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.
I work in a company where we say that everyone is an expert (and to a very large extent this is really true). We create teams of experts, including more business savvy people. Everyone respects each others expertise and makes sure they can apply it as best as possible. We don’t infringe upon each other’s expertise. We might ask another expert about the why or the how, but we should not assume we know better. Obviously this happens sometimes, but then we remind each other that we’re all experts and that an engineer wouldn’t like to be told by marketing how to do their job either.
I think this fits nicely with ‘stay in your lane’ and actually makes it easy to remind people to do so. It’s in the core values of the company that people excel in their lane and cooperate with people in other lanes.
Engineers like to say that business people should get out of the way and let the engineers to their job, but ask yourself how many engineers choose to supervise other human beings. Somebody has to do the hard job of dealing with employee psychology all day long. It’s a messy, “up to your armpits in other people’s lives all day long” kind of job.
You need people who are actually GOOD at that, with all the emotional intelligence it implies, if you want a workplace that doesn’t completely suck.
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.
I work in a company where we say that everyone is an expert (and to a very large extent this is really true). We create teams of experts, including more business savvy people. Everyone respects each others expertise and makes sure they can apply it as best as possible. We don’t infringe upon each other’s expertise. We might ask another expert about the why or the how, but we should not assume we know better. Obviously this happens sometimes, but then we remind each other that we’re all experts and that an engineer wouldn’t like to be told by marketing how to do their job either.
I think this fits nicely with ‘stay in your lane’ and actually makes it easy to remind people to do so. It’s in the core values of the company that people excel in their lane and cooperate with people in other lanes.
Engineers like to say that business people should get out of the way and let the engineers to their job, but ask yourself how many engineers choose to supervise other human beings. Somebody has to do the hard job of dealing with employee psychology all day long. It’s a messy, “up to your armpits in other people’s lives all day long” kind of job.
You need people who are actually GOOD at that, with all the emotional intelligence it implies, if you want a workplace that doesn’t completely suck.