Imagine that you’re tasked with recruiting a development team to build a new product. What would that team look like? How big would it be? Who would be on it?

Well, you’d probably want a team that’s lean, efficient, self-sufficient, and highly productive. You’d also probably want a team large enough to deliver whatever is needed, but not larger. In short, what you want is a Minimally Viable Development Team.

I Want My, I Want My, I Want My MVDT

My MVDT would consist of 10 people:

Developers

Let’s start with developers. First off, why six? In my experience, 3 dev pairs* are just enough to make progress, absorb unexpected interruptions, continually clean up the code base, and most importantly keep up momentum. I find that it’s just too easy to break momentum with a smaller team.

Why is momentum so important? At the risk of stating the obvious, it’s important because people yearn for accomplishment. Nothing motivates quite like seeing stories fly off the backlog at a healthy clip. It’s invigorating and infectious, it creates a virtuous cycle of productivity, and it’s a lot of fun.

For my six devs, I’d have one tech lead, two senior devs, and three devs. Everyone is expected to write great code. Seniors are additionally expected to make major positive contributions to the code base (pioneering new technologies, spearheading significant refactorings, implementing necessary performance/scale optimizations, mentoring others, etc).

The Tech Lead is expected to do everything that Senior devs do plus he has the responsibility for the overall health of code. This means that he has to worry about things like code metrics, keeping the stack current and sane, and guiding the team through the trade-offs inherent in architectural decisions being made. He also gets the deciding vote in case of conflict.

Product Engineers

Next, let’s talk Product engineers. They’re primarily responsible for uncovering and refining user needs, expressing those needs in form of user stories, and verifying that the final product meets those needs. (I say “primarily” because ideally everyone on the team should be concerned about this sort of thing.)

Product engineers should have the necessary skills to uncover user needs: user interviews, prototyping, hypothesis testing, etc. Product engineers should also have the necessary skills to translate a need into product: analysis of complex business domains, information architecture, user interface design, visual design, and so on.

Finally, product engineers should have a complete understanding of the product. They should know the feature set inside and out, understand how different parts of the product work together, what external dependencies exist, etc. They should also know how various user personas interact with the system.

Test/DevOps Engineers

Last but certainly not least, we have the Test engineer and the DevOps engineer. Now, you can argue that the responsibilities covered by these two roles should be owned by everyone. After all, shouldn’t everyone test? Shouldn’t everyone worry about infrastructure and build/deployment pipelines?

Of course they should. For instance, testing should be deeply ingrained into the development processes. Devs should be writing unit and integration tests as they go along. Yet I believe that it’s still important to have a dedicated test engineer for two reasons.

First, test engineers provide a perspective which devs typically lack. I find that too often devs tend to think happy path and have a tough time uncovering edge cases and boundary conditions inherent in their code base. On the other hand, test engineers are great at finding ways to break software, typically via unexpected interactions and untested assumptions.

Second, the types of tests written by test engineers tend to be at a higher scope than those written by devs. While devs are typically concerned about verifying smaller units (via unit tests) and their immediate interactions (via integration tests), test engineers are usually concerned with verifying paths through the application (via functional tests).

DevOps is another area where it helps to have someone waking up everyday thinking about it. It’s good to have someone focused on optimizing the machinery which underlies the development process. It’s important for someone to constantly work on bullet-proofing the deployment pipeline, optimizing the use of infrastructure resources, maintaining the build system, setting up proper monitoring/logging/backups in production, and so on.

And yes, devs could do most of this as well. However, I find that even with the best intentions, devs end up doing the bare minimum to get things rolling, but no more. Optimization of the type I described above is rarely top of mind for devs because they’re (rightly) focused on feature building.

Final Thought

The Minimally Viable Development Team I described above is unlikely to work for everyone. It makes a lot of assumptions about the culture, the processes and practices used, and, quite frankly, the caliber of people involved.

It also assumes a certain level of maturity in the product vision. In other words, I wouldn’t throw a dev team of 10 people on an unproven idea because searching for a product-market fit with a full dev team is hugely wasteful.

 

* I should note that this setup obviously reflects my bias for pair programming. That said, even without pairing, you need a critical mass of devs to move things along.

You may also like:

tagged with:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got 4 comments so far. Care to add yours?

  1. Rick Jensen says:

    What scale of product are we talking about? I think your numbers are pretty close for most products, and having at least 1 person in each major role with lots of depth on the dev team will get you by for quite a while, but I think your ratio of Ops and UI people to devs is a bit off. Of course, these ratios would shift with the particular product domain, but I usually like closer to a 3-1 ratio for the Ops:Devs and UI:Devs.

    Having a higher ratio of UI-focused team members lets you shift some of the UI implementation onto them if possible / needed, and also is an extra buffer of user-focused attention, which leads to a better product overall. The higher ratio of Ops lets your devs offload some of the more infrastructure-oriented work onto the Ops folks, and also lets Ops have the additional depth to be able to be a bit more flexible and broad with what they can do. The extra UI and Ops person can also shift to help more with testing when needed.

    If you poach 2 of the devs and turn them into an Ops person and a UI person, you still have a dev team of 4, which would have 2 senior members and 2 junior members, or 1 senior and 3 solid juniors. This should still give you enough velocity to keep things moving along well, and make the team much more flexible / versatile, with the ability to easily add developers for larger products or efforts.

    • Alex Tatiyants says:

      Hi Rick,

      Excellent points, thank you very much for your comment. I do realize that “product” is an ambiguous term to use. What I had in mind was something with a common set of features (i.e. single backlog), running on a single tech stack, with a single pipeline. A web app, common set of APIs, collection of related services, and so forth.

      As far as higher ratios of UI or DevOps, there are certainly situations where that’s needed. Another point to make is that, as you add more product teams, people doing UI and especially DevOps work could potentially be shared between teams.

      Thank you

  2. itoctopus says:

    Hi Alex,

    Here’s my formula for the minimum viable team:

    - 1 team lead (developing + coordinating tasks)
    - 3 developers
    - 1 tester
    - 1 UX/design person (can be outsourced)

    Of course the numbers above are proportional to the size of the project, but for a medium sized project the above are more than enough.

    If you have a team of 6 developers you will risk incoherence especially if your project manager is not that good.

    Thanks for sharing…

    • Alex Tatiyants says:

      Thank you for your comment itoctopus. I think that, when it comes to how many devs you need, it probably comes down to how many concurrent streams of work you should have. In my experience if the team is unable to sustain 3 streams consistently, it causes issues. Now, since my preference is for pairing, 3 work streams = 6 devs. In your example, you can also sustain 3 to 4 streams concurrently.

Leave a Reply