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!
People
Alignment with technical founders
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.
Process
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.
The first part is fairly straightforward. Work with your team to identify a process to use and help them implement it. Start with an existing process like Kanban, Crystal, or Shape Up. Realize that these methodologies are not intended to be static. Conduct regular retrospectives with your team to identify what’s working and what’s not. If something isn’t working, change it! Teams tend to fall into the trap of treating these methodologies as rules, when in fact they are frameworks that can and should be modified to meet changing needs.
Just as we often get excited about new software tools, some teams get overexcited about new processes and attempt to use everything at once. Resist this urge: Start small and slow. For example, if you choose Kanban as the basis of your process, begin with a minimal number of columns on your board, like “To Do,” “Prioritized,” “In Progress,” “Blocked,” and “Done.” These columns cover most of the states you’ll need during development. As you progress, you’ll discover whether you need additional columns, but make sure that additions or changes can be justified. Similarly, start with either no or very few work-in-progress limits. The fewer concepts that the team has to absorb in the beginning, the better. Add to the process incrementally as the team identifies gaps that need filling.
“Mostly agile” is meant as a warning to prevent your process from becoming your product. All too often, people become dogmatic about process execution. Excessive time is spent debating minutiae and tailoring the process in ways that don’t help you deliver your actual product better or faster. Periodic process retrospectives can limit these discussions while also creating space for them without impacting the flow of product delivery.
Another useful trick to help mitigate this behavior is to avoid acknowledging the process directly. For example, you can implement Kanban without saying the “K” word. Talk to your team about making work visible when introducing a board. Explain why it’s beneficial to limit the amount of work currently in progress. Part of the reason that Agile (with a capital “A”) has acquired a bit of a negative connotation is due to the focus shifting toward the monetizable mechanics of the various processes, and away from the agile (lowercase “a”) principles that form their basis.
Product reviews
One of the best ways to communicate status, especially for software, is to demonstrate the work in progress. While many teams hold demo days, a product review (used by the original Adobe Creative Cloud team) encapsulates more of what we want to achieve from this meeting. The minimum goals for a product review are:
Demonstrate new product features (complete or almost complete) to the whole organization.
Answer questions and solicit feedback about what’s being built.
Capture feature requests and new ideas generated during discussion.
Get a temperature check from key stakeholders (usually the founders).
As startups grow, it’s easy for silos to form. This is generally more a function of focus than malice, but as a result parts of the organization don’t know what the rest are doing—or at least don’t get all the details. Product reviews counteract this when they’re a collaborative effort between product management and engineering: The product manager schedules and leads the meeting with a focus on setting context, and the engineers who worked on the features demonstrate them. Both answer questions as appropriate. Record the product review so that people unable to attend can watch it later.
Product reviews, like Kanban boards, make work visible. If you’re making progress, everyone will see it, which boosts morale. It will also be clear if progress is stalling, and others may be able to help unblock things. Founders—who are often busy raising money and talking to customers—appreciate having regular, consistent, and concrete updates on the product.
Engineering reviews
Once you have multiple teams working on different product areas, there’s an increased risk of teams becoming insular. Some of this is understandable—teams likely have limited bandwidth, and it’s easier to focus on local concerns than global ones. If teams have no work in common, the lack of familiarity with what’s occurring in the engineering organization as a whole can be detrimental.
Similar to product review meetings, engineering review meetings help negate the effects of silos. The main difference is that engineering review meetings are conducted by the engineering organization, for the engineering organization. A typical agenda may include one or more of the following:
A walk-through of a design document that’s ready for review.
A technical deep dive into the implementation of a product feature (preferably before it’s shown at product review).
A solicitation of feedback on various options for a feature being designed.
Engineering reviews are intended to drive high-bandwidth technical communication with engineers across the entire organization. When there’s a venue for engineers to go deep on very specific technical details, product reviews can focus on more customer-centric concerns. If other teams want to attend engineering reviews and feel excluded, communicate broadly that engineering review is intended as an engineer-to-engineer mentoring and coaching meeting, and that a smaller attendee list facilitates that goal. Offer to provide notes and a recording of the meeting to the entire organization, and encourage active participation in product review.
As the organization grows, modify engineering reviews as needed in order to help them scale with your company. This can involve changing the cadence from monthly to bimonthly to quarterly, or changing the format to more closely resemble a technical brown bag meeting. So long as the primary goal—facilitating communication and awareness of technical decisions within engineering—is preserved, there’s plenty of room for creativity with the format.
Release cadence
Your release cadence provides a heartbeat to the organization and your customers. It can be an effective tool for setting and managing expectations for delivery. This should be distinct from your build cadence, which should mostly be continuous. A build is an essential component of a release, but not the only one. Other components that need to accompany a new product version include user documentation, release notes, marketing-website updates, and social media announcements.
While the adage “Release early, release often” is valid, it’s diminished when the focus is on output as opposed to outcome. It’s essential to determine how early and how often (and to whom). If your product is aimed at consumers, you can and should release more frequently than you might for an enterprise product. Frequent releases exercise the delivery machine and help reduce overall risk. Time and again, organizations with large gaps between releases have difficulty getting future releases out the door.
If frequent releases help reduce risk, then why wouldn’t we want to have a faster release cadence for enterprise products? Think about the customer. In many large enterprises, there’s sufficient friction preventing customers from consuming releases as quickly as you may be able to produce them. Compliance and security processes can be major factors, too. If your product is on-premise software, several other factors come into play. Do your customers have the human bandwidth to upgrade your software? Are there breaking changes that would impact currently functioning workflows? Is the update going to provide sufficient value?
One approach to achieve balance is to have both internal and external releases. Internal releases are generated more frequently and delivered to internal customers, such as product management, sales engineering, and support. The primary function of these internal releases is acceptance testing, with the additional benefit of helping engineering reduce risk. An external release, then, simply becomes an internal release delivered to customers.
Let’s put these pieces together. Your product is an enterprise application that’s delivered to customers both as an online (SaaS) and on-premise application. Engineering configures the CI/CD system so that merges to the master branch deploy the product to the preproduction environment. The team primarily works on feature branches, and plans to deliver an internal release of the SaaS product every two weeks and the on-premise version every six weeks. The on-premise version is a superset of the SaaS version, and the additional time is for integrating and testing components that aren’t used in the SaaS version.
All new features are developed behind feature toggles to allow selective access. For the SaaS version, the organization wants to do monthly external releases. Product management approves which features have passed acceptance testing, and a percentage-based rollout of those features starts. For the on-premise external release, the organization chooses a more conservative quarterly release. At the beginning of the last month of the quarter, the previous monthly SaaS releases’ features are aggregated and bundled into the installation packages for the on-premise external release. The rest of that month is allocated for additional testing and documentation updates.
The key ideas are:
Separate builds from releases.
Release early and often.
Distinguish internal releases from external ones by convention.
Tailor your release cadence to the needs and expectations of your customers.
Developing this discipline early on will help both your product and your team scale as they grow in size and complexity. Teams that neglect these processes often have difficulty implementing them later, and pay a high cost at the expense of value-added features for customers.
The end of the beginning
Startups are hard. Engineering leadership is hard. People are hard. And things constantly change. These factors make any small successes you experience even more satisfying. Your work is important, but so are your relationships, your physical health, and your mental health. Pay attention to these! (You are no good to anyone if these start deteriorating.) Balance is important: When you achieve it, you’ll be able to tackle the most difficult challenges—from startup to enterprise.