On team composition
At this stage of my career, I have developed a keen interest on what makes (technical) teams tick, what connects and motivate them, what makes them productive or frustrated.
Over the last years, I’ve read a lot about product teams, how you might to create a multi-disciplined team where all facets of a product are being represented. We tend to look at this purely from a functional level: you need one or two back-end developers, a front-end developer, a marketeer and a business analyst for example. Depending on your business you might even have your own formula.
However, this is only one dimension to look for a multi layered team. People can also look at it from a character or personality perspective. Whilst generalist labels like 16personalities and such efforts to catalogue people by personality types might hint at a good balanced team, the truth is that you won’t find a lot of people taking you serious if you would ask them to fill this in. It also does not guarantee you that they will behave like described.
What interests me more is the role they pick up themselves inside of a team. I’ve reflected back to teams I used to work with, and try to synthesize a set of roles that were valuable and had great synergy. This is by no means a list to hire against, but might give you some key insight look at a team as more than the sum of individuals.
Grunter
The grunter is the backbone of your team, but will rarely be seen in leading role of the team. The grunter will take on tasks nobody really wants, but need to be done. He or she will be the one push through the mud to get it done. The grunter is not necessarily the one with the most skills, but is invaluable to your team.
Grunters are often the people that are overlooked in any promotions or such, since they don’t do the flashy work. They will not really work on strategy or abstract plans but when they give a comment, it usually tends to be quite pointed towards value for the customer, since they work on more diverse parts of the code base and hence, have a fresher recollection of how things work.
It takes a while for a grunter to be worn down, they will most often be the ones to work the longest in a team or a location. They might also be the ones to cool down any heated discussions or frustrations, but everyone has a breaking point.
My advice to manage a grunter is the following: keep them happy, offer them a salary increase from time to time, without them asking for it. Involve them where their deep knowledge might be useful.
Criticaster
The criticaster will keep your team sharp. I’m not necessarily using this term in a negative connotation. The criticaster will ask questions about things that your other team members might find quite obvious. But more than often, the criticaster will uncover assumptions, and as the old adage goes: “when you assume, you make an ass out of u and me.”
The criticaster makes it so that people need to be prepared to answer questions about their ideas, and that only makes the quality rise to the top.
My advice with a criticaster is not to try weaken his/her/x position but fitting them into a culture of accountability, where all questions can be posed and will be answered.
Depth charge
The depth charge is one of your more senior profiles. It’s the person that likes to go very deep, sometimes a bit too deep for the budget. The depth charge has insights that he/she/x wants to share, you’ll often find them in a coaching role. One of the finer things in a team is seeing a criticaster and a depth charge doing some form of pair programming.
A depth charge will mostly take charge when big changes need to happen in a code base, or in an organization. Depth charges, depending on the characters of the people in question, tend to gravitate towards the analytical ones to have nice and long discussions. Out of these discussions, you’ll be able to see strategic plans for software.
The depth charge will normally be the one that ensures the software quality inside of a project, and therefore is also quite important.
My advice with depth charges is to mostly just respect their modus operandi: don’t pull them out of their focus too much, communicate with them during the respective moments like daily standups. You’ll get more value out of them, and you’ll get a better relationship with them. When you do need to pull them out, due to budget constraints, make sure that you prefaced it before they start the work and explain when you need to pull the plug. Don’t try to rule over them.
Analytically inclined person
Together with the depth charge, the AIP forms a tandem. The biggest difference from the AIP and the Depth charge is that the deliverable of the AIP is slightly different. Sure, this person may still develop, but his/her/x eye is more on strategy, structure and/or planning.
This might be an analyst, but can just as good be a senior developer that wants to pivot a bit away from day-to-day programming. This person is a very good profile to have in classical hierarchies, as they are able to communicate best with a form of upper-management.
Rule follower
The rule follower might be — counterintuitively — not be the one that follows all the rules, but is the one that will make sure that rules are followed. When somebody adds a ticket to a sprint after it has started, this person will be the one pointing it out.
You might have some friction with this person, but in the end always keep in mind that they don’t do it to spite you, but to ensure that work rhythm stays healthy.
The one that everyone needs
The one that everyone one needs is a very abstract one, and one that is quite rare to see in the wild. When this person has never been part of a team, your team won’t really notice, but when he/she/x arrives your team will instantly notice it. This person is a catalyst inside of your team. It most of the time is a senior profile, that focuses on relationships and structure.
Most of the time, you’ll see a scrum master take this role. Be the approachable one, that people can bother to duck program with. The one you can ask questions as a spring board.
Be aware that when this profile leaves your team, it could have devastating effects if it happens for the wrong reasons.
—
Now, this by no means is an exhaustive list but it might help you to identify some people around you, or any gaps that you are noticing in your team that you can’t really put a finger on.
I’m also not saying that every productive teams needs at least one, or only has one of each, or even that they can’t overlap. The most important thing to note in this blogpost is that everyone in your team probably has a big value for the fibre of your team. The je ne sais quoi that makes a team more than the sum of its parts. If you look out for this fibre, and make sure to cultivate it, you’ll see that the value you deliver will be awesome.
It also needs to be said that instead of wanting to “only hire the best developers” doesn’t really bring you what you want. You’ll miss that spark between certain different roles. You should try look for a diverse crowd and balanced team.
If you have any further questions, feel free to contact me on any of the social media platforms, or reach out via email at niels@codingculture.be!
