Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)
At the time, while I’d been running important teams in my organization, it was still a relatively small organization (each CEO knew me by name), so the role and significance of each team was more clear (or at least had been justified by someone before me).
Since then, I’ve learned a little more about what is important in a large organization, and I have some more roles to add. The above management roles have more to do with day-to-day management of a team, and assume that managing upwards and managing long-term are taken care of elsewhere. (Theoretically, they are probably most likely part of the ‘Product Owner’, but most likely they would be part of the ‘reserve power‘, and would devolve to whomever was considered ‘highest’ in whatever organizational hierarchy was present.)
I had also been blessed with excellent technical leads on all of my teams at all of the places I’ve worked, enough so that I didn’t think to explicitly call out ‘Technical Lead’ as one of the ‘traditional’ management roles.
(So now, we have six):
Technical Lead (Software Architecture & Implementation Decisions)
Performance Manager (Worker Evaluation)
Estimatrix (Estimator)
Product Owner (Prioritization)
Scrum Master (Removing Obstacles)
(People) Development Manager (Development Conversations)
(There are also some questions about the exact line between ‘roles’ and ‘skills, for example: ‘Running a Meeting’ ‘Presenting engaging presentations’), so I will include them for completeness, even though they bleed into many of the other ‘roles’.
As mentioned above, the roles below would fall under some combination of:
– ‘Product Owner’ (because they involve working with people or groups outside/above the team in question)
– ‘Scrum Master’ (because the team would notice that they were blocked or impeded by not paying attention to a certain type of issue, and might be perceptive enough to up-level the discussion to a more general/role-based one)
– ‘Reserve Power’ (roles or tasks that are automatically put under a traditional ‘Team Lead’, but no one really considers them separately, even though they take real time and effort)
Anyways, here are some other longer-term and/or more upward-facing roles to add to the above:
Milestone setter
Team Vision & Planning
Recruiting, Interviewing, & Hiring
Team compositions planning/Team Development (this is development of the team as a whole)
Building relationships (travel, phone, random 1:1s)
Running Meetings
Preparing & presenting engaging presentations
Tech architect (Longer-term decisions about code structure)
Code reviews (this would likely fall under ‘Tech Lead’ above, but ‘what is good enough’ would likely fall under the next line, ‘Quality decision-making’)
Quality decision-making (how good is ‘good enough to ship’?)
Quality Assurance & testing
Asking for resources
Team Champion, in charge of Dog & Pony shows[1] (Why is the work that the team does important?)
Some of the above roles are systematized, automated, or otherwise circumscribed by processes in larger organizations, for example, they may have specific processes for project planning, or for recruiting or development conversations.
But still, there are a lot of these. This suggests that either teamwork is super-complex, and requires too many different things to easily handle without tools[2], or there must be some way of grouping them into meaningful ‘roles’.
So, how do we group them? We could group them into the familiar Agile ‘Technical Lead’, ‘Scrum Master’, and ‘Product Owner’, but that just really puts us back where we started, shoehorning roles into boxes that don’t quite fit, or with a bunch left over.
Fundamentally, all of the above roles are some combination of tasks and making different kinds of decisions.
I’ll do what I can to define, codify, and group them tomorrow.
[1] I am somewhat flip in my naming here, but in any large organization, any team should have a story for how they are planning to remind the management structure of why they are important. This serves a number of functions:
0) The obvious ‘remember who we are and what we do’
1) It’s a good check-in, to make sure that what they are doing is actually perceived as important
2) It’s good practice for the inevitable re-orgs in any large organization, or even if one’s boss changes because they leave for another position or organization
[2] Like checklists, or more advanced tools like JIRA and wikis.