 |
| Are Your Engineering And Product Teams Talking The Language Of Business? |
Isn't it cool for a business to know the technical details and talk through it in their business conversations? It really depends on whether or not the business conversations warrant it! And when it doesn't, you see the symptoms of dilution in business nomenclature, which is the early sign of rot in implementation.
It is not uncommon at many workplaces to see business talking about deep implementation details so much that they start using business nomenclature interchangeably because the code implementation is same for either of the use-cases. Here is one example I witnessed in my teams where people clubbed vendor companies and warehouse/distribution companies we partner with and collectively address all as vendors. It took a good while and quite a number of conversations to realize this gotcha in business nomenclature. On gently probing every stakeholder, I realized that they were doing so because the code implementation doesn't distinguish between the two.
I noted that the below three things have gone wrong:
- Business Stakeholders talk implementation details.
- Application Developers not talking business language.
- Engineering Leaders believing that above culture is so damn good.
Guess what is the effect? It's a fail-fail situation. Grapevine has it like:
- Business thinks engineering is straightforward and engineers are dumb.
- Engineering thinks business doesn't know what they want and so are dumb.
Shouldering the responsibility of an Engineering Leader I had to do course correction by setting a right direction. It took me a few months of nudging one-and-all and parroting my favorite © quote,
"It is everybody's business to speak the language of business and then work backwards. You and the business benefit from it. Don't effing jump the gun!"