When I first moved into the COO role at Airtasker, a number of people from around the industry responded to the news with a tone of mildly surprised encouragement, as when a member of a traditionally underrepresented group wins an award or gains a position of influence. Engineers are hardly wallflowers, nor are we underprivileged, but it is true that the path to COO doesn’t run most commonly through Engineering.
In my view, Engineering is a tremendous staging ground for building the skills required to act as COO. In this article I explore the key aspects of a COO role and the ways in which Engineering prepares you (or in some cases doesn’t prepare you) for that part of the role.
But first: my fragile ego needs validation! This is a free newsletter, I’m doing it for the glory.
If you haven’t subscribed yet, please do so now. And if you already have, tell your friends, tell your parents, tell those closeted-COO types who really need to get out there.
And link away too:
OK, on to the article.
Organisational Design & Leadership
In a technology company, Engineering will typically compete with Sales or Support as the largest function by headcount. As such, a CTO or VP Engineering will often be in charge of an organisation that on its own possesses significant scope and complexity. This is valuable experience for any aspiring COO.
At Airtasker, the Engineering team consisted of about 50 people. That meant I already managed managers, had to communicate effectively with my team using one-to-many techniques, operated a leadership team, had to execute multiple re-orgs, and created process and communication pathways with quite some complexity in order to keep the team working smoothly and to a high standard. Engineering teams consist of valuable and highly skilled craftspeople who know their worth and typically tend to be quite outspoken. Leading such a team is no picnic, which is to say, it’s a great learning experience!
Had I come up from Product, Design, or Marketing (for example), I would have had a smaller team and few fewer of the above experiences. This is definitely a pro for the Engineering pathway. Amidst all the newness and uncertainty of moving to a COO role, I was able to lean quite heavily on my experience as VP Engineering when it came to the organisational aspects of my role.
Engineers become very familiar with the art of the difficult tradeoff (e.g. speed vs. cost). In fact, amongst Software Engineers it is often the ability to make good architectural decisions in the face of the many challenging constraints and tradeoffs that is the mark of a high quality and experienced practitioner.
As COO the ability to efficiently make high-quality decisions (or at least to be decisive enough to resolve deadlocks) is key to keeping things moving and to ensuring good outcomes in the long run. I have found the skills that I built up in Engineering around effective decision-making in the face of difficult tradeoffs to be invaluable as COO.
Software Engineers often like to present themselves as rebellious anarchists who are too free-spirited to be constrained by process. And yet, nearly everything a good Engineer does is guided by well-designed processes and conventions: from how to name a variable, to when to deploy software, to how to respond when there is an incident in production, the modern Software Engineer depends on process to be able to do their job well.
Hence, an Engineering leader tends to be well versed in the design and implementation of processes. My work as VP Engineering at Airtasker required me to involve myself fully in the art of process design. In my time on the role alongside the team I defined a process for testing our software, reworked our interview process, created a process for making architectural decisions, and many other things besides.
It is my belief that designing processes that aid and assist the organisation, rather than allowing anarchy to reign or building a stultifying bureaucracy, is one of the marks of a quality COO. Once again, Engineering is a place where that skill is honed.
It is always a shock moving from a position of functional leadership where (in some ways at least) you are as skilled at the work your team is doing as they are themselves, to cross-functional management where those who report to you (and their teams) know much more about their area of expertise than you could ever hope to.
How to manage such people? How to coach them? How to have a conversation with them without just feeling a bit dumb? It’s a whole new world.
Of course, this is largely unavoidable no matter which path you take to COO. There are a number of advantages to coming in from Engineering, however. The first is that Software Engineering already has many sub-disciplines (backend, frontend, native, SRE, etc.), so the humility and skillset involved in leading people more expert than oneself is something that an Engineering leader has quite a bit of chance to practice. The second advantage, especially if you work for a product-focused organisation, is that Engineering sits within a cross-functional structure (Product, Engineering, Design etc.) that provides quite a bit of exposure to a number of other disciplines. Although I don’t fool myself that I have the skills to be a Product Manager or Product Designer, I have worked closely with many of them across the years and have a decent understanding of what the role involves.
Now we’re starting to get a little more into the cons territory of the CTO pathway. It’s true that good Engineers work hard to understand the problem they are solving, but there is no getting away from the fact that they are away from the front lines. Unlike Sales or Marketing, Product or Design, Support, CX and the rest, Engineers tend not to regularly talk to customers as a core part of their job.
I have yet to do a good job of getting in front of our users. Instead I rely on the learnings of others within my team to understand as much as I can about them. If I listen carefully, I can learn a lot. But I know that this is a poor substitute for actually being there with our users, or coming from a background where user affinity is a core competence. This is clearly an area where I have much to grow, and is the gap that is most exposed when transitioning from CTO to COO.
Another area where Engineering does not provide a particularly strong education is in the more commercial side of leading a team. Of course, any senior leader needs to tangle with budgets, accountability, and outcomes. And a good executive needs to care about the economics and financial situation of the business. But: as with user affinity above, it is difficult to argue that the commercial side of things sits particularly close to the core competence of an Engineering leader.
The nice thing about a lot of business stuff is that it is technical and number-based, and therefore doesn’t feel all that alien to the Engineering mindset. Personally I found something quite satisfying about the world of CACs and LTVs, TAMs, margins, burn rates, forecast models, cohort analysis and all the rest. Like software engineering, finance and its related fields are about representing the real world in an abstract and numeric form.
Other aspects of commercial acumen such as dealing with investors, business development, partnership negotiations and whatnot are beyond the remit of a typical COO. These are skills that are hard to learn and are certainly not honed in the world of Software Engineering.
Moving from functional leadership into the sort of general organisational management that is embodied in the COO role is inevitably going to expose big knowledge and skill gaps, no matter which function you come from. I have found that leading an Engineering function as CTO or VP Engineering is as good a place as any (and a better place than most) to prepare for the challenge.
If you’re not learning new things you’re not growing; I encourage leaders in Engineering to consider whether a COO role may be just the thing for them as they seek the next step in their career.
Still reading? Still not subscribed? Here’s your chance to fix that: