One of my favorite things about the role of CTO is how different the role is at different companies. Early on it basically means technical cofounder or at least first technical team member. As the company grows, it can evolve in either the technical direction or management direction or a hybrid of both. Some CTOs are more like lead architects and oversee solely the technical decision making on the engineering team. Greg Brockman has a good take on this, as does my favorite CTO thought leader Camille Fournier (you’ve read her book, right?).
Suffice it to say, it’s a role that can be many things depending on the needs of the company and the strengths of the individual filling the role.
For me, the role is a combination of:
Leader and manager of the engineering team, and sometimes the entire product team (depending)
Member of the executive team
I used to joke that the acronym actually stood for Chief Translation Officer because of how important it is to speak the various jargon dialects across the company. (“Reworking the model” for Excel-wizards is “pay down technical debt” for engineers.)
At its core, my responsibility as CTO is to work w/ the members of the executive team to help set and understand the objectives of the company, to translate those objectives into a technical roadmap, and then execute that roadmap successfully.
Part of this skillset is not just engineering management but general management. Effective communication to all parts of the company, fostering a non-adversarial relationship between the product and engineering teams w/ the rest of the company, and striking the right balance of Andy Grove’s black box w/ transparency. It means knowing (or learning) how to hire and manage all types of people – engineers, designers, product managers, tech leads, and so on.
One last note. I’m not here to build a command-and-control organization. Command-and-control is pre-industrial revolution. It’s for unthinking robots who don’t want to make decisions or exercise responsibility over their fates. Other companies do that well – not us. We don’t give orders – we provide goals and we get out of your way.
We’re building a team of people who know what the goals are, have displayed competence and good judgement, and as a result have the autonomy and responsibility to make sound decisions.
Someone once told me that as a member of the executive team at a growing technology startup, whenever there is a Big Decision that must be made, you have three choices:
Agree and commit
Disagree and commit
Don’t let the door hit your ass on the way out
Obviously this is a bit tongue-in-cheek, but I’ve found it hugely clarifying over the course of my career.
Agree and commit
This is the happy path. Healthy debate has occurred, and the decision was made according to the path you preferred. You’re on easy street and immediately leap into next steps.
Disagree and commit
This is hard. You argued your perspective. You used your credibility and the best of your persuasive abilities. You brought data to the discussion that backs up your argument. You provided lots of evidence. And the team went in a different direction.
You’re at a critical juncture. How you conduct yourself and move forward will speak volumes about your leadership style. Now is the moment when you will either:
Proliferate politics and frustrate your team by remaining ambiguous about your team’s goals, inhibit progress, throw up roadblocks to the team’s momentum, or
Foster a focused team rallying behind a clear direction.
Obviously if this happens frequently enough, you may just need to part ways. But I’ve found for the vast majority of Big Decisions, disagree and commit is the right path. You deepen your professional relationships, build empathy and respect for other points of view, coach or assist your direct reports (and learn from them) on this process, and ultimately learn a ton about yourself and your values.
We’re currently on week 14 of Agave, and I wanted to write a little about the product development process inside my brain as Jared and I are working on building the best virtual office in the world for remote teams to have serendipitous interactions.
Separate problems/opportunities and solutions
It’s such a common mistake to make – mixing up problems and solutions when trying to decide what to include in a given sprint. Every team has a Kanban board, a 2×2 matrix, or a backlog with both problems and solutions all mixed together. A simple example might be “onboarding is too complicated” – this is a problem. “Build lifecycle emails” is a solution to a problem.
The best product processes I’ve ever seen place a strict separation between these two things, and treat them differently. Problems should be stack-ranked in terms of importance or impact. What problems are we solving? In what order? This week, are we focused on fixing acquisition problems? Engagement problems? Churn problems?
Problems can and should be debated vigorously. Lock horns, butt heads, exercise those strong opinions and subject matter expertise. Bring data to back up your statements. Argue. Foster internal competition on what the problems are, and in what order we should solve them.
Ideally, at some point you draw a line between the need-to-solve problems and nice-to-solve problems. (And then throw out the nice-to-solve problems, you’ll never get to them.)
Solutions are different. They require a completely different frame of mind. Once you’ve got your stack-ranked problems, conduct a brainstorming session – “yes, and” instead of “yes, but”. It’s not about debating which solution is best – it’s about getting as many ideas out onto the table as possible. Cultivate ideas from every part of the company – at this stage, no idea is a bad idea. You want a ton of fodder for the next step.
This is a great time to think hard about what competitive advantages your team has. How can you use your superpowers to solve these problems in ways other teams cannot?
After you’ve got your whiteboard full of ideas to solve a particular problem, you should be able to identify similarities amongst some of them – ideas that are sort of adjacent to one another or have lots of overlap. Identify these adjacencies – combine these ideas and, if necessary, refine some of them to be a little more detailed or fleshed out. Don’t go overboard – just be able to describe them in a sentence or two.
(Optional): Deep-dive on each solution
If you have the time and resources, it’s sometimes worth taking some time to get smarter about the actual cost and benefit of each solution. Figure out who the target user is for each solution, what are the substitutes / complements for this solution, what are the success metrics or go-to-market details, and then sketch out the MVP solution, effort, and implementation. Identify risks, assumptions, stakeholders, and dependencies in your organization.
Not all teams can and should perform this step, but if you can, you’ll be much more well-equipped for the next step.
Effort and Impact
Now is the time to finally bring those ideas to your 2×2 matrix. For each problem you need to solve, take the ideas for that problem and throw them onto the board. Like this:
This can (and should?) be a little messy. Just toss them on there somewhere and discuss their position on the board with your teammates. The people on the team thinking most about the business goals can have more of a say in the impact axis, while the people responsible for implementing the ideas can have more influence in the effort axis.
You’ve got your roadmap
That’s basically it. Once you’ve got your team in rough agreement on the cost-benefit impact-effort of the ideas to solve a particular problem, you can literally work your way from top-left to bottom-right. There’s your stack rank.
This does not need to take a long time. For super small teams of 4 or less this can take an hour: 5 minutes for problem identification, 5 for stack ranking, 15 or 20 for brainstorming, and the rest for impact/effort discussion. For larger teams it can span a week or more.
If you follow this process week-by-week, month-by-month, quarter-by-quarter for a long time, you can sometimes find yourself not working on anything “big”. This is a common criticism that I intend to write about elsewhere. Suffice it to say, you should adjust this process to suit your needs. Many teams take a sprint here and there to switch gears completely away from this approach and perform rapid prototyping or hack-weeks to showcase what they think could leapfrog the current product. This is a great example of The Innovators Dilemma.
This process lets all participants have a say. The people closer to the customers bring valuable data and instincts about what customers want. The designers and engineers bring valuable opinions about what’s possible. The sales and marketing pros bring valuable intel about what the market is telling your company. Customer support reps bring valuable data about what customers are having trouble with. All of these people have valuable data and insights that can and should influence your company’s product roadmap.
(And if you don’t want your people participating in this process, why did you hire them in the first place?)