“No matter how it looks at first, it’s always a people problem,” says Gerald Weinberg in his consulting classic, The Secrets of Consulting. When I join a startup as a firefighting CTO, the team is often focused on technology and processes. They overlook team composition. This is how I think about building a team to build software from a CTO point of view.

Difficulties for a CTO when building a software team

How do you know when you have a personnel problem? There are a couple of signs and questions you might ask yourself:

  1. What type of profile should I hire next?
  2. How can I beat the competition with my current team?
  3. Is my team good enough?
  4. Can my engineers ship faster?

Maybe you’ve tried Scrum but it doesn’t seem to work anymore. Sometimes, when asked, the team is talking about how the product needs to be completely rewritten from the ground up. Other times, you know you need to scale up the team, but it isn’t clear what skills to look for in candidates.

Factors and terms in hiring software experts

Let’s dive into the different terms you might hear and how they can impact decisions when expanding your startup.

Brownfield, Greenfield, Legacy, and Antiquated code

Software can have a long lifecycle. Because of this, some people focus their expertise on specific stages of that lifecycle. Brownfield projects are those that have existing code and systems. Users and customers actively access the system to perform their work. The opposite of this is a Greenfield project, something completely new and unused.

The way you approach these projects is entirely different. If you have an existing project, you’ll need people with skills in refactoring. Look for candidates that have experience launching a product and then maintaining it. People with expertise in maintaining legacy or antiquated systems will approach the project in a sustainable way.

Roles and titles

There are many different roles and titles in software development. What’s important is to think of people as wearing many hats, especially in small teams. This means that you need to identify the roles needed on the team.

The roles are then assigned to people (shared responsibilities). One person can have many roles. Each role is owned by multiple people. The job titles only matter a little bit.

Roles are like puzzle pieces and a new hire will be better at some and worse at others. Your goal is to figure out which pieces are missing and how they can fit together. Which role needs the most attention?

Reading tip: enjoy the benefits and services of a CTO without the cost of a full-time

IC and Manager

An IC, short for individual contributor, is someone who is creating the product. This could be a developer writing code, a product manager performing research, a quality assurance analyst running through a test book, or myriad other things.

Defining expectations for managers is important, especially with C-level executives or Vice Presidents of Engineering. Do you expect people with these titles to code? Make sure any job descriptions include that information.

Conservative versus progressive

No, we aren’t going to cover politics. Within each team, some people will resist change, focusing on stability. Others will focus on innovation and incorporating cutting-edge technology. The team needs this tension and both ends of the spectrum should be represented.

Structure of a software team

Now that I’ve explained some of the factors and considerations, let’s focus on the team structure itself. First, the rules.

Rules for building a software team

Rule 1: Minimum 2, Maximum 5

Our focus is on collaboration. To do so, we need a team size that encourages that. This means the team should be composed of two to five people. The minimum is obvious: if you have one person, you don’t have a team. The maximum is good because your team can split up into pairs in order to co-deliver work via pair programming or the like.

If you have a team of more people, you’ll find the team will naturally split up into smaller groups to get things done. It’s better to formalize this so that the next rules aren’t accidentally broken.

Rule 2: Vertical, not siloed

Teams need capabilities to fully ship functionality. This is called vertical shipping. This means one team can create an API and connect front-end code so that a customer can use it. They also make database changes and deploy the code. Finally, they can test the changes themselves, via automated and manual tests.

In the past, there were front-end teams, backend teams, and mobile teams. This creates silos of knowledge and requires teams to hand off work. This leads to a waterfall-like delivery that is rigid and incapable of adapting quickly to customer needs.

Rule 3: One thing at a time

Each team must have one topic at a time. The cost of context switching is incredibly high, and managers consistently underestimate it. If I’m working on something and you are working on something else, when I come to ask you a question, I’ve just wasted a bunch of time.

The reason is that I’ve interrupted any deep flow you might have enjoyed. However, if the entire team is focused on the same topic, the cost of context switching is reduced. Prioritization changes also have an impact here. So if you need to change priorities, allow the team to finish the current task.

There is a built-in synergy between small teams and focusing on one thing at a time — if you properly size your tasks. When team-wide tasks are days of effort or smaller, then you will have better transparency and predictability surrounding their work.

I like to think about a freight train arriving at the station. A crane (your team) takes the first freight box and deals with it. Another crane (Team B) can deal with the second one. The manager’s job is to line up the freight so that each crane spends a couple of days (or fewer) unloading, never longer than a week. Then the train pulls forward and the process repeats itself (in a sustainable way).

Responsibilities

It’s important to define the responsibilities in a team. Again, this is based on roles instead of titles (or specific people). Start with a simple description of the different types of roles that individuals might take up, such as Engineer, Marketer, and Product manager. What is the key outcome this person will enable?

Then for each role, define a detailed description. This is similar to the text used in a job advert. In fact, I find myself copying and pasting the existing role documentation when opening new positions. If needed, I also define seniority levels so people can see the difference between junior, medior, and senior roles. During assessment periods, this list can be used for self-evaluation.

Avoid documenting traditional Scrum roles such as product owner. Instead, focus on the responsibilities that are necessary to build a product. What are the outcomes needed and who will oversee that those things occur?

Example structures of a product team

Free Range Management and Extreme Autonomy

I’m a huge proponent of pushing responsibility deep in the organization, to those working directly with solving problems. They are the best people to make decisions since they have all the details. My job as a manager is to provide context, prioritize work, and prevent distractions.

This is hard, so I’ve written a book (along with Andreas Creten!) to provide you with a practical, step-by-step approach to creating an environment of extreme autonomy. We call the structure Free Range Management.

When it comes to structuring your team, the key is installing the right feedback loops. This is how people (and processes) improve. Many companies pick up a form of “Agile” and it doesn’t seem to work at their organization. This is because processes are never one-size-fits-all. It’s all about experimentation and continuous improvement.

Beware of some of the following structures and focus on how your team can truly become agile rather than adopting some “agile theater” — in other words, don’t worry about following a specific structure or processes, but carve out time to reflect on what really works. After all, you aren’t putting on a show.

Scrum

Many teams have some experience with Scrum, a formal framework based on the Agile Manifesto. Daily communication and retrospective moments are just two structures provided by Scrum that help enforce good behavior, especially for immature teams.

However, there are also downsides, such as its rigidity. Instead of embracing the core principles of the Agile Manifesto, some teams continue to use Scrum processes that no longer serve them. Buyer beware.

Team Topologies

As teams grow to become teams of teams, there is always the question of who works on what. Team Topologies answers that question. Matthew Skelton and Manuel Pais define four team types and three interactions. If you’ve got a mid-sized or larger organization (20+ engineers), definitely consider their approach.

One team type is the stream-aligned team, those that deliver primary value to customers. Enabling teams help the stream-aligned teams learn new skills related to specific technical or product challenges, usually interacting via collaboration (cocreating) or facilitation (mentoring).

Subsystem teams focus on owning complex technical domains in order to reduce the cognitive load of others. They interact by providing a service; the stream-aligned team is their customer. This is similar to a platform team since they both create internal products that propel the stream-aligned team forward.

Shapeup

The core of Shape Up, by Ryan Singer, is betting. Small senior groups shape a rough solution, something that provides implementation teams room to maneuver. Projects are timeboxed based on risk appetite, revenue potential, or the maximum cost. The team can then tailor the solution based on this limitation. After the time is up, generally 6 weeks, the work is either complete or the company needs to extend their bet.

The system is nice because you are forced to do just enough research to make bets valuable while still leaving room for implementation teams to control the final outcomes. It also skips estimation, and conversations revolve around the tradeoff between exploring the unknown versus making things happen.

Sociocracy and Holacracy

Truly mature teams can self-organize. One way to do this is to create a completely democratic environment. Holacracy, a form of Sociocracy, is a framework to manage this. It’s focused on circles (groups) of roles (not people).

Each circle has a core responsibility and someone that reports on governance actions. Concentric circles are used to delegate responsibility. People take up roles for which they are well-suited, and they can participate in multiple circles. This is a complex system, but it can pay off for the most mature teams, especially ones where the purpose is clear.

The Fractional CTO explained
Fractional CTOs make more and more sense. Check out what a fractional CTO is and how you might benefit from one. Also discover the costs involved and what skills to look for when hiring one.
madewithloveSteve Tauber

The purpose of the team

A main consideration when structuring the team is based around what work they will do. First, let’s determine the type of complexity the team is dealing with since this will ultimately impact the seniority of people that must be staffed.

Product complexity

Simple projects

Non-complex projects are the easiest, so let’s look at that first. What’s the right ratio of senior and junior people? Ideally, senior people are focused on mentoring others and pair programming to help individuals level up their skills. They also need time to weigh in on architectural discussions and deal directly with the most technical implementation.

The right ratio depends on the skills of the senior people involved. If the project involves lots of refactoring of older code, it could be very time-consuming to make progress. I see the best teams spend about 50% of their time working on improving existing systems, upgrading dependencies, and creating scalable infrastructure.

This means you might have a 1:1 ratio between junior and senior developers. Using the pod structure above, a small team might consist of 1 junior, 1 medior (independent), and 1 senior engineer. A large team could include 2 juniors, 1 medior, and 2 seniors. Note that we never see the number of juniors outnumber the number of seniors.

Complex projects

With complex domains or advanced technical architectures, it can be more difficult to build the product. We still want to include junior engineers because there is a reduced payroll cost, and it gives us insight into how complicated our solution is. We never want to build complicated stuff, even for complex problems. If the junior engineer doesn’t understand an aspect of the code, the solution needs to be rethought.

In this case, a pod could consist of 2 seniors and 1 junior. Since the maximum number of people is 5, the team could be composed of 3 seniors, 1 medior, and 1 junior.

Complex interfaces

A third situation exists: when the domain is simple but there are complex interfaces. This is often the case for dashboard-like applications. In this case, proper UX research is needed so that as solutions are designed, the complexity is appropriately extracted and defined. In this case, the front-end focused developers in the pod are likely all very senior.

Double diamond design

If you perform proper discovery work, you probably think about focusing on a specific problem to solve before settling on a solution. The British Design Council has formalized this in a structure called Double Diamond Design.

It starts with divergent thinking in the problem space (problem research) and then convergently arriving at a problem definition. Next, solution ideation occurs (divergent), followed by solution delivery (convergent).

Many teams make the mistake of handing off work once a solution has been defined. This causes problems since engineering needs a deep understanding of the problem and the context that goes with it.

Engineers must be included during solution ideation. Shifting their involvement left helps to create better outcomes. Your team structure needs to account for this, a key area where Shape Up (above) hits the mark.

When you have teams of teams, this consideration can manifest by embedding dedicated product-minded people inside the pod. I’ve found it useful to assign specific bounded contexts to each pod. This is a great way to align product and engineering while ensuring that epics aren’t too wide.

Product or technical focus

As the organization grows, some teams might become focused on specific technical topics such as those described in the Team Topologies approach. Understanding the purpose of the team will also help inform you who to hire.

For example, suppose a SaaS team noticed an opportunity to improve Activation, a part of pirate metrics. They decide to run some experiments around onboarding. This team is very product-focused so they will probably be composed of people with specific skills such as front-end development, A/B testing expertise, and, perhaps, even a deep understanding of low-code solutions.

This composition would be very different from a team that is building a deep technical feature that sits behind the interface. Perhaps the product is a recipe generator, powered by AI. The team that focused on researching and building machine learning models should have a very different make-up.

Team composition

We look for people that are T-shaped, those that can add value across multiple roles. Consider the areas where you need expertise instead of competency. Oftentimes, generalists create more value.

Strategic versus tactical roles

Teams also need oversight, and that can come in many forms. We’ve written a lot about how teams evolve and the various titles that might be assigned. Regardless, there is a strategic and tactical role to consider. Sometimes, this is not clearly defined, and a team might not have a strategic thinker to help them.

When hiring, think about who will be responsible for setting goals based on context and then communicating that to the team. Make sure this role is explicitly represented. It’s possible that responsibility lies outside the team. If that’s the case, someone on the team, a lead, needs to take responsibility for tactical execution.

Build the right thing

The team needs guides. Their job is to create context, help with prioritization, and prevent distractions. Guides have many titles such as CTO, CPO, Product Manager, Designer, Researcher, or even Data Analyst. The goal is the same: create a clear path.

Now comes the hard part, doing this well. Without key skills in performing data-driven research, managing a product, staying close to customers, and organizing the work, the product will suffer.

I often come across engineers who are very technically savvy but lack fundamental organizational skills. I’ve also seen product managers that don’t know how to interview customers in an unbiased way.

Build the thing right

Next, the team needs to roll up their sleeves and deliver. It’s all about execution. The individual contributors here have titles such as Engineer, Programmer, or Designer.

A Free Range worker demonstrates communication and writing skills, shares knowledge freely, masters their tools and productivity, and cultivates others through mentorship. I also have a strict No Assholes policy. Your hiring pipeline should actively test for and evaluate, not only the hard skills, but soft skills too.

If you aren’t an expert on all the roles involved in the full product lifecycle, consider working with an advisor or external recruiter who can help you source and filter candidates for these roles.

Implementing this advice

With a pod — two to five people — shipping vertically, you’ll reach new heights of productivity. To do this, you need to understand the purpose of each team by knowing what type of work they will be doing and how much experience is needed for each job.

The biggest challenge you will encounter when implementing this advice is that there is no perfect team. Teams are composed of people and people are inherently flawed. This is why I focus on creating environments where failure is acceptable since it is inevitable.

"It is possible to commit no mistakes and still lose. That is not a weakness; that is life." Captain Jean-Luc Picard (played by Patrick Stewart)

In practice, this means that you must carve out time to regularly reflect on your processes and nudge and modify them as needed. It also means that you must design your team around the average.

It is incredibly hard to hire the top 1% of people for each and every role. It’s only moderately easier to hire people in the top 25%. Your processes must work for everyone on the team, especially those that will not follow processes perfectly.

Additionally, each and every team is different. Create a map of the existing people on the team and figure out where the gaps are. Returning to the puzzle analogy: you need to find the missing pieces and make sure new hires add to the picture.

In today's fast-paced world, it's essential to foster a culture of continuous learning within your organization. Especially as a CTO, you have the power to build and shape a happy, autonomous, productive, and impactful team.

To create that learning culture, it's crucial to set clear goals, provide regular feedback, and offer various learning opportunities. You are not Spotify or Netflix. Their processes solve the problems they’ve encountered. Your processes need to solve the problems that your team has encountered. This is how a CTO builds a team.

Also read: Why would your startup benefit from having a Fractional CTO or CTO as a Service?