Hopefully by now we are aware of the context our team is to be built around and it’s time to put the wheels in motion.
The absolute first step is figuring out which team we need to aim to, if we are creating one from scratch or updating an existing one. This is deeply correlated with the context and all its variables. Most content about “the perfect software team composition” fails to take into consideration exactly that. You’ll often see roles as Technical Lead, Product Owner, Analyst, and the list goes on. I do agree that many of these roles are “essential” to make a perfect team but it leaves out all the other factors.
I’m a strong believer that perfect means perfect fit for the context and limitations at hand. Not every business can aspire to have a blank check to achieve utopia. Let’s start by breaking down the classical roles and their relevance.
Developer
The meat of the software development team. The main contributor and producer of deliverables. One can have solely a team of developers and spit out a project or product, however, with a lot of caveats.
Quality Assurance
Testing is one of the most important nodes in the development chain. It adds up to overall quality and security of the deliverables. You can never test enough. I’ve managed many teams without QA, and it’s definitely possible, however, not advisable. End of the day some form of quality control will always need to be done, but in a poorer fashion and done by (probably) either more expensive roles, less suited roles, or both, to a limited effect.
Project Manager
The daily conductor of the what and when on most project. It manages the schedule, budget, and scope to keep the project on the track “someone” decided it has to be in. This role can be split up into other more specific ones, as the classic scrum master role and many more. Much like the QA, this is also a role that needs to exist in some shape or form, even if embodied by someone else in the organization as there has to be someone calling the shots on “what” and “when”.
Product Owner
A form of strategist and planner around a product of part of a product. The PO defines the priorities, goals, backlog and makes sure all of the requirements are gathered and understood before implementation or actual daily planning starts.
Unlike the Project Manager, this role is not as common or even necessary on a few scenarios. Small product teams often have Founders or other management role defining these (although sub-optimally). Service-based companies often don’t include these in their teams as the product vision is not managed by them.
Technical Lead(ership)
This term encompasses a whole plethora of leadership roles. Depending on the size of the teams and product, more or less technical lead roles can come into place, each with different scopes and interventions.
The more “higher up” the leadership is, the less hands-on it gets and the more involved with decision making it becomes. These are key roles for many different reasons, however, these are most of the times not involved with “producing”. Instead, they deeply impact the productivity and deliverables of the biggest engine in the team, the developers.
Which team do I need?
Knowing the bulk of the classic role-types we have in most software development teams (there are oh so many more), now we need to figure out which combination of these are suited for the goals we want to achieve.
Here is where it gets complicated. All the factors that go about defining our context start to come into place here. Budget, location and culture are pretty straightforward to apply, so I’d focus on the type of problem we’re trying to solve with the team we are assembling. To do that I’ll immediately split off between Product and Service.
Product
Product teams, depending on the stage, can be very different from Service teams. A few things to take into consideration:
Stage
If we’re going for a prototype/MVP or working on a bootstrapped project, I’d focus on the best quality developers my budget could find, coupled with a decent Project Manager. Anything else can be secondary.
For an established product looking to mature, with a team under 6 developers, I would probably only invest in a proper QA practice, perhaps a PO, depending on how complex the product roadmap is.
For any team with 7 or more developers I would immediately focus on a Leadership role. This will make a difference in terms of productivity, coherence, quality but also motivation and drive. Leadership roles embody exactly that.
Anything beyond this point has too many variables to consider and much more roles to take into account to make a suggestion on. Bigger products have bigger infrastructures and that opens up for a whole plethora of specialized profiles, middle-management and eventually somebody to watch the Watchmen.
Quality & complexity
Product code tend to have a much longer “shelf-life” than service-based usually delivers. As such, it’s common practice to really push for quality here. However, not all products are built the same nor they require the same level of technical excellence. Some stacks are simpler; Some don’t need to worry about scaling that much; Some don’t have very complicated infrastructures, etc.
This will define the seniority requirements, the room to hire potential, the need to diversify and hire specialists for each part of the puzzle, etc.
Long term vision
Hiring strategic profiles is also something very important.
Consider AI as an example. It’s proving to be a brand new market to jump into and I would advise any product to start to invest or at least investigate how this can benefit its offering. A big enough company might consider launching an AI team with a low impact on the budget. Whilst a smaller company might want to aim towards having the next needed hire to have some AI-related “chops” and kill two birds with one stone.
Service
The considerations to build a service team are somewhat similar to those of the product, although service teams tend to have less middle-management roles. The bulk of the focus is (most of the times) to produce which leaves the burden of POing and overall strategy to the client (most of the times a Product) side. Having said that, most of the same rules apply.
Still, there are some things to take into consideration:
Quality and complexity of deliverables
These two will define the balance between seniors, mediors and juniors. It will also impact which type of roles you need. Take for example a software house focused exclusively on wordpress implementation. The vast majority of roles are going to be the same as most projects tend to follow the same line. There is little need for roles with either huge flexibility.
On the other hand, a software house that works on the full scope of the web, will need a lot of flexibility to be able to deliver Frontend, Backend, Devops, Design, Blockchain, AI, etc. The quality you want to put out as a service will, again, influence the seniority of these roles. Top-notch scalable and readable code requires completely different profiles than just getting a website running for a marketing campaign.
The first one has a low barrier entry, it’s perfect to onboard juniors in. The latter will require a very big investment in training and quality control.
Speed
A regular team can deliver fast, with low quality. A great team can deliver fast OR with quality. No team can do both. A good team tends to be cheaper and easier to setup than a great team.
The ideal team
Much like in sales when defining an ICP (Ideal Customer Profile), I’d start off by defining in detail each of the ideal candidate profiles for the team we’re about to start recruiting for. Now, ideal doesn’t mean unicorn-grade candidate. The point of having these is to end up with a team composition with specific (down to earth) expectations for the best case scenarios. It will immediately translate into the job descriptions we need to create to attract talent, and will work as a framework we can use to measure quality of fit.
We will also need to define, for each role, what are the minimum requirements for us to consider a hire, or even an interview. This will also add up nicely to the job description as form of minimum requirements and nice-to-haves.
As an absolute minimum, we’ll need to figure out our expectations to:
- Experience in specific stacks
- Experience in specific industries
- Seniority
- Cost
As an reasonable minimum, I would always add to the above:
- Communication skills
- Cultural fit
- Location
We will, as mentioned before, need to decide how broad the stack needs to be, the quality level we want to focus on, and ultimately what is the benchmark for deliverables.