Choosing where to spend my team’s effort

It’s the start of a new fiscal year. Strategy season. That time when all the grand ideas come out and everyone is still hopefull.

Over the years, I’ve settled into a structure that helps me define projects that not only link to the strategy above but also looks at my own team’s enviroment, I thought I’d share it here.

Working with the given strategy

Strategy usually comes down from the top. The C-suite sketches the big picture, department heads slice it into projects, and those trickle down to the teams. It’s not always a very transparent process, but that’s how it works.

Knowing this, there are some ways you can take (partly) ownership of this process by injecting your own projects into it. We’ve talked a lot on this site about organizational layers¹ so there might be some projects that you can think of that benefit the strategy that layers above you might not see. What you see depends on where you sit. That means there might be gaps in vision, gaps that you can fill.

First things first is getting to know the strategy. That sounds extremely obvious, but it’s something, so many team leads skip over. Having a conversation with your boss about where the company wants to go towards in the next X years and where your boss’s boss wants to go, and why. The bigger picture stuff. If you’ve never done that, you’d be surprised how suddenly some questionable decisions from the past suddenly make a lot more sense. This is something I would do at least yearly.

All the work will be routed in this. If you can pitch your projects in the framework of the company’s strategy your odds of a successful pitch will skyrocket, most of the convincing has been done for you already. Not only that, your boss can easily pitch that project to the higher ups. Everyone wins.

Converging strategy into projects

Ok, you’ve got the strategy. Now how do you turn that into projects? I like to use a bastardization of Teresa Torres’s opportunity solution tree. It’s a startup thing, but it works just fine in the grand halls of enterprise.

I use it like this²:

You take one of the strategies. An example would be: we want to reduce cost. The next step is to start linking broad actions that we could take to handle that strategy. EG: automate processes, eliminate underused software, look at licences. Don’t judge the ideas too much yet, this is the part where you make the mess.

You can do of these things alone, but it’s probably better to get some smart people in the room from your team. Again, you only know what you know. More brains, more angles.

Once we have these vague ideas, it’s time to shift from vague to specific. It’s possible that you can’t find a real project for an item in the tree above, or that if you go deeper into it, it turns out that it was not a great idea. This is good, that means that you are already filtering out the fluff.

The last step is thinking of a proof of concept, this is another filter layer. What can we quickly build that proves this idea has legs? If you can’t find something that can at least proof rather quickly if there is value or not, it’s probably not something to pursue. This process turns abstract strategy into stuff that ships and also gives you the ammunition to pitch it, as you walked the logic all the way down.

You might end up with something like this ³:

This is good, but it can be better

You could stop here and have a solid list of projects. Your boss would be impressed. But I think the real kicker would be to have projects that serve more than one strategy.

At the “vague idea” stage, before turning anything into a project, pause. Run the same exercise for your other strategies. Build separate trees. Then take a step back. Look across them. You’ll start to see overlap, ideas that touch multiple goals at once. Those are the winners. The projects that move more than one needle. The ones that get budget and visibility.

This is where the real value starts showing up.

Once you start defining projects, focus on the ones that serve multiple strategies at once. For example:

Say the sales team manually emails orders to the delivery team. You could replace that with an API connection. That alone cuts labor costs. But there’s a second win: if you’re also planning Project X, and it needs real-time order data, that API suddenly becomes critical infrastructure. One move, two wins.

So now your project becomes: “Build an API that connects sales and delivery across product platforms.”

And when you kick off Project X, you’re already set up to automate and move faster. You didn’t just deliver a feature. You moved strategy forward on two fronts.

But I don’t have the freedom to define my team’s work

Most teams don’t. But this is a first step towards something like that. What we are doing here is helping your boss look good to their boss. We reach out and help find answers to the questions they get asked.

The first time you try, you might get brushed off, plans are already locked in, no time for new ideas. That’s fine. The second time the strategy to project planning comes around, you have a higher chance to be in the room where it happens, as you’ve proven in the past that you understand how these things work.

And yes, your team is probably already busy. Everyone is. It is important to remember that you’re reaching out with potential projects that we can do, ideally replacing assigned work with chosen work, not taking on the extra projects. Suggesting projects doesn’t mean you’re committing to them: it means you’re helping to shape the conversation.

Replace assigned work with chosen work. That’s the shift.