Suppose your software engineering teams are bad-ass, high-functioning units. They produce quality software with a low defect rate that gleams like the chrome on a new Harley. They deliver on time, every time. The entire organization is impressed as hell with their output, ooh-ing and aah-ing every time they release a cool new feature.

Life is wonderful and the donuts are calorie free, right?

Wait up, though. Even though the team is rock-star quality on paper, the projects they work on don’t actually deliver value. They grind, but they don’t move the needle on company goals. In other words, the team is not aligned with the business.

It can be painful to realize that your engineering team kicks ass but doesn’t produce the right stuff. This might manifest in several ways. Perhaps the team works mostly autonomously, and the work they prioritize isn’t what others might consider a high priority. Or maybe you have to spoon feed projects to them, which means they inevitably ends up bottlenecked, waiting for you to hand down the next bits of work, and when they do complete work it doesn’t actually advance business goals.

This can be a killer not just for productivity, but for morale as well. Either the team will feel frustrated that they’re being held back and aren’t trusted to make some basic decisions on their own, or the rest of the organization will be discouraged that the team, while efficient, is not effective because they’re not moving the business forward.

“Yep,” you might say, “that pretty much describes the situation. So now what the hell do we do?”

I’m glad you asked.

The first place to start is with the design of your team. They should be capable of managing their own work and be led by someone who is responsible for the success of the product or domain. By “domain” I mean a well-defined business context, like software that handles member registration, billing, MRI image processing, or team collaboration. The team should be able to take a nice, hefty problem as input, make their own decisions about how to solve it, and manage their work.

The team leader can be a product manager, engineering lead, etc, but they need to be able to keep the team laser focused on the end user of the product or products in the team’s domain.

Once your team is organized, they need direction. This starts with product strategy, which is the combination of the vision for the product and the Next Serious Challenge.

[Aside: Don’t make the mistake of thinking of strategy as a goal, a plan, or a checklist. If you have no idea what I’m talking about, go here.]

The product vision – which can come from either the team or business leadership – is a clear picture of the future the product will create. Whether it’s a world where car ownership is no longer necessary, average people being able to wield the power of AI to better their own lives, or a human colony on Mars, your product vision will be the compass heading that guides your team.

Your “Next Serious Challenge” (“NSC”) is the next mountain between you and your vision. If your vision is to make humanity a multiplanetary species by founding a self-sustaining colony on Mars (sounds familiar?) and you are able to inexpensively launch reusable rockets to low Earth orbit several times a month, your Next Serious Challenge may be finding an inexpensive way to get a vehicle capable of carrying a significant payload to Mars and back just once.

Or perhaps your vision is to make it easy for the average person to create beautiful designs for their own marketing collateral instead of relying on expensive freelance talent. Your application’s current state allows people experienced with design tools to create collateral, and your Next Serious Challenge might be upgrading the application so users with zero design skill (like yours truly; seriously, a platypus with a pack of crayons can draw better than I can) may do the equivalent.

The next step is to take your NSC and break it into subproblems. Depending on your organization, this can be done at the leadership level or lower. Let’s suppose your NSC is finding an inexpensive way to get an unmanned vehicle capable of carrying a significant payload to Mars and back just once. Some of the subproblems you may have to solve in order to surmount that challenge might be:

• Vehicle should be almost entirely reusable, even after the high-stress entry into both Mars’ and Earth’s atmospheres
• Navigation systems should consume as little power as possible
• Vehicle must be able to safely land on Mars with the largest payload ever attempted
• Vehicle must be able to safely take off from Mars for the return trip
• Given the high latency of communications with Earth, the vehicle must be able to autonomously handle as much of the voyage as possible

…and more. Once you have broken your NSC down into subproblems, the next step is to hand those subproblems to your teams to solve. In a perfect world, each of the subproblems would have no dependencies on other subproblems, which would allow the teams to move at their own speed and independently of one another. However, since we don’t live in a perfect world (how boring would that be?) teams will have to coordinate with each other to some degree.

You may then keep your teams accountable and monitor their progress with regular meetings. Teams should regularly report on their hypotheses for solutions, what experiments they have conducted, the results of the experiments, and what they have planned for next steps.

The wonderful benefit of this approach is that your teams can experiment their way to a successful solution, instead of working on a solution prescribed for them that may actually not be the right answer to the problem. This autonomy allows your organization to put the resources closest to the problem – your teams – in charge of solving problems. Since those problems are directly tied to the progress of the organization, as your teams solve problems they will necessarily be creating value.

So to keep your engineering teams aligned with desired business outcomes, organize the teams into user-focused groups that can manage their own work, identify the vision and the next serious challenge, break the challenge into subproblems, give the subproblems to your teams, and meet with them regularly to monitor their progress.