Note: I didn’t necessarily learn these things from CTO’s directly, though some of them did result from conversations between me and my favorite CTO’s. I didn’t necessarily work for these CTO’s either, though in all but the first I did. I have used poetic license in many cases since CTO’s, in my experience, are less pithy than I am wont to be. Finally, in at least two of the cases, the lesson I learned was not the original intent of the CTO I learned it from. Not that it matters. Lessons are funny like that.
1. If you don’t think this film can be your baby, I don’t want you directing it.
This nugget came from an interview process, actually. I was pitching myself to a company – I loved their growth and team. Their customer, not so much. It piqued the CTO’s Spidey sense. I answered honestly. I was kidding myself into thinking I could love this product I would be managing and said so. It was gut-wrenching to get that far along with people I respected only to be called out on my physical impossibility of using or enjoying the product I would be asked to manage.
Interview over. But what stuck with me was the fact that he invoked a film metaphor. What’s up with that?
In the question, it hints at the auteur theory of filmmaking. It wasn’t always the case that film directors were considered the “authors” of the film. It wasn’t until the French New Wave came along that directors were put front and center and then film history back-filled the history books with the “auteurs” of each opus.
You only need to look at how a film is made to understand why being a product manager is like being a film director. As a film director you work with so many talented and very focused engineers: from script-writers, to lighting and audio engineers, to special effects wizards and the cinematographer; then there’s the actors and musicians; and finally, the marketers and producers.
As a product manager you’re going to be working with so many people focused on singular efforts: designers, developers, testers, marketers and sales. But at the end of the day, while the success of the opus might be owned by many, it comes together because you took care of that baby. In all those facets, others were looking to you to know if their contribution mattered. As product manager, you are the director. As CTO, you need to know your team is getting the guidance it needs from someone who is invested in the outcome. Success or failure, it will have your name on it.
2. Talented people don’t need management, but they need product managers.
Managing effectively, as a CTO means knowing how and when to offer guidance to the technical staff. In no small degree the CTO needs to be able to get a cow out of a ditch, know why it got there in the first place and know how to prevent it from happening again. CTO’s need to know whether development efforts should be rabbits, horses or elephants. CTO’s need to establish large blocks of development effort in terms of debt, equity and product. And CTO’s need to be able to hire talent and know enough to get out of their way.
Product managers manage people, processes and expectations. They are the fulcrum in the balance beam of resources and output. A good product must be good with people, fluent in development processes and deliberate in establishing expectations.
While talented people will rarely need management, they do often need product management. Why? Because if something is not creating equilibrium between all of these competing forces, the system will waste a lot of energy doing it itself.
It’s also important to note that at a technology company, this is one of the best rationales I know for why the product organization should report to the CTO.
3. Measure everything, but report only what matters.
I started working with a team on a product that was going from being a server-based install to a cloud-based SaaS offering. When I joined, it already had a cloud offering but it was suffering from multiple layers of suckiness. During my discovery process, I learned one of those layers was that the product was unavailable for hours every week. The SLA was non-existent. Confidence was low for customers. Morale was low for the team. There was considerable evidence that downtime was an issue. I was gathering a ton of this evidence and reporting it back to the team, but it only served as a whip to those who were already feeling bullied. The problem wasn’t that they didn’t know. Nor was it that they didn’t care. Instead, I found that they didn’t have a clear target for acceptability for this problem and they weren’t being asked to focus on it.
Nothing establishes focus like setting goals.
What did we do? We picked an SLA we thought we could proud of: 99.9% uptime. In downtime here was our goal: 1m 26s per day. 10m 4.8s per week. 43m 49.7s per month. 8h 45m 57.0s per year. 8 hours a year compared to 8 hours a week. We had a steep mountain to climb. We got a tool that tracked uptime in realtime and which we would give our customers access to. We put a monitor in the same room with the engineers and let them focus on those goals. In a few sprints we had dedicated ourselves to this sole problem and we had the measurements to prove we had solved it.
We eliminated all other metrics. For the purposes of this theme, there was only one goal that mattered. Everything else was noise.
Over time, the monitor’s contents changed. Depending on the theme of the sprint, we would be reporting different goals. We never stopped measuring uptime even though I sprint themes changed. But we did stop reporting them because the new challenges were more invigorating. Morale improved. The product improved. It took a product manager to hold people accountable.
4. Social contracts are important
Agile, waterfall, chaos, whatever your development style, it will be dictated by the team and its leaders and adopted begrudgingly. I kid. Teams love agile. The others are suckier. Why? Because agile is a natural byproduct of teamwork. Indeed, agile begets teamwork. Here’s why: Scrum. Put your heads together for a moment, then break. Repeat at regular intervals. Scrum is a fantastic way to align yourselves temporarily and set the tone for what’s going to get done. But when scrum works it helps you not only manage products, but it helps you measure what’s important for team-building.
- What did I do yesterday?
- What will I do today?
- Do I have any blockers?
This order is important. Start off by listing the items you did. We’ll call you on your bullshit if they’re different than what you said you’d do.
What will you do today? Great. We’re going to hold you to it.
Your blockers? If I can unblock you, I will add that to my to-do list.
Round we go from person to person outlining our responsibilities in our contract to one another. It’s how good teams become great. If you’re eyes are glazing over in scrum, you’re doing it wrong. You should be holding each other accountable and calling each other out if you’re not holding up to your commitments. It’s not the CTO’s or PM’s job to do that, but to encourage peers to do it. When it happens, it’s magic.
5. Slow down the input process.
One CTO I worked with ran around with a stack of 3×5 notecards everywhere. Any time someone brought something up that needed to be done, he would give them a stack of cards and say, “Go ahead and write me every use case you can about that feature set. Then schedule a meeting with Kelly to flesh them out. We’ll look at them prior to the next sprint planning session.”
I loved this approach. First, it was so analog it was hard for people to not get it. Sometimes the tools that have been designed for power users get in the way of thoroughness and thoughtfulness of simply putting pen to paper. Second, it established a timeline that the reporter him or herself would be responsible for adhering to. Sprint planning happens every thursday from noon to 4. Get your stories straight with the help of the PM before that meeting. Last, the cards themselves were effective props. If a story was completed, the card itself was taken over to the person who reported it who then had the pleasure of ripping it up. So much smile.
6. I’m not building a religion, I’m building a church.*
Let marketing build the religion.
7. I’m a CTO, not a scientist.
This is my favorite. The only people I’ve worked with who call themselves scientists are data scientists. However in most orgs, the developers have Computer Science degrees. The CTO almost certainly does. Yet, they go by developers, engineers, designers, directors, chiefs, leads or architects. Why not scientist?
I think the answer boils down to the intentions. Scientists, even data scientists, spend much of their day running experiments. The process is mostly academic. Whereas engineers are living in the world of applied sciences; that is, applications are the manifestation of knowing what works for ensuring this equation always stays true:
solution > problem
The exercise is not academic. It’s practical. And it’s why you are a CTO, an officer of a company, and not a hacker. My job as the product manager is not to minimize the hacking (the CTO will help there) but to make sure the problem exists and set priorities for its problem-solvers to apply their science.