Programming

So I've been in IT management since the 00s, first running a help desk, then moving on to projects, then senior technology leadership incl. running onshore and offshore dev teams. Right now I'm in a sr. dev/service architect sort of role that includes oversight of deliverables from developers.

And it's a tough question. The problem is, you will hear valid points from every extreme. Some will say, get the business people out of the way, let the engineers run the show and solve the problems. And they're not wrong. You will hear some people say, money rules the castle, any behavior that is not aligned toward revenue is a waste of time. And they're not really wrong either. And others will say, the management hierarchy is paramount; do what your immediate supervisor says, and trust the process. Others will say, do what's right regardless of what management thinks, and you'll get ahead. And none of these people are wrong either.

What I've learned through working on both the technical and business sides of the house is that while technical skills comprise assembling technical assets and resources to solve an engineering problem, business skills comprise assembling financial assets and human resources to solve a business problem -- assets and resources that INCLUDE engineering effort. And for the most part, business people do not, and cannot, understand everything engineers do, any more than they can understand everything HR does or everything facilities does or everything sales does. Business people are like the generals pointing to a map; they don't know (or need to know) how the guns and tanks and helicopters actually work. They do need to decide which hill to take, which bridge to destroy, etc.

But damn it, they better listen to the people who DO know how things work.

So, inasmuch as I can answer your question at all, I would answer it this way: developers will be empowered when everybody learns to stay in their lanes... most of the time. Business people should treat development a little bit like a black box: make sure the right requirements go in the Input side, and make sure the right deliverables come out the Output side, and get involved in the innards only when there is a problem with the outputs.

Conversely, developers can -- and should -- analyze requirements critically, develop an understanding of WHY the requirements are what they are, and generally be consulted stakeholders in the requirements gathering process. But ultimately they should not be deciding what to build, because they just aren't going to have the 360-degree picture to understand how the business is going to make money from that output. Those inputs have to come from business-oriented people who are actually charging money to do things (or otherwise know what the customer wants).

That's probably why modern development methodologies like Agile are so tightly focused on pairing the developers with business people who can provide rapid input and evaluate prototypes on short timelines. Keep the inputs and outputs in digestible chunks, but keep the business thinking on the customer side and the engineering thinking on the development side.