In an ideal world, startups progress through inflexions of growth and success as customers require more enhancements or features that are needed on a larger-scale. The startup’s engineering team has to grow to address these different dimensions and do it with increasing pace and predictability.
Before we dive into how to scale an effective and successful technology team, it is wise to first touch upon how a typical CTO or Technical Founder role develops at the various stages of company growth, as this reflects the changes of a growing tech team.
The Evolution of the CTO Role
As your team grows and evolves, from Seed to Series A and beyond, so does your role as a technology leader.
1 Engineer
In the initial stages of a startup, the tech team is likely to be made up of one CTO (or Technical Founder) who is an engineer fully dedicated to building an MVP.
2-10 Engineers
Following a successful round of Seed funding, a CTO typically spends less time coding (about 60% of their time) and starts spending time recruiting a small handful of engineers. Practices such as regular 1-2-1s, sprint planning and daily standups become commonplace.
11-50 Engineers
Coordinating work within a larger team becomes more difficult, and at this point, a CTO has to make a binary choice: stay on the technical path and hire a professional manager (e.g. a VP of Engineering), or give up coding and focus on the management of the team.
51-100 Engineers
If the CTO has chosen to focus on the people management of the team, the role is likely to focus on being the best manager as possible to the tech team, training other engineering managers to do the same, as well as recruiting.
100+ Engineers
A CTO at this stage will be focused on building the leadership for front- and back-end engineering, testing, UX, product management, infrastructure and delivery whilst considering global vision and strategy to ensure that the business’ competitive advantage is retained through the use of technology.
So, as your startup grows, what areas do you need to consider and nail if you want to be as effective at 50, 100 or 500 people as you were on day one?
Watch Out for Conway’s Law
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin Conway, 1967
Conway’s law is an applicable adage for many environments, particularly for software engineering teams. As teams across businesses grow and organise themselves to deliver solutions, there is a tendency to repeatedly design and build systems that mirror the structure of the company itself. The basic idea is this: your organisational structure drives a specific software architecture. And your software architecture drives a specific organisational structure. People who work closely together and communicate regularly will create software that reflects this and vice versa.
For example; take an invoicing department, there will be an invoicing system; the finance department has a finance system; notification areas will have a notification system, and so on. All of these systems will combine with one another in a way that reflects the way these organisational departments communicate.
For a tech team, the software and its underlying code will resemble the communication and organisational structure of the group that produced it. How you organise your teams will have a powerful effect on the software you produce, as well as your resulting architectural and production outcomes.
In a First Round Review, Adam Pisoni, Co-Founder of Yammer, revealed that he originally oversaw a small team of engineers building an initial product. Every engineer worked on the codebase, but as the company and engineering team grew, that original codebase became progressively unmanageable and monolithic, just like the team. Only when the team was broken down into smaller teams were they able to break up the codebase into smaller services intelligently. So, for a positive effect, you need to organise your team so that Conway’s Law works to your advantage.
Case Study – Etsy
In 2007, Etsy’s engineering team was split into three siloed teams:
- Devs, who wrote code.
- DBAs, who wrote SQLs.
- Ops who deployed code and touched product.
Etsy was still a startup at this stage, and they made a big bet on ‘Sprouter’ to address their scalability problems (the Stored Procedure Router). Sprouter was originally designed to help make life easier for developers and database teams, as it was easier to scale than the current database.
As Ross Snyder, a senior engineer at Etsy said during his presentation at Surge 2011: “Sprouter was designed to allow the Dev teams to write PHP code in the application, the DBAs to write SQL inside Postgres, with Sprouter helping them meet in the middle.”
Sprouter was situated between their front-end PHP application and the Postgres database, centralising access to the database and hiding the database implementation from the application layer. However, adding any adjustments to business logic caused significant friction between the developers and database teams. For nearly any new site functionality, Sprouter required DBAs to write a new stored procedure. Consequently, every time developers wanted to add new functionality, they would need something from the DBAs, which often needed them to navigate a lot of bureaucracy; resulting in work sitting in queues, meetings, longer lead times, and so on. Soon, almost every deployment became a mini outage.
Key Learning
This is a perfect example of Conway’s Law at work; Sprouter was still a silo architecture, which resembled the team that they had. The resolution? Cutting Sprouter and building an object-relational model so that developers could directly make changes to the database without needing DBAs. The level of communication and coordination required decreased. Reliability increased.
So, what does a cohesive and highly functioning software engineering team, unencumbered by Conway’s Law actually look like? Well, every team should be different – they should be building different systems on different software stacks for different businesses, most likely with very different principles and cultures – and most critically of all, they should be building for a very different and individual customer.
Organise Your Team Structure Early
Following on from Conway’s Law, the more team members you hire, the more important it is that you organise them consistently. Typically, vertical teams are preferable in most situations; however, there are circumstances that a horizontal structure works well, such as Buffer. Regardless of your structure, the crucial thing to formalise is the role of management. If you neglect this, everyone thinks they’re a tech lead, which is never conducive.
Don’t be tempted to promote your top coders to managers, as manager roles revolve around people, not about code.
Building an Environment to Flourish
Teams thrive when they can grow and work in a safe and supportive environment, particularly a culture that considers setbacks and failures as fuel for future improvements. In other words, a blameless culture. This is challenging to attain for teams working on highly available or visible products, but it’s an important foundation for success. There’s a great quote from Peter Drucker that summarises this well:
People who don’t take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year.
Peter Drucker
It is important to note that a blameless culture does not mean a zero pressure culture; there’s an important balance between the two. Suitable levels of pressure on engineers will drive them to perform optimally and energetically, but you need to know your team well enough to gauge when the pressure is counterproductive. To strike this balance in your team, you need to be clear about what is expected of them and set an explicit and congruous strategic and technical direction that underscores your aspired outcome and the guidelines around how to operate.
Know The In’s And Out’s Of Your Team
As your team increases in size, it becomes more important to understand its psychology and how to utilise your human resources successfully. Whether your team is 10 or 50 engineers, you have a duty and obligation to each engineer to support them and develop their careers. This begins with knowing every team member individually and aiming to continue 1-2-1 meetings with every engineer. Although this is likely to become less regular as the team grows, you should still prioritise this time and only rearrange or cancel with very transparent reasons well in advance of the conversation. This is a reflection of the growing priority of people management as the CTO role develops.
Consider what formal and informal communication opportunities there are to connect with your team. Formalise communication with tasks such as architecture reviews, code reviews, and demo days. When the tech team passes the 12 person mark, you’re no longer having lunch together, you might not even work on the same floor, so you need to get creative for informal communication such as socials or lunch and learns. At Yahoo, one manager started a Three at Four initiative – three talks by three people (two technical and one nontechnical) at four o’clock every Friday. By investing in this time, it will serve you and your team well into the future.
Although engineers should feel like they can ask for guidance and mentoring from you, they should also feel happy to ask this from others, such as senior engineers. So, focus on coaching your senior engineers to develop them into trusted and empathetic mentors, and that the team knows that these senior members have your total trust and support.
Hiring is Your Biggest Investment
Also reflected as an increasing priority in the later stages of an evolving CTO role, hiring becomes an increasingly critical task (also one of the most challenging), so give it appropriate precedence by ensuring you have the time available to concentrate on it. Generally, it is advised to hire for the person, and not for their skills alone. New skills and competencies can always be learned, but you can seldom change a person’s underlying principles, personality and attitude.
Top Tips for Hiring
- Diversity is important – both in terms of gender, ethnicity, etc., but also in experience and career history. A team composed of computer science graduates with 12 years of engineering experience working on your product is not a route for success. Diversity in ideas, experience and background is an important consideration.
- Don’t be intimidated by hiring people whose technical knowledge or experience exceeds your own; you shouldn’t be the smartest engineer in your team!
- An obvious, but important consideration, hire candidates that you can see working well with the team. The ability to form good working relationships with each other will notably reduce the unavoidable impact on team efficiency that follows new additions.
- As your team expands, senior engineers will also take on hiring, but people don’t enter a role knowing how to hire; you need to intentionally set them up for success by treating it like any other skill and properly training them for it.
- Set up structured interview panels to interview candidates, so a variety of questions and judgements are made.
- Don’t get stuck with a “meh” hire – this the candidate that no one is particularly championing, nor strongly opposing. The “meh” hires results in mediocrity everywhere.
- Here’s a great example of how Amazon mechanises their hiring process to make better decisions.
Write a Cultural Manifesto
As a CTO, you need to understand your role and influence in the wider company, which will vary significantly depending on the type of business. In a technology company, technology leaders have a weightier voice of authority than in more of a traditional media or retail-driven businesses. Use your understanding of your own playing field to set one for your team. If you fail to understand your own role or influence, then this can manifest as a notable roadblock to success as engineers will be uncertain on their own mission and sphere of influence, or how you best assist and support them.
According to Kevin Scott, CTO at Microsoft:
The single most valuable management tool while you’re scaling your engineering team is something I call a cultural manifesto”…“This is a document or a set of materials to help your entire engineering team get on the same page about how you make and operate things, and how you function as a team.
Kevin Scott, CTO at Microsoft
The heart of any united team is a small set of shared understandings. When you’re in a state of hyper-growth and building products to go to market as fast as possible, without solid recorded opinions, everyone will have differing and incongruent beliefs about how they make products, how they operate, and how they function as a team, causing cracks in the team’s foundation. Here are some tips on creating a cultural manifesto:
- Don’t wait until breaking point to draft a manifesto – start proactive conversations around culture early on.
- Discuss and revise your manifesto regularly to refine the engineering culture.
- Clearly articulate the role of the engineering team within the wider organisation.
- Commit to working out your values collaboratively, together with your team. This will not only give them ownership of their values, but it will ensure that the values and views are commonly held – it’s not something that you can just communicate over Slack!
Collaborating on Values
Start brainstorming with your team. Get together and spend an afternoon creating post-its of ideas and discussing what engineering stands for at your company. Hopefully, this will give you a shortlist of 30-35 draft culture values. If people have similar thoughts, that’s a good sign. Then, you should work to consolidate the draft culture values into a condensed number of 20-25 values.
In groups of 15-20, vote on the values in a workshop. Write the culture values down on a whiteboard or large piece of paper and ask everyone to add tally marks to choose their favourites. Next, split into groups of 2-4, and ask each group to create presentations on the most popular choices and present them back to the cohort, as values are usually just a few words written down, so they need to be brought to life through interpretation. This should bring you down to 12 draft values.
Finally, choose your final set of values by using something like a Google Form or a Doodle poll and ask people to vote on which values resonates the most with each individual. This will then eliminate a few ‘correct’ but less popular thoughts.
At the end of this process, you will have a set of values that will not need further convincing or buy-ins from your team as you’ve taken the time to involve everyone in the process. These values might diminish as the team grows, so revisit this process periodically with the team.
Conclusion
Over the course of a company’s growth, the engineering team can drastically change, and it’s your responsibility to be able to sense when the wind shifts and manage the structural adaptations through the team. Building technology at a company that is scaling quickly is incredibly difficult, so if you’re a tech leader, you must start with addressing your leadership role, from engineer to manager, to reorient your team’s collective mindset through initiatives such as cultural manifestos, hiring best practices and supportive environments, to help your team thrive.
