Two days ago, this has made my day:

Poor Mitchell.

"ESB. It's ESB."

No clue what he has responded, but if I were to suggest something, it would be going for either bullshit bingo or buzzword bingo. Regardless of what you're actually trying to sell, the best way to make an impression is still to put some Enterprise Service Bus in (even if it's neither service, not bus - people just don't get what ESB is AT ALL), mention Cloud or ...-as-a-Service & don't forget describing the solution as: "robust", "customer-centric" & "synergizing" (with whatever, it doesn't matter).

Yeah, I'm sneering, but honestly - situations like that happen all the time. High-level executives, who usually get more & more content-free the higher they get in pecking order, still want to make (direct) decisions even in low-level, technical considerations / issues, without bothering themselves to understand what's on the table.

Usually it's due to:

  • ol' times nostalgia (they miss the times they were not content-free? :>)
  • bad understanding of the role they are supposed to play
  • lack of confidence in they subordinates / tendency to micro-manage
  • poor time management / priorities
  • inability to efficiently delegate (properly set the targets & give valuable feedback)
  • workaholism

Fifty-fifty

But to be frank, it's just half of the truth. Tech people are ... well, tech people & many of them aren't good speakers. I've met many smart engineers who were focused on totally unimportant (at some level) aspects of how instead of why. The skill of stepping into somebody's shoes (trying to look at the solution from the other party's perspective) is very, very underestimated (& therefore - rare). Mix that with different language, lack of understanding of local issues & challenges: it's not hard to get your listeners annoyed & impatient.

Nevertheless, there are many good tech speakers, presenters & "salesmen" - who also encounter the mentioned attitude of executives. The truth is that the opinion that technical details are meaningless is a relic of 90s way of thinking:

"architectures & technologies of today are still just the variations of what was known (& used) on ol' good times"

This may be true to some degree (mainstream RDBMS didn't change much, FP languages were not born recently (but rather - excavated), actor model has been invented decades ago), but there are some benefits of modern software engineering that just can't be easily mapped to what executives grew up on, 10-20-30 years ago, for instance:

  • DevOps (& Infrastructure as Code, & Containers, etc.)
  • Continuous Delivery (& Continuous Deployment, & Continuous Testing, etc.)
  • Automated Testing (& Mocking, & Dependency Injection, etc.)

That's why they are so poorly understood or trivialized by decisive people in larger corporations. They map them to what they personally know (or they think they know - like ESBs ...), but they've stopped learning (tech-wise) ages ago. And now they don't want details ...

Piss of cake

Obviously, the solution is piss simple. Don't dive into details (personally), send a person who can do it for you. As a decisive person, you don't have to know everything, but you're supposed to surround yourself with experts, who know what you don't know. It's THAT simple.

It's those experts, who are supposed to:

  1. dive into details
  2. understand them
  3. map them to local context, find out whether they can address any known or unknown problem
  4. affirm (to the decisive executive(s)) the value added, without getting into technical details (it's not necessary, if experts are credible, competent and self-reliant)

It sounds that easy & ... obvious, but it very rarely works that way. Projects & products are being sold, technologies are being chosen on the top executive level, without an expert analysis, sometimes based on as weak criteria as past relations & personal connections. Keeping that in mind, it should be that surprising, that so many projects keep failing ...

Share this post