Two jobs you can't delegate

Ten years ago, building software was slow and expensive. Producing a new customer portal meant a budget cycle, vendor selection, and months of work before any working screens were ready.

The cost, in money and effort, was useful in a way. It forced an executive conversation about whether the project was worth pursuing.

Today, much of the friction of earlier software development is gone. Low-code platforms and AI coding assistants allow teams to prototype in days what used to take multiple months. An operations manager with no coding background can build a working automation in a few days.

For the most part, leadership teams have adjusted for the better. Early in digital transformation, I saw plenty of executives sitting in on vendor demos and sprint reviews. Part of that was risk control, and an equal part was because it was new and genuinely interesting.

As technology functions have matured, most leaders have handed off much of their involvement. But for many leadership teams, stepping back from implementation has turned into stepping back from decisions that still belong to them.

Technology teams often end up deciding which projects get built and what counts as success. Increasingly, so does anyone in the business with an idea and the tools to build it. Neither is in the right seat to make those calls alone. A technology team knows what’s feasible, and each department knows what would make its work easier, but both tend to underestimate how much change it takes to get people using something new, and neither is responsible for what’s best for the whole organization.

Those are business decisions, and they involve tradeoffs only leadership can make.

Job 1: Decide what gets scaled.

When anyone can build their own tools, leadership can't approve every project. Someone in finance builds a fix for their own problem, while someone in customer service builds a different fix for a similar one.

You can’t decide everything that gets built, but you can decide what gets scaled. This requires a path for people to bring the prototypes they’ve built into the open, and a clear point where leadership decides which ones become tools the whole organization will rely on.

Leadership must own that decision. What limits how many projects can move forward isn't capability. It's money, meeting time, leadership attention, and your team's capacity for change.

Job 2: Define what success looks like.

"We need an AI pilot" is not a goal. Neither is "digital innovation." Both describe work to be done, not what the work should change.

For an experiment, that’s fine. When building software is cheap, a quick prototype doesn’t need a business case. You could set a learning goal, like whether a new approach will work for quoting, and find out quickly with little at stake.

But scaling is different. Before a prototype becomes something your organization depends on, leadership should be able to say what problem it solves and what will look different. Say the quoting prototype worked: Before rolling it out to the whole sales team, leadership should be able to name the change and impact, such as quotes going out the same day instead of the following week leading to an increased win rate.

I’ve previously written about measuring whether technology has changed what the business can do. This comes before that. If nobody writes down what “different” means before the project starts, there’s nothing to measure against when it ends, and the project is simply judged on completion.

Your technology team can help test that definition and whether it’s realistic or what it would take to get there. But they shouldn’t be the ones writing it, because the outcome lives on your P&L. You are accountable for the success.

Try reflecting on these questions:

1. When was the last technology initiative where you could say, before it rolled out, exactly what would look different afterward?
2. Could you list what's being built across your business right now, and which of those deserves to scale?
3. If someone asked why a project should get your organization's time and attention, could you answer without saying "innovation" or "keeping up"?