Tools for operating a growing organization.

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:

1. 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,
2. process needs to be adapted to its environment, and success comes from blending it with your particular context.

Line management

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.

The criteria I use to evaluate if a team’s sprint works well are:

1. team knows what they should be working on,
2. team knows why their work is valuable,
3. team can determine if their work is complete,
4. team knows how to figure out what to work on next,
5. stakeholders can learn what team is working on,
6. stakeholders can learn what team plans to work on next,
7. 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.

Middle management

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 unwieldy with a couple of folks dominating conversations, or
• only includes 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 to become exceptionally useful at this point is team snippets which come out every two to four weeks, and give snapshots of 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.