How Do Tech Teams Evolve?

This post is part of a series that I’m doing to respond directly to reader questions.

Today’s question is “How do tech teams evolve as the company grows? How do I go from my 1-2 person team today to a more full-blown development team in the future?”

There’s no hard and fast rules, but generally the evolution of your team will go like this:

  • Phase 1 – Small team of “people who can do anything and everything”, almost no structure
  • Phase 2 – Some additional specialization and adult supervision, a bit more structure
  • Phase 3 – Highly specialized roles and formalized structure

Let’s explore each phase in a bit more detail.

Phase 1

As I talk about a lot on this blog, the early days of a company’s lifecycle are critical. You can’t have people who work slowly or are focused on titles and hierarchy on your team. You need people who Get Stuff Done. If there’s a test to be written, they can do it. If there’s automation to be built, they can do it. If there’s support tickets to be answered, they can do it. You get the idea. No one is above any kind of work.

In terms of specialization, the only specialization you might have is if you have a mobile application and a server-side application. It’s still pretty uncommon that developers do both of these things well. The other area of specialization might be something like a data scientist or subject matter expert. However, if this is a key part of your business, having a data scientist who can also do other things is critical. No prima donnas.

You probably have a CTO, but the CTO is in the weeds every day alongside everyone else, cranking on the code and ensuring that you’re building things that won’t fall apart. They provide direction and guidance, but if they have to spend a lot of time managing you either have the wrong leader or wrong team members.

Possible team makeup:

  • CTO / technology leader
  • 1-2 very strong generalist developers

Phase 2

As momentum builds, you’ll start adding people to the team. These people should still be able to dig into any problem or issue with the rest of the team, but they may have more specialization. Perhaps they’re more of a front end developer vs. back end, and they do the kind of work they’re most comfortable with 80-90% of the time.

It’s critical during this transition that you don’t let anyone get too siloed in their work. Make sure that there’s still cross-discipline sharing going on within the team. You have to always be protecting the organization from people transitioning in and out.

You still want a relatively flat organization, but you might start to establish seniority on the team for decision-making purposes. For example, you might hire a junior backend developer who needs to work under someone more experienced as a mentor.

You might consider bringing in a QA resource at this point, at least part time, to aid with any human testing required. However, remember that you want as much automation in testing as possible.

Possible team makeup:

  • CTO / technology leader
  • 1-2 senior devs with some area of ownership
  • 3-4 junior devs, 1 with DevOps focus
  • 1 part-time QA only if required

Phase 3

At some point, you’ll need to bring in someone who loves the process part of building software. In most companies this role is called VP of Engineering or similar. These people have a passion for building scalable applications and love digging into the minutia of how everything is done. They will often come in and rip a bunch of stuff out that the team did previously because they understand how critical each decision is from here on. The company has hit a velocity where it’s obvious that the application will need to support lots of users. It’s time to get serious.

Typically these people show up when you hit Phase 3, which I put at around 10 developers or so.

Also typical in Phase 3 is that you introduce more formal leadership and start breaking the larger team into smaller teams of 3-5 people. You might have a mobile team, a backend team, and so on. As before, you want to move people in and out of different teams to ensure that there is sufficient knowledge transfer between all of the different disciplines.

This is also a great time to start identifying who the leaders are among your team. Remember that the leaders are often not the best technically. Often the best technologists are not great leaders of people at all. Be wary of promoting people to leadership just because they’re the best developers.

At this point the CTO’s role becomes much more of a strategic position. They are setting direction, making critical decisions and helping with product. Their job is to stay 12-18 months ahead of the team in thinking about direction and communicating where the business is heading to the rest of the organization. They might still be doing some coding, but they’re not typically in the day to day work nearly as much.

Possible team makeup:

  • CTO / technology leader
  • VP of Engineering
  • Multiple team leads with areas of specialization
  • Senior developers with subject matter expertise (AI, data scientist, etc.)
  • Multiple junior devs under each team lead
  • QA leadership established

Once you hit Phase 3, you really have to find your stride as to how you grow the organization. You’ll be hiring all the time, and figuring out the mix of experience will be critical. There’s no secret formula. Every organization is different in how much autonomy vs. structure is pushed down.

I highly recommend reading about Spotify and Netflix. They are two organizations I admire, and they share freely about how they build their organizations and development culture.

Above all, remember that if something’s not working for you, change it and change it quickly. It’s OK to make mistakes in growing your organization. It’s not OK to let those mistakes linger.