A technical leader translates technical solutions into a business context. Translation is very different from explanation. Your business doesn’t want to know how your software works. Non technical leaders want to know what impact technology has on the goals of the organization. An effective technical leader provides that translation.

Translation allows the business to make good choices by understanding the impact of those choices. The higher up in an organization you go, the less likely someone will need to understand the technical underpinning of the work you do. Technical translation isn’t about helping someone understand a technology. Many technical leaders struggle because they assume their role is to explain the technology. Non-technical leaders will conclude you don’t speak the language of business.

Your job as a technical leader is to bridge the gap between business priorities and technical choices. Or technical challenges. You help the business understand the impact of the choice. Cost. Performance. Time to market. User adoption. Liability. These are examples of business needs that have technical dependency.

In order to effectively translate, a technical leader must understand the business needs. Only then can you start asking yourself if the choices you’re making will impact those needs. Many of the choices you’re making simply don’t. When you decide what language to write an application in, the language itself isn’t what matters. What may matter is how hard it is to recruit talent. Or the cost of the production platform. Or the exposure of relying on open source software. You’re effectively translating when you can say “We’ve chosen Ruby on Rails because there is a big talent base, it’s supported well in the open source community and the cost to run it in production is reasonable."

I recall working with a colleague and trying to explain that our test coverage was bad. Dismal. We weren’t doing enough testing. "Are you saying the product quality is poor?" No, we don’t have enough tests covering enough of the application. Who cares? I had to translate into what mattered; “We have uncertainty in our product quality. We don't know if our customer will find a big problem with our application because we aren't testing enough of it." We had to decide to accept this liability that we didn’t know if our product was performing as expected.

Perhaps user design is an important aspect in customer retention. Perhaps customer service is also. You may find that the CEO is comparing investment in user design against staffing costs for service. It is hard to compare these things when you are technical. A business leader must. We can make a more effective argument if we understand how they’re being compared; an investment in user design is a one-time investment in ongoing customer retention. Adding service staff is an ongoing cost proportional to the customer base. "Let’s choose the investment that scales better as we grow."

Think of the technical decisions you’re involved. Use the lens of how it matters to the core of your business. What’s the business objectives? Growth? Sales? Margin? Customer retention? How do your technical choices impact those goals. Now consider how they impact relative to other nontechnical factors. You’ll start to understand how your CEO puts on your world, and how not to get lost in translation.