Delegation
One thing about job hopping is that you get to experience new perspectives on how people work. It forces you to reconsider what’s obvious. Take delegation for example. I used to think anyone with a bit of experience can do it effectively. It’s just about decomposing a system and assigning components to different people, right? It turns out effective delegation is much more nuanced.
Situational Leadership
Situation Leadership is a model that ascribes different delegation styles based on the competency (skill) and commitment (motivation) of each team member. Assuming motivation is not a factor, skill is the sole determinant on how much you should direct an engineer. A highly competent engineer requires very little direction. An inexperienced engineer requires specific and concrete directions.
I really like this model of collaboration because it recognizes the power of total ownership while respecting the risks of insufficient guidance.
Scrum Falls Short
An important part of Scrum-based agile methodology involves the preparation of a backlog, review of tickets, and democratic estimation of ticket sizes. This can be very effective when each member of the team has similar skillsets and motivation. In many descriptions of scrum, each ticket in the backlog can be worked on by anyone and estimated by anyone. This approach, however, runs in contradiction with the Situational Leadership model of giving more autonomy to high skill, high motivation individuals.
Consider a team of highly experienced engineers. Each engineer can take on a large problem and work without directions for multiple days. Each engineer can pull in others when needed and collaborates without supervision. The assignments for this team are likely to be vague. It gives each engineer the ability to make tactical decisions without having to first seek approval.
Now consider a team of green engineers. They need supervision to ensure things are done right. They also need coordination to ensure their pieces fits well with others. Their decisions often requires review and approval. Their assignmetns are likely to be small in scope. Specific and concrete tickets are necessary to give frequent and minor course corrections that inexperienced engineers need.
On many teams, you will have a mix of engineers with different skills. As a team lead, you may need to have tickets that vary in scope and have a good idea of which ticket is going to whom before grooming. As a leader, it is important to be conscientious of the competency variable. You and your team should adopt the backlog preparation process to best fit the changing and growing skill levels of your team.
The Big Picture
Most leaders know that it is important to communicate the big picture to the team. However, many leader overlook the importance of explaning how the big picture should be broken down. A key thing to remember is that there’s more than one way to organize work. It is tempting to believe that your team will figure out the details. But that’s often an unreasonable ask. There are many ways to decompose a system and if there is a best way, it isn’t obvious to everyone. So we must settle for the next best thing: Consensus on how the team divides up work.
In a group, your responsibility as a leader is to create consensus on how the big picture is broken down and keep that consensus throughout the entire project. You can assign project breakdown to yourself: Take a complex project and break it down according to your own style and you’ll ensure the team knows how each ticket relates to another. This is NOT advocacy for “the manager knows best”. This is advocacy for team alignment. Ideally you can rotate this responsibility between senior engineers. In theory your team can be so good at communication that this isn’t needed. But I’ve never seen that happen - within or outside of engineering teams.
As a leader, work hard to make sure everyone on your team understands how their assignments come together holistically. Because modules of your system will change as new requirements arrive, you must ensure that understanding is kept up to date. This is a lot of work, but vitally important to keep your team motivated and productive.
Managing Up
So far I’ve been talking about managing down - how to effectively delegate work to your reports. Equally important is the ability to manage up - effectively communicating project wellness to YOUR managers. In the Situation Leadership model, you assign different levels of authority and accountability to engineers of different qualities. However, I’ve seen problems this approach and how manager-of-managers like to track progress. Many managers push for an idealistic version of scrum where each ticket is small enough that anyone can work on it. Generally the argument is that long-lived work carries more risk and results in worse estimation. This is true. At the same time, you don’t want to give a senior enigneer a task that can be completed in a day or two. That’s usually too specific to allow them to exercise autonomy and tactical decision making. As a leader, you are responsibile for managing the tension between the two goods.
It is easy to pick one extereme: Push back against management on creating small tickets. It is equally easy to push the other way and convince your engineers each ticket must be small enough. In my opinion this is a case of a false dichotomy. As a leader, your job is to create the right balance to effecitvely manage a project. To your managers, your ability to support and execute to their goals is key. To your reports, authority, trust, and freedom is worth much more than financial incentives. Perhaps you have a policy of “small tickets only”, but ask your senior engineers to take a few minutes to break a large assignment into small subtasks. Perhaps there is an unspoken agreement that enigeers who estimate well and deliver large tickets on-time earn the right to be the exception to the rule. The right solution depends mostly on the company culture and the people around you. So use your experience to navigate this maze.