+1 WIS

Being heard

I've read (and crafted) many engineering proposals at $work over time that made a lot of sense but ultimately failed to get traction. Why? Because they were proposed in the engineering context, but evaluated in the business context.

Here's an example:

What the engineering lead proposed

"The Frombulator service was written by an intern in Visual Basic 15 years ago, it's a major pain in the ass, let's rewrite it in Rust."

Sounds reasonable, right? But it doesn't mention anything about why someone further up the foodchain should care.

What the CTO needed to hear

  1. The Frombulator is in the critical path of all user requests. It has weekly outages despite a council of 20 elder wizards being employed to run it, and it's quite inefficient. This costs the company $X per year in hosting, wizard salary and customer credits.
  2. Here's a proposal to reduce running costs to $Z/year (a team of 6 goblins and a laptop) and reach 99.99999% availability, over 2 years at $Y total.
  3. Confidence of pulling this off on time is high (90%) since the APIs are well defined, we have clear exit criteria, and all necessary knowledge is already in-house.

This will then fly, right? It depends.

Corollary: finding impactful work

We engineers (and I'm guilty as well) often want to Fix The Broken Things. But turning the above method around is often a way to discover the real opportunities that actually "matter".

Write for your audience, and you shall be heard.