How to Balance the Two Types of Engineering Leadership
And why many startups can’t innovate at the cutting-edge
Some of the very well-acknowledged authorities on start-ups, and business in general, have a normative view on the gulf between the two types of engineering leadership that a team at an innovation start-up requires. An engineering team needs direction, perfection, management, and motivation in order to deliver exceptional results. The two roles encapsulate these needs. And they both need to be made on extraordinarily sturdy scaffolding.
It is not the exception but the rule that technology-oriented companies and start-ups need solutions at the exceptional level because their raison d’être is to propel the cutting edge forward. Building insurmountable competitive moats in the information economy also entails a strong application of exceptional technical solutions.
A mature organization today was built at least a decade ago, and in most cases, several decades ago. At the time it was founded, the accessibility of tools to bolster innovation practices — as compared to tools that fall into our fortuitous laps today — may have been akin to pulling a giant bucket wheel excavator submerged in quicksand. (Today, it would only have its tracks submerged, and it would have already started light excavation with zero intervention from you.)
These companies have grown through arguably tougher times, in terms of access to innovation tools. And at the wake of their growth, the top management may have developed distinctive patterns of organizing engineering and innovation.
But can early-stage start-ups today emulate such frugal learning in some form to create an inherent competitive advantage?
It pays to ponder over what constitutes engineering and product development at its most fundamental level. Only with this knowledge can founders build the necessary mind-set towards their own innovation and engineering effort.
What begets exceptional engineering
There are many sources of innovation, including bathtubs, but none is more promising than a well-planned engineering effort. Exceptional engineering is borne of an artistic recapitulation of high-quality technical insights on a devoted set of requirements.
It is immediately apparent that there are multiple skills at play. An engineering leader needs to have foresight, which is only manifested by being both learned and observant in the field. An engineering leader must know her way around the tools and techniques of the trade, be it software, bioengineering, or sound-stages. She must also be able to imagine the engineering effort in the form of a timeline, iterate through it before and during the project, and deal with resource constraints to maximize the possibility of producing exceptional solutions.
Finally, the most crucial of aspects: before the team exists, the leader exists. And the leader must exist in spite of the team.
The two types of leadership help to formulate the two buckets (pun intended) that will contain complementary skills. We can condense these two types of engineering leaders to their foundational ideas:
An “artist” is the one who can set the tone for technical and engineering development. This is the person who is skilled in the product domain enough to know how to perfect its development and specifications, and is also motivated by the thought of pushing technical boundaries and achieving product excellence.
A “manager” is the one who has the technical and people skills to operate a complex engineering project. This is the person who is skilled in the product domain, but is also skilled and focused on delivering the complex operations of the technical development over extended periods of time.
Mark Suster equates the CTO role to that of the artist. In every start-up team that wants to build big visions into reality, there is a need for high quality and near-perfection. He says the role of the CTO should be to indulge in the technical details of the product and internal systems of the company, and indulge to the point of (useful) profligacy.
A product prodigy more often than not, the CTO should be required and allowed to set the technical direction of the product and internal systems based on deep technical expertise, with a focus not on quality assurance, but on quality augmentation. The CTO’s job should be to not just use benchmarks from the industry, but to set benchmarks for the industry.
Anything and everything that goes in between, especially including the overcoming of learning curves, a CTO should do. And in order to do that, the CTO requires time on her hands.
This is typically where a VP of Engineering, or equivalent, comes in. Suster suggests that the VP of Engineering is effectively the manager of technical operations — process-oriented and responsible for the engineering deliverables. A team needs vision and direction, but it also needs method and control. The VP of Engineering is the chief problem-solver from a process point-of-view, but if need be, from a product point-of-view as well. He deals with the ins and outs of the engineering activity, budgets, and timelines, and is responsible for coordinating world-class engineering.
This is where those mature organizations’ tribulations led them. This is the simple pattern of organization followed almost everywhere.
Everywhere except early-stage start-ups.
When in an early-stage company there is just one person to do the job(s), the start-up is at a stage when it needs to be thinking about making a pioneering product, while also thinking about how to get to the next stage of development, growth, and revenue with no real product in hand right now.
It is difficult to argue for any differential in importance between the two, because failure in both can mean failure for the company itself.
One school of thought would say, “If the product vision isn’t at its highest fidelity today, we can still go to market with a product that we can improve later.”
And the other would reply, “If we are not building what we’ve already envisioned to be outclassing others, then what is the point of having envisioned it?”
At first glance, in the context of a company trying to get up on its feet, you can see the point of at least “building something” instead of “building something compelling”. But doing a little double take here, it doesn’t seem like any of them is wrong per se. The real reason for the incongruence is: the company agenda. At the time of starting out, founders tend to focus on reaching the point where they have something in hand or something to show in order to gain what is called traction with the user base. The whole Lean Start-up phenomenon: it is based on the logic of active learning and iterative building. This is the portion of their jobs that founders wholeheartedly embrace.
What is often forgotten is that if there is no process initiated for quality augmentation early on — the background operations, the kind to constitute the company’s underbelly — it will be difficult to implement later on. It is a deceptively simple fallacy. You spend six months to a year “building something”, and then you realize that you are nowhere near the required level of excellence for it to become “something compelling” soon enough; perhaps even that your whole “building something” could have gone quite differently if you had had certain product and technical insights from time to time.
But who spent the time and lost their hydration for creating those insights?
Timely reminder: Some of this discussion pertains to companies that are trying to build technical solutions to really big or really hard problems. But everyone can partake in this approach — it would serve to vastly improve the overall rate of useful innovation.
The real underlying conflict between the technical leadership roles required in a high-fidelity environment in an early-stage start-up is not so much interpersonal as it is intrapersonal. Think about it this way: a good, smart start-up, especially one with multiple co-founders, recognizes the two distinct roles required in its team from Day Zero. But as is the case with most start-ups in their early life, a team finds it difficult to fulfill the conflicting requirements because they are limited to using just one person!
The reason for the conflict is not the job title, but the innate nature of the role itself. Harking back to Paul Graham’s sagacious observations about the Maker’s schedule versus the Manager’s schedule, we can begin to qualify this conflict.
It is clear that the CTO-type role needs to be on the maker’s schedule, i.e. her time devoted to thinking about the product, knowing tech and learning new tech, trying solutions at a high level, bringing cutting edge ideas, and implementing ground-breaking solutions. A lot of this is the kind of work that goes on in the background, invisible to spectators.
On the other hand, the VP of Engineering needs to be on the manager’s schedule, i.e. his time devoted to thinking about building the planned product, replete with all technical requirements, providing structure to the development process, and managing time and cost, while providing technical support to the team from time to time. The nature of this role is to produce tangible results, and this is what people — stakeholders, internal team, customers, market-watchers, and investors alike — see at the end of the day.
The nature of both tasks is vastly different, and the real value created by the former is not immediately apparent to all.
This is where the problems begin.
Once you know, talk
Let’s fold back to the issue of the one-person job. The technical guy or gal on the team has to provide all four of the essentials to an engineering team — direction, perfection, management, and motivation. Time is limited, though, and the Maker and the Manager within the person may or may not be able to manifest themselves at all times.
So, what are the options?
- A co-founding team with more than one technically oriented minds;
- Hiring someone to be one among the Maker or the Manager; or
- Setting the company agenda to not cover one of the roles.
It is evident that the third option does not count when we have already recognized the criticality of both roles, but it still may be feasible for some situations. (More on that in the future.)
The second option is something that not all early-stage companies have the luxury of entertaining, for obvious reasons. It basically comes down to option one: let the team handle it within the co-founders or early team.
It’s fairly straightforward — make sure you have the kind of people to be able to handle something like this from the get-go. But going forward, the biggest hurdle is to be able to set the right company agenda, one which recognizes that activities required for performing both roles need to be prioritized, even though one is outwardly visible and the other not so much.
Communicate the reason for considering both kinds of roles.
Communicate why some bilateral prioritization needs to happen.
Most preferably though, this hurdle is eliminated by the conscious appreciation of the simple fact that for something compelling to be built, it might make sense to work in complementarity, because someone typically needed to be on two jobs at once.
What about the rest?
There is no paucity of similarities between the discussion on engineering leadership roles and a discussion on strategic & tactical management leadership. In every start-up, founders, technical or otherwise, need to focus on a fairly large set of activities to be able to navigate the company through the uncertain and into the certain. There are endless questions to be answered and a barrage of problems to be solved. The best founders and teams know that despite the deluge, they need to take two perspectives at any given time — the strategic and the tactical.
For example, a founder in a two-member start-up trying to get to MVP stage is working on how to implement the initial version of the product, the development of which is being directed by his co-founder, and bring it to market. There are lots of things to manage — operations, procurement, deployment, contracting, etc. But in growing the company, the same head needs to be used for thinking through not only fund-raising and hiring but also alternative go-to-market strategies, hustling to achieve side objectives, studying the market and competition (I mean really studying it), and setting a multi-year agenda.
His job is a mixed bag of the micro and the macro. Only when the founder is able to keep track of when he needs to be on the micro or on the macro will he have a chance of succeeding at his job.
The challenge here is to be able to have the head-space for this.
And the follow-on challenge is to be able to have the head-space for this on a highly regular basis.
(Imagine how the problem is compounded when a technically oriented founder is also the one who is thinking about how to grow the company. It’s not desirable that this be the case, but then not all teams are built equal.)
The same principle that we applied to engineering leadership is also applicable here. There are both strategic and tactical roles; there are both visible and hidden results. And there are just a few people to do it — sometimes just one.
If co-founders fail to recognize the dual-class structure (pun intended, again) of his roles, it is going to quickly become difficult for our guy to get work done. Not because he’ll be ineffective or unmotivated, but because it would be difficult to set the company agenda in a certain manner.
When items are not on priority because there is mutual agreement on the low importance of their currency, things are good. When items are not on priority because the importance of the strategic and tactical coexisting goes unrecognized, or a failure in value judgement, or worse, a practised abstinence from two-layered thought… Well, that’s a bit of a bummer, isn’t it?
Understand — and communicate — that it is not just the visible things that can be achieved that matter.
As founders, the tactical is of course very important. Yet, what also matters is what goes on as an undercurrent in the operations that helps the company to create sustained competitive moats and advantages in the market.
Because what also matters, besides building something, is building something compelling.
About the author
Sarang Deshpande is an engineer, founder [Flow Mobility; Cambio Motion], and writer. This trifecta allows him to be usefully interdisciplinary in his approach. Besides spending time solving challenges in the urban mobility domain, he regularly writes about science, tech, business, and life (sometimes). He is an editor at World In Mind, a new publication which brings cutting-edge research to students and working professionals: important research across industries will set the tone for humanity’s future trajectory, and young humans would do well to keep the world in mind when they choose their area of professional focus.