Startup CEOs face a very tricky transition period when their software engineering teams are between 10 and 30 people. If you are lucky, your early technical lead can make the transition to managing a growing team and communicating effectively with execs and board members, but that doesn’t always align with people’s interests or capabilities.
In this situation, the mistake that too many startups make is hiring too far ahead of their growth curve. They bring in a “proven” VP of engineering from a bigger company. These leaders are very good at communicating upwards, but are often used to having layers of operational leadership underneath them. They don’t get close enough to either the actual work or the individual team members, which is a recipe for disaster at a startup. (p.s. this endemic hiring mistake is not specific to the engineering role)
This “A and B venture-round” head of engineering is a hard role to fill because there aren’t that many out there who can think and communicate strategically AND can get in the weeds with the team at both a people level and an engineering level AND are available.
I’ve seen many situations where companies just churn through VPs, but there is a viable alternative: pair a VP-level product leader with a strong “director” level engineering leader. (It’s very important to note that the reverse also works well when the hiring challenge is reversed)
Here are a few requirements for it to work:
- The VP of Product needs to have a strong understanding of and empathy for engineering process and culture, and has ideally managed engineers before.
- The VP and the senior engineers need to have enough shared values that they can work together (i.e. how one approaches testing, tech debt, deadlines, etc) — at least at the high level.
- The VP needs to coach engineering process and culture, but not micro-manage it. The engineering team should feel like they can steer what engineering craft and culture looks like.
- When it comes to architecture and technology choices, the VP should ask questions but should defer decision-making to the engineering team (except in the case where they are totally deadlocked).
- The VP needs to have the bandwidth to get closely involved in personnel issues across the entire team.
- The “director” level engineer should be respected by the team for their engineering skills; have the personal interest to shift from mostly coding to dealing with people, process and hiring; have the willingness to shift from peer to leader (i.e. you can’t be everyone’s buddy anymore); and have the right mix of strength and humility to be able to stand up for their ideas but take in ideas from others. (I’ve included below my current version of the job description for this director role)
- The VP role can come from the outside but the director-level role is best coming from within the existing team.
- This director does not necessarily need to aspire to become a VP — they can bridge you until you have found that hire — but ideally they do. This partnership becomes an excellent way to mentor someone up to VP level.
This is the flying formation we’ve had at Axial for most of 2017, and it brought stability and productivity to the team after a long period of turmoil. It had the added benefit of aligning product and engineering very closely together on process and values. I brought some new things to the table in how I approached agile, lean and cross-functional teams, but importantly, I already had shared values with the senior engineers on more frequent incremental releases, making time for testing, investing in devops, paying down tech debt, and being realistic with timeline goals and expectation setting. Together we were able to make those things real.
I’ve seen this work at other companies too: a successful e-commerce company in NYC had churned through several VPs of engineering. My friend “Z” had been an engineer on that team for years. She is a very talented engineer and highly perceptive reader of people, but she had resisted my urging her into management for years because she prefers coding. About a year or so ago, the company tucked engineering under their head of product, and “Z” took on more engineering leadership tasks while not being forced to completely separate herself from the engineering work itself. This VP-Director split worked far better than their struggles to find the perfect VP.
Two last thoughts:
First, I don’t think this structure is scalable in the long run. I personally think that it is a good thing to have two peers running product and engineering, or even three peers running product, design and engineering. But this VP-director split can get you through a very tricky stage for a startup.
Second, it can be equally difficult to find a head of product who can successfully take on the engineering side of things, so if you don’t have it, you should hunt for this role while hunting for the ideal VP of Engineering. You will have at least increased your pool of options.
— — —
If interesting to folks, I’ve shared the job “description” I currently use for the director role described above. Some of it is aspirational — in this situation, you are mentoring someone up to the VP level so they are naturally going to have gaps of experience and capability — but it covers some of the essential pieces.
Director of Software Engineering Job Description
While you will perform your tasks with the help of colleagues, you are ultimately responsible for 4 major areas:
- who is on the software developer team (hiring/retention/firing)
- how team members grow and improve
- how we do our work
- how we maintain a great culture
Ensure that we have a really strong team
This covers hiring, retention and firing: you have responsibility for ensuring that we attract great talent whenever we need to hire. Part of this includes inspiring great developers to discover Axial and to want to work at Axial — and in particular inspiring engineers to want to work with and for you because they believe they will learn and grow. You are responsible for ensuring that every member of the team is productive, and that unproductive or culturally-poisonous team members are removed. You should be thinking about, and advocating for how we can retain valued employees, not by coddling them but by giving them a sense of accomplishment and a connection to the mission we are trying to accomplish.
Ensure that members of the team are growing
You are ultimately responsible for the progression and growth of all members of the software developer team. This covers both a developer’s advancement in their craft as well as their professional maturity. You are responsible, both directly and through your leaders, for ensuring that every team member is getting regular feedback, both positive and critical, and that every team member knows where they stand.
Ensure that we run a smart and ever-improving process
You are responsible, in partnership with product and dev-ops leadership, for the process with which we write and ship code. Our goal is to run teams that continuously ship and continuously learn. Our goal is to be as productive as possible and continually find the right balance of speed and quality. Process is an ever-changing thing that is influenced by our own context as well as best-practices learned from the outside.
Ensure that we are making the best technical decisions
You are ultimately responsible for the software architectural decisions that we make as a team, as well as the process for making those decisions. You will ensure that we are making decisions efficiently yet intelligently, that the right people have a chance to weigh in on decisions, and that we are balancing technical and business needs. You should create and refine a continual process for this to happen effectively.
Ensure that we have a culture of ownership and responsibility
We need to build a culture where people take pride in their work and their craft, while being cognizant of the needs of customers and the business. This means insisting upon the right level of intensity and focus, while keeping it sustainable. This means requiring engineers to pay attention to details and quality. It means requiring engineers to respect the needs of the team when they think about time off.
Ensure that we have an inclusive and meritocratic culture
You are the tone-setter when it comes to team culture. You, along with your leaders, are the role models and enforcers of the culture we want, as spelled out in the blog post on our values.