Developers Should Develop... A Business Sense

I’m an engineer at core, but I’ve come to a point in my career where I’m much more than that. I’ve seen lots of pain, fear, damage, and my ‘professional angle’ is much wider than it was when I started my career.

I’ve been working for a long time on how to bridge the gap between managers and engineers.

The problem I often see is that managers think engineers have no business sense, and based on the dynamics I observe in engineering teams, I cannot entirely blame them.

Don’t get me wrong—there was a time I was a hardcore engineer myself, totally on board with the typical engineer’s manager-weary mindset. So I’m basically talking about my mistakes here. I just don’t want other engineers to fall into the same trap.

Engineers do need to develop some business sense. That’s why I appreciate those of us who are getting MBAs. I do think getting the right perspective on how business works is extremely beneficial. Not only that, but I’ve said many times a strong foundation in Psychology would help as well (I think software-oriented uni courses should be revised but that’s another rant).

Engineers typically have this attitude of seeing a problem and trying to build the proper solution around it. Most of the time, it’s some sort of architectural pattern that would allow work to flow smoothly as of a certain point onwards.

Now, the problem is that “as of a certain point.” How far in time is that moment? That’s where business gets fidgety, and it’s the source of friction in so many places.

I’m not saying anything new here. The whole point of XP, incremental & iterative development, agile methods was to deliver value incrementally, letting designs and architectures emerge. But we tend to focus too much on the engineering perspective and forget the business perspective.

Whenever they present an engineering proposal, engineers need to learn to always associate, surface, and communicate some clear business objective. And it must be a realistic one. Something that can be achieved and can make the business happy and encouraged to continue.

Do not embark on building a platform to onboard multiple new products if you don’t have a plan to onboard the first product soon (whether it’s the most or least critical in your context depends on the risk you want to take and the type of experiment you want to run).

I once helped a major British publisher deliver a greenfield product. The product owner told us it was the first time in years they were delivering on time and on budget, and jokingly added we were now “in trouble”—we had to keep the momentum going. That meant “we trust you”.

Wet your managers’ appetite with the technical idea, but also sell a clear business value that they can reasonably expect, monitor progress on, and finally receive.

If you satisfy managers with concrete results, you’ll get more ammunition from them. You’ll be seen as trustworthy, reliable, and worth investing in.

Originally posted on LinkedIn.