Roles and Responsibilities
Business is more similar to rugby than you might think. No, I’m not referring to scrums, shared showers and alcohol abuse! In this series of posts I’ll use lessons from 20 years of playing and coaching rugby to make you a better CTO.
- Part one: Trust
In a well-functioning team every team member knows what they should do in most situations, has the requisite skills, and can excel with minimal communication. Having a defined, yet dynamic, system of roles and responsibilities, along with trust between team members, ensures the team can quickly make tactical decisions and execute them while on the field.
Thirty years ago, rugby players were segmented by body-type and skills. The “fatties” at the front did all the pushing, shoving and ball winning, while the “skinnies” at the back did the running and scoring, and a couple of bigger mobile players did lots of tackling. Those days are now mostly over (at least at the professional level) and all players are expected to be able to throw an accurate 15 metre pass, tackle, contest rucks, and run hard for 80 minutes. There are still some specialist skills and positions: place kicking, hooking in the scrum, lineout throws, jumping in the lineout, positional kicking, but less specialization than in the past.
Over the same period we’ve seen a similar trend in software development. At the start of my career we had a QA department, architects wrote 300 page functional specifications, project managers used Gantt charts to track progress, security and performance experts reviewed code just prior to completion, and operations teams managed infrastructure and deployments.
I recommend CTOs build agile teams with an emphasis on specialized generalists: people that have a strong background in a given programming language, framework or problem space, but are open, inquisitive and knowledgable about a broad range of adjacent areas. Hire people that love to share their knowledge.
At Clause, engineers move naturally between frontend, middleware, backend and database work. They are responsible for the security and performance of their own code, documentation, and deploy to production several times per day.
The advantage of a system of specialized generalists is that the team is far more adaptable to changing circumstances, more innovative, and it is more resilient to the absence of individuals. It enables teams to make decisions on the fly and to quickly realign in “attack” or “defence” to exploit fleeting opportunities. In business, this could mean being able to quickly ship a new feature required to close a deal, or fix a security hole within an hour or two.
As CTO, it is very important to have a flexible team structure, and I’ve heard from many engineers that it is also more rewarding to be able to participate to a much broader range of tasks. That’s not to say that all team members are anonymous “human resources” — people will always have their individual strengths, weaknesses and preferences. A team of specialized generalists can quickly realign when someone falls sick, is travelling or is simply on vacation — often without any external coordination at all. In rugby we see these situations routinely, the scrum-half trapped in a ruck, or when players get injured, replaced or sin binned during a match.
It’s worth underlying however, that just because generalists are useful, it doesn’t replace the need for specialists. A rugby team typically has 2 or 3 designated goal kickers (for penalty kicks and conversions), as well as lineout throwers and scrummagers. So, there are certainly situations where you will draw on the experience of your specialists for specific tasks — or use them to train others, or to promote best practices.
- What base level skills do you expect everyone on your team to have?
- What specialist skills are in short supply in the team?
- Who are your specialists for things like operations, security, performance, information architecture, quality, compilers, frontend, database, API design?
- How replaceable are people on the team at short notice?
- How hard is it to hire people with the skills you need?
- Are your technical choices helping or hindering having an adaptable team?
- Do you need to provide on-the-job training to make your team more adaptable?