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.
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.
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.