In early 2015, after spending more than a decade working at Adobe, I was itching to return to the startup world. While working at a larger company had its benefits and I learned a lot, I missed the fast pace, the ambiguity, and the no-risk, no-reward elements of startup life. As I transitioned back into startups, I found that I had to scale down my approach as an engineering leader while also paving the way for the organization to scale up.
What follows isn’t intended to be prescriptive advice for engineering leaders. Consider these ideas tools to use if they solve your particular set of challenges. If they work, add them to your toolbox!
The excitement of joining a startup is understandable. You’re sold on the vision, the people are nice, and the amenities in your cool new office are fantastic! You can’t wait to start working with the team to push out code. Well, the best way to go fast is to slow down.
Do you truly understand the founders’ vision? Could you pitch it to a new candidate the way that they pitched it to you? As product ideas are validated with customers, the pitch is likely to change frequently— you’ll need to stay in sync with the messaging. Participating in customer calls or visits, leading part of the company all-hands, and having regular check-ins with the founders can help ensure that you stay aligned on communicating the vision.
Somewhat more difficult is aligning on roles and responsibilities. If one or more of the founders are technical, you need to establish your role relative to theirs very early on—preferably before you even start. Technical founders often want someone else to handle the drudgery of management, leaving themselves free to focus on technical decision-making. This can be a delicate dance on numerous levels. First, you obviously have technical opinions that are likely as valid as a founder’s, and egos may start to come into play. If a founder is the CTO and you’re brought on as the VP of engineering, the most common division of labor is:
Role | Scope |
---|---|
CTO | technical vision and architectural decision-making |
VPE | people and process management; responsible for delivery |
This is a simplistic take, but it’s key to discuss the expectations around the role with the founders. After all, you have to send a clear and unambiguous signal to the rest of the organization as to how things will work. Push back lightly when a founder oversteps (this will happen), and be as flexible as possible without turning into a pushover. Founders have the advantage in the power dynamic, but they hired you for a reason. If engineers report to you but you’re frequently contradicted by a founder, you lose—and so does the company.
Your job is to provide the founders leverage. The easier it is for people to understand what they should come to you for versus what they should take up with the founders, the more likely that leverage will be achieved. Create space for the founders to focus on the things that they enjoy. For many CTOs, this includes things like building prototypes, exploring new technologies, giving demos, and talking at meetups. If you’re keeping the GitHub issues and backlog up to date, ensuring that the build system is always working, recruiting and hiring more engineers, and providing detailed status information to the rest of the organization, the CTO will most likely appreciate you greatly. The specifics differ from company to company, but it’s your responsibility to figure out what will work where you are and to adapt as the situation changes.
Recruiting and interviewing
Whether you’re starting from scratch or joining a startup that already has a small team, take the time to flesh out and document your recruiting strategy and interviewing process. Winging it is all too common, but it’s destructive and shortsighted. Your people are the most important aspect of your business: They enable everything else.
One task often delayed is establishing a career ladder, as time to market and establishing product-market fit are often considered the most important things to tackle early on. Career ladders, on the other hand, are seen as a management artifact only needed when the organization gets larger. It’s better to look at them as a recruitment tool. Potential hires are evaluating you as much as you’re evaluating them. Demonstrating that you’ve put some thought into their future at your organization helps to demonstrate an inclusive mindset, particularly to underrepresented candidates.
One of the most referenced starting points is Rent the Runway’s career ladder (although many other companies have since published theirs). Read several career ladders and borrow the ideas that resonate with your team’s emerging engineering values. However, start small! Some companies have elaborate ladders based on their size and experience, which may not match your eventual trajectory. Consider starting with these simple ladders:
Engineering Track | Management Track |
---|---|
Engineer | Engineering manager |
Senior engineer | Senior engineering manager |
Staff engineer | Director of engineering |
Principal engineer |
Collaborate with your team to define the expectations for each job title and the grounds for promotion to a higher position. Signals should not merely be checklist items but a set of demonstrated behaviors, unambiguous definitions of expected work product, and specific areas of peer feedback.
Avoid the temptation to have too many levels, e.g., senior engineer 1–6. Often, this is driven by compensation issues such as salary bands and equity distribution. Instead, work with your leadership team to develop wide and overlapping salary bands. It’s inevitable that people will want to figure out how to move up the ladder in order to increase their compensation. This, in turn, leads to overpromotion and level-jumping. Your goal as a leader is to reinforce that promotions are and should be about mastery of current skills and the acquisition of new ones. Emphasizing this concept is best done by separating the process from compensation.
Equally important is your interview procedure. First, you need to be able to explain the process clearly and succinctly to both your interview team and the candidates. A poorly prepared interview team creates a bad experience for all participants. Each interviewer needs to know the expectations of the role, what they are expected to assess, how to provide feedback, and how the final hiring decision will be made. Second, interviewing is exhausting and time-consuming for everyone, especially candidates, who are likely interviewing at multiple places at the same time. Explaining the end-to-end process early helps them better assess if they should make the time commitment.
While a recruiting team is there to assist in areas that can provide you leverage (such as scheduling and email follow-ups), you are still responsible for the outcome. They cannot, and should not, do everything for you. Many engineers may not respond to a recruiter but will do so for a head of engineering. Sourcing and screening (first- or second-round) candidates are areas where you can have the most impact. Building a healthy partnership with your recruiting staff will pay huge dividends in the long run.
Team composition
Keeping teams small and cross-functional is generally considered an industry best practice. While this is a solid guideline from startup to enterprise-level, the guidance often ends there. Just how small should a team be? Which functions should be considered part of the cross-functional team? Take the time to establish these policies from the get-go.
First, we need to establish the context for the team. The guidance that follows is primarily for a team that reports to a single manager, as opposed to a virtual team with matrixed-in members, such as a tiger team.
Teams should be no smaller than three people, excluding the manager. There’s no such thing as a team of one, so if you have any, you should move quickly to correct the situation. No matter how talented an individual is, there’s no team dynamic with a single person, and no incentives for them to reduce the inherent risks of working in isolation. A team of two has similar issues. At three people, there’s the minimum amount of structured communication and process required to form the basis of a team.
If three is the minimum size, what’s the maximum? In my experience, seven to eight people is ideal and 10 is the maximum. Beyond that, it’s difficult for a manager to maintain a solid sense of overall team health. A model that I find works well is to have a staff-level engineer, three senior engineers, and four engineers led by an engineering manager. Not only does this offer diversity of experience but it creates a built-in mechanism for mentoring. Staff and senior engineers should be encouraged to mentor the other engineers on the team. This, in turn, strengthens the overall team dynamic and builds up team identity.
Remote first
Remote working, though not yet widespread, is rapidly gaining acceptance. It’s also easier to implement for some startups (especially those based on open-source projects, which are inherently remote). However, many startups can face issues with onboarding early-career engineers or nontechnical coworkers who are accustomed to a co-located environment. If the work habits established in the team are already remote-friendly—a strong preference for asynchronous communication (email, Google Docs, GitHub pull requests), all meetings in Slack (real-time chat) or Zoom (video conferencing) with no one in conference rooms, and respect for time zones and nonwork hours— the experience will be that much better as you onboard new remote employees.
Ideally, the decisions around working remote should be made before the first non-founder hire is made, and certainly before the team approaches double digits.
Everyone has opinions about process, and most people seem to hate it. Some folks believe that process is put in place by managers to stifle creativity or get everyone to conform to a mediocre standard. Others just don’t like to be told what to do and how to do it. Even if someone claims not to have a process, they probably do. (It may not be structured or consistently communicated, but it exists.) Unfortunately, processes with those attributes do more harm than good.
My general rule of thumb when it comes to process is a play on Michael Pollan’s food rules:
Use a process.Not too much.
Mostly agile.