Do things on purpose

A theme running through several entries has been that of intentional decision making. What does that mean and why does it keep coming up?

Efficacy is a vector, too

The most important part of agile requires thinking deeply about efficacy. Efficacy (like velocity) has a directional component to it, i.e., are we being effective at doing the right things. Properly assessing efficacy also assumes a clear understanding of what you are trying to accomplish. In practice, it’s too easy to handwave away your goals or leave them implied rather than directly expressed. This impedes your ability to determine if you’re actually making appropriate progress.

As you move up within an organization, your sphere of influence tends to broaden and the nature of your work becomes less defined and subject to longer timelines. For example, a junior developer on a project spends most of the day working on a single, well-defined task from the backlog. There’s an explicit backlog of work (the actual backlog), clear success criteria, and tasks take less than a day to complete. A manager a few levels up likely has a much larger set of things that could be done than will fit in the time actually available, a set of both shorter and longer term initiatives, and possible outcomes that are far from black and white. When you combine endless possibility with limited capacity and urgent stimulus (say, those urgent, unplanned requests that seem to show up all the time), you fall into the trap of being reactive rather than intentional about your priorities.

What do we do about this trap?

First a la the technology evaluation framework we should decide if this is a problem that even needs to be solved. If you feel like you’re running in place, your teams don’t seem aligned, or key initiatives feel shortchanged or left untouched, you may need to adjust how you operate. If everything is humming along, maybe you don’t (or else you’re about to be surprised). At a minimum it’s worth recognizing that you’ve made an intentional choice to remain reactive - that way you can go back and assess the efficacy of this choice later.

How do we start breaking free?

The good news is that you can start small and build incrementally. What are we doing? What are we trying to accomplish? What assumptions have we made? How do we know if we’ve succeeded?

Name what you are trying. Try it. Think about whether it worked. Think about whether context has changed. Reformulate and repeat.

Be intentional about granularity, too. As we’ve learned from the complex, highly variable process of making software, it’s better to think at a Roadmap granularity rather than the Plan level. Plans can be overly precise and brittle, while Roadmaps have clear goals and waypoints and allow for adapting as the real situation emerges. Because adaptation is assumed, we remain open to new information arriving and are comfortable with (intentional) pockets of uncertainty.

You can choose to change this specificity over time, too. For example, you might move from just trying to fit everything in (it’s all important, so nothing is), to scheduling a specific time each week to think about what is the highest priority thing for you to solve, onto having a high level hypothesis of the solution with specific times setup to resolve key bits of remaining ambiguity, etc.

Where do we go from there?

I don’t want to imply that reactivity is bad, so long as it’s how you’ve chosen to operate. Some situations call for a fire-fighting mode of action. During the Roman Republic, in times of crisis they would appoint a temporary dictator to act quickly and decisively and resolve the crisis before going back to their more representative form of government. Fire-fighting mindsets, like dictatorships, are likely not a winning long-term strategy.

This isn’t just a way of working individually. You can and should manage this way. Tell your teams what you’re trying to accomplish (likely at roadmap granularity). Walk them through the introspection process. Not only will this help your teams be intentional about their own thinking, they now have more context for your bigger goals and can make smarter choices and help you adjust. Don’t short circuit the contributions your teams can make by keeping them out of the strategic loop.

This also works outside of work, too. I’m not suggesting this as a productivity hack or something dumb like that. It’s not really important what you choose, but if you are intentional about your choices and are honest with yourself you can likely head off dissatisfaction.