3 Lies Your Tech Team Tells You (and Themselves)

“That’s how Google does landing pages. It’s the industry standard.” 

“We can’t deliver any sooner than August. We added up our estimates and six months is what we got.” 

“Just wait two weeks for that urgent fix. We can’t break the sprint, or we won’t be Agile.” 

Every one of these is a lie your tech team tells you—and themselves. These very common misconceptions stem from a fundamental error endemic among engineers: the belief in “better.”

Better Isn’t Better (for Everyone)

Inside a computer, it’s the land of ones and zeroes. There’s no doubt or uncertainty about arithmetic and logic gates, and barring the odd cosmic ray, the machine is entirely deterministic, following the same path over and over every time you provide the same inputs. 

Even the apparent randomness in games or simulations is actually an illusion. If you provide a specified “pseudorandom seed” to, say, Minecraft, you’ll get precisely the same behavior every play-through. It’s helpful to remember that every member of your IT team chose a profession that involves this level of certainty and predictability; it’s literally impossible to do their jobs without reasoning rigorously from first principles.

But outside the computational realm, we encounter unpredictable humans, and all bets are off. No sales team would even consider applying the same deck or pitch to every prospect, and every customer service call is different and surprising. Scripts and training help your staff achieve consistency, sure, but it’s crucial to vary the approach to match each situation, as so many organizations found when they tried to adopt holocracy or lean methods to ape the success of Zappos and Toyota and fell flat on their faces.

This is just as true in building software as it is in operations, finance, or strategy: there’s no one right way to design a login screen, build a report, or discover what features customers will pay for. That's why engineers have devised such a dizzying array of software methodologies, such as Scrum, Kanban, ShapeUp, the Spotify model, SAfE, and a hundred others, all successful in some cases and disasters in others.

Now you can see why we techies fall victim to the betterism trap. Any one of us would find it attractive to believe that there’s a stone tablet out there with the answer to our problems chiseled into it, but certainty is dangerously seductive when every day you work with tools and machines whose very operation depends on absolute consistency. But how do you break the binary thinking habit?

First, Question Relentlessly

For so many of us, technology is just black magic. The engineers mutter weird incantations about Kubernetes and zettabytes and out-of-the-void pop websites and emails and credit card payments. So, when the sorcerers tell us with authority that they’re following “best practices,” who are we to doubt them?

The answer is YOU! Just like any other team members, software developers need feedback about whether their plans and deliveries are on track for company strategy. You don’t need to use geek-speak to provide your reactions and guidance; it’s their job to learn enough about your market and targets to be effectively accountable to you using standard English. Don’t be afraid to ask any and all questions about what they’re prioritizing, the reasons for deciding on this or that technology, and especially how they expect the rest of the business will benefit. 

I believe so strongly in asking questions that I printed up fancy gold-leaf certificates granting official permission to inquire of engineers on any topic whatsoever, and I hand them out whenever I can. Below is a sample. If you’d like one on your wall, drop me an email, and I’ll send you one (free!) 

Next, Play The Why Game

Once you’ve conquered the fear of asking questions and learned more about your tech team’s approach, it’s time to play the 'why' game. The rules are simple and familiar to every five-year-old: you first ask what a developer is doing, then ask “why” repeatedly. 

“I’m replacing our payment page.”

“Why?”

"Because it’s inefficient.”

“Why is it inefficient?”

“We do extraneous checks that slow down our response times.”

“Why does speed matter?”

"Because users give up when they have to wait too long to pay.”

The signal to stop is when you get to money. Once you hear, “because it will increase conversions,” “because more clients will upgrade,” or “because we’ll slash research costs,” you’ve won. If you never get there, ending with “I don’t know” or “because Jane said so,” you (not the engineer) have lost the 'why' game. Look for ways to connect your tech team much more closely to business results so everyone’s a victor next time you play.

After a few rounds of Whys, you’ll start to see patterns and gaps. For instance, I worked with one team that was laser-focused on boosting their conversion rate but was totally ignoring costs. No surprise that they went way over budget with hyper-optimized social ad strategies that were way too complicated for a simple Christmas campaign.

Sure, their intricate algorithms were “better” at getting a tiny price advantage on certain keywords, but the Facebook bill was a harsh reality check when it arrived (including charges for actually crashing some facebook.com ad servers with too many requests!). When you see blind spots like these, correct the priorities, cancel what’s unnecessary, and reinforce the message that the tech needs to be tightly aligned with your business goals.

Finally, Ensure Accountability

Now that you’ve found and rooted out the “better” tech solutions that aren’t actually working for you, provide simple ways for engineers to show you that they’re staying aligned and on track. Notice I didn’t say anything about “holding the tech team to account,” a finger-pointing approach that always makes me want to hide under the nearest desk. Instead, enable your developers to be accountable to you. For instance,

• Schedule a weekly demonstration of IT improvements, with team leaders describing the business benefits and taking feedback from you and others.
• Set up a dashboard showing important metrics like system uptime or calls answered, and ask developers to explain frequently how their actions improve the results.
• Create a glidepath for tracking progress on key projects and for recovering quickly when key elements get delayed.

A clear strategy for frequent feedback and a focus on real, tangible business benefits will ensure your IT spend isn’t wasted on clever but useless “better” projects. And if you, like most businesses I work with, are throwing millions at tech with murky results at best, isn’t it worth measuring your return on that huge investment?

Subscribe to The CTO Club's newsletter for more advice from our community.