Coding is magic. Leading an engineering organization is like being in charge of a cadre of brilliant wizards. At least, it should be.

The experienced and calloused tech executive has learned—often the hard way—that things are not as easy as they seem. As the team grows, complexity prospers. The intrinsic perfectionism engenders a vicious negative feedback loop forming an organization on an incessant drive to… meet expectations.

Getting Boxed In

As a leader, you might find yourself facing a simple aspiration—delivering the freaking roadmap you committed to. I know, that’s frequently not a trivial achievement in and of itself. Nevertheless, the problem is that by having this mindset at the outset, you’ve already hurt your chances of achieving that goal. If that is the best-case scenario you can imagine, and that’s how the entire team then learns to consider your roadmap, how likely are you to overdeliver?

This negative feedback loop manifests in that you focus on merely delivering and then box yourself in. The budget and headcount are tailored specifically to fit said roadmap and often don’t have enough wiggle room to allow for anything else. You put yourself squarely in a position where your wildest dream is to do what you said you’d do. That’s the exact definition of “meeting expectations.” Shouldn’t we aim for a situation that allows us to exceed expectations, at least potentially?

Making Headroom

The figurative headroom needed to make space for greater success and exceed (some) expectations starts with a change of perspective when considering your roadmap. Consider the rough sketch below. If your aim is only as high as achieving the roadmap, you’ll never exceed it and often fall below it. Aiming higher is required, and that’s done by taking the roadmap for granted and making the “extra” part of your regular work.

In my recently published book, The Tech Executive Operating System, I talk about breaking out of the cost-center thinking and putting in place the needed prerequisites to create an R&D team that’s also an innovation center. (BTW, if you grab copies of the book now, you can enjoy the free early-bird benefits. Don’t miss out!). These are the prerequisites I outline:

Deboxing as Mindset: I sometimes call this the Coders Without Borders mindset. Stop viewing yourself as enslaved to the holy roadmap. Instead, move upstream so you can help shape the roadmap for maximal impact and start looking for other opportunities where your team can supply leverage.

Budgeting Appropriately: If the budget is cut to size for the roadmap, you will be hard-pressed trying to fit any other initiatives. No one likes extra spending on a cost center, but an innovation center generates more value. Get the budget to support the extra people and expenses that are required to aim higher.

Making Innovating Habitual: I’ve discussed at length the practice of implementing ongoing innovation in The Tech Executive Operating System and some of those concepts are covered in my series about intermissions and managing “non-feature” work. The gist is that you cannot expect something like a yearly hackathon to create innovation. That only teaches your people to keep silent with ideas until the “innovation time.”

Honing Mastery: Tech mastery is essential in order to achieve efficiency, but product mastery is a must for efficacy. Get your team intimately familiar with the product and the business so that they put their brilliant brains to work on providing tangible value. Otherwise, they’ll be busy researching new Node.js packages.