People in R&D are sometimes unaware of the great power they hold over the company. Can you imagine the VP of Sales saying, “We have so much sales debt that we have to redo our playbook for three months and only then get back to selling”? Want to wager how long it would be between uttering something along those lines and getting jettisoned by the CEO?

Contrast that with the regular tech-centric thinking in engineering teams. We rewrite things; we claim a lot of time in the name of tech debt. When you don’t realize that the other parties in the organization might view you as some sort of a magician, you might miss the fact that there are not enough checks and balances that “hold your feet to the fire” when it comes to delivering value.

Your prime objective should be impact and helping materialize business results. Can you genuinely say that actions like these are driven from that point of view?

• Obsessing over “test coverage” religiously.
• Hackathons that are all about code quality.
• Switching a programming language because it’s no longer trendy.
• Choosing an overly complicated tech stack for your needs.
• Committing 25% of all work time to “tech debt.”
  

The Tech-Product Continuum

All of the above are telltale signs of an organization that has too many engineers drifting toward the “tech” part of the continuum. Without the right culture and guidance in place, you will create a team that’s filled with principal engineers, but not product engineers.

Advising clients, and in writing The Tech Executive Operating System (coming this April, subscribe below for details, BTW!), I saw this often starting from the top. A tech executive that’s focused on “doing things right” this time around. After getting burned in the past by poor code quality and demanding deadlines, we tend to overcompensate. We go too far and eventually create a team that’s biased towards what I call for tech for tech’s sake.

I’m not saying that code quality doesn’t matter, that you should let tech debt spiral out of control, or that your team should be focused only on work and have no fun. I want to stress that without the proper pressure from within the company, which doesn’t happen naturally in all environments, and without some outside perspective, it is easy to go down the wrong path. After all, when it comes to techies, obsessing over tech is easy—it’s the path of least resistance.

Creating an Impact-Focused Organization

I view the pinnacle of software engineering excellence as creating a team obsessed with providing value rapidly. That’s what I love helping my clients orient toward, and it’s never straightforward. If some of the previous scenarios and descriptions sound all too familiar, you might benefit from readjusting your default stance as well.

For example, instead of devoting hackathons (which are a hack) for tech debt, create space for regular innovation in the form of tech capital. I’ve discussed this at length in The Tech Executive Operating System, but it’s also covered here. Help your team act as coders without borders, where they help everyone in the company—not just follow orders from Product.

I find that this transformation often starts from the right attitude at the top of the organization. As a tech executive, you have to claim your seat around the table and move upstream. Only by becoming proficient not just at the “tech” part of your role but also the “exec” part can you achieve the most significant leverage in your position. When you internalize what’s essential and pass that on to your senior staff, you start turning the ship around.