One tension in management is staying far enough
out of the details to let folks innovate, while staying near enough
to keep the work well-aligned with your company’s value structures.
Seeing this challenge from a variety of perspectives with different teams, I’ve
collected a playbook of tools to facilitate the balancing act, and a loose framework
for rolling those tools out.
A few caveats about process rollouts:
teams and organizations have a very limited appetite for new process;
try to roll out one change at a time, and don’t roll out the next change
until the previous change has enthusiastic compliance,
process needs to be adapted to its environment, and success comes from
blending it with your particular context.
Around the time your team reaches three engineers, you’ll want to be running
a sprint process. There are many successful ways to run sprints, try a few
and see what resonates for you.
I use to evaluate if a team’s sprint works well are:
team knows what they should be working on,
team knows why their work is valuable,
team can determine if their work is complete,
team knows how to figure out what to work on next,
stakeholders can learn what team is working on,
stakeholders can learn what team plans to work on next,
stakeholders know how to influence the team’s plans.
One of my coworkers likes to say that
“shipping is a habit”, and a well run sprint both helps teams
establish that habit, and is a mechanism that creates visibility into
a team that hasn’t quite gotten there yet. As a team’s direct manager,
you can use this to ground concerns around individuals who might not
be ramping up successfully, and as you move into middle management,
sprints are useful for debugging within your organization.
Within your sprint process, your backlog is particularly important:
it’s the context-rich interface where you’ll negotiate changes in direction and priority
with your stakeholders. It’s always more interesting to
discuss which of two things we should do next, rather than whether something is worth doing.
As your team gets larger and the number of stakeholders you’re working with grows,
you’ll also want to develop a roadmap describing your high-level plans over
the next three to twelve months. Planning does not inherently create value, so
aim to keep your roadmap as short as possible while allowing teams to coordinate.
Initially, the distinction between your backlog and your roadmap may be quite small:
your backlog a bit more detailed, your roadmap looking a bit further into the future.
The value in having both is that it lets you specialize the backlog to be more useful
for your team, and the roadmap to be more useful for your stakeholders, rather than
relying on one tool to satisfy both sets of constraints.
At this point, most teams will be tracking operational metrics, with a focus on
tracking day-to-day user and system behavior. These tend to be exclusively focused on
helping the team operate, and in particular detect outages, regressions and what not.
As you move into middle management, you’ll become responsible for
two to five line managers, and will need to shift away from day-to-day
execution to give your line managers room to make an impact
(and free yourself up to make a larger impact as well).
You’ll be spending more time in your roadmaps as you:
move from receiving asks from stakeholders to deeply understanding what is motivating those asks, and
invest into learning what other folks are working on to continuously validate that your teams’ efforts are valuable.
As you spend less time with your teams, you’ll want to start a weekly staff meeting
with your managers. The best versions I’ve seen start with brief updates from each person,
at most a couple of minutes per person, and then move into group discussions
on shared topics. Topics might be running effective sprints, planning, career development
or whatever else, and done well these discussions are the key learning forum for you and the
managers you work with.
As your teams and the organization around you grows,
you’ll start to see more and more cases of preventable misalignment:
two teams working on similar projects that were unaware of each other,
another team struggling because they don’t have a reliable email service when
your team actually does have one. At that point, it’s time for each
team to write a vision document: a concise statement of the team’s goals and
strategy for accomplishing those goals.
It’ll be extremely frustrating for some teams to write their vision documents,
because it’ll force them to recognize and reconcile areas of distributed and unclear ownership.
It’s worth the pain! Once your vision comes together, it becomes your roadmap’s north star,
and will help you reconcile stakeholder asks with
your longer term product and technology strategies.
This is also when you’ll want to start skip-level 1:1s to ensure that there are
direct, open channels for feedback about your managers and your teams. Typically
if you’re learning something negative during a skip-level, you should have learned it
somewhere else first, but rigorous processes have some redundancy. Nothing
consistently works every time.
Managing an organization
As your organization starts to get even larger and you’re mostly managing middle managers,
the playbook shifts again. Your staff meeting either:
has so many managers in it that they can’t even provide important updates,
and the discussions have become unwieldly with a couple of folks dominating conversations, or
only include your middle managers, who themselves are likely missing some of the context about what
their teams are working on or struggling with.
The mechanism I’ve found most helpful in this case is ensuring every team has a clear set
of directional metrics in an easily discoverable dashboard. The metrics should cover both
the longer term goals of the team (user adoption, revenue, return users, etc),
and the operational baselines necessary to know if the team is functioning well (oncall load,
incidents, availability, cost, etc). For each metric, the dashboard should make three things
clear: the current value, the goal value, and the trend between them.
Now your staff meetings can start with a quick metrics review to give a sense of whether
there is somewhere you need to drill in, and rather than peanut buttering, you can focus your attention on projects
which are exceeding or struggling.
The other mechanism I’ve found become exceptionally useful at this point is
team snippets which come out every two to four weeks, and give snapshots
of the each team’s sprints: what they’re doing, why they’re doing it, and what
they’re planning to do next. These are valuable for you to retain a sense of
what your teams are working on, but they are invaluable for decentralizing
coordination and communication between teams in your organization, as you
become increasingly ineffective in that role.
Along the way, remember that your old problems
still exist, it’s just that other folks are dealing with them instead.
As you roll out new processes to solve your personal pain points,
you should be handing off processes to your managers, and keeping
them intact and running. This will leave you with a tapestry of
reinforcing processes that support you and each layer of management
that you support.