It goes both ways. I've met engineers that want to be told what to do. I think they just looked at their role as "a job" which is fine. There's also people that are really interested in their work and should be included in the design process.
I work in a product role at a mid-size enterprise. I'm happy to involve anyone and everybody in high-level product discussions. But in order to do that you actually need some kind of insight into the business you're actually working for.
How will the customers buy the product? Is this kind of signup suitable for our demographic? How will component Y delivered by ASP vendor X in the value chain be impacted if we do Z? How much money will we (roughly) make for each customer? What will be the total profit potential given N percent of our target customers sign up? Is this initiative significant or insignificant for our business? Is it regulatory compliance or a major new business?
The developer response is (unfortunately) very often a major discussion along the lines of "this should be a lambda function", "no, this should run in our k8 cluster" or "we should migrate the app we just built last year to some fancy new technology I just read about on Hacker News, then we can build this in no time".
Sorry, but that's acting like a craftsman. Acting like a craftsman gets you treated like a craftsman. Management (or I) don't care about serverless or Azure or AWS. And when you don't understand basic business priorities I won't trust the "agile developer" using a three hours fixing a pixel alignment issue on a non-standard Android Phone on the least visited "compliance only" webpage.
I vividly remind a session where one of our SVPs talked about the main business problems and plans for almost one hour in an all-department meeting. One front-end developer raised his hand and excused the slow rate of change of change at a certain (and important) application with "it was built with jquery and no one has touched it since 2014".
The exceptions are (we are not Google) rare and very valuable - which is why they often are promoted. In my experience business intelligence, backend developers and database people are most "business aligned" or "business focused". Front-end developers at the other end.
I'd argue that it's acting like an engineer not a craftsman.
Either way, I'd be thrilled to be treated like an engineer/craftsman. That would be a big step up from "interchangeable cog".
Also, I'm not clear on what's wrong with "it was built with jquery and no one has touched it since 2014". The fact that the system is built using an archaic technology, that technology is inferior to current technology, and the engineers are not familiar with the code base is completely relevant to how long it will take to make changes.
I agree, I think it’s an alternative to answering your SVP with:
“You remember how our entire team left last year because they were fed up? Those were all the people with knowledge of the system.
You also remember how you gave us a budget of 50k to hire replacements? Well, we used it on one developer, and he’s left university this year, so doesn’t even know what jQuery is, much less how to work on that system.
That’s why changes are slow.”
Much preferable to not shame him like that and just summarize it as “It was built 4 years ago with jQuery.”
The problem is that statement is completely ignorant of the audience. An engineer might understand "jquery" as an explanation for slow delivery speed, but it is not the right explanation for the standard exec (notice that you inferred a lot of information from that statement that someone unfamiliar with front-end technology would not).
What the exec needs to hear is "this is built on out-of-date technology that is slowing us down and to fix that we need to be given time to migrate the application to a modern technology".
Problem + proposed solution + no irrelevant details like the name of the technology.
I deliberately became the just a job guy. Why should I bother my arse coming up with “insights into the product” - a product which I don’t own, in a company which I don’t own? They’re still only gonna pay me as a developer. I might as well run my own business if I have to deal with all that. Now I’ll be a short-order cook for 8 hours and forget about work once I’ve left it... at least it’s relaxing.
Yes, I had massive problems with it and it was making me really stressed. I changed jobs to somewhere with more capable leadership, so I could trust the work I was given to not be outright stupid.
In consulting, I run into this type of engineer pretty often. And these engineers often work at companies that are scared of being disrupted.
So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned. It is not easy.
> So my work in "Digital Transformation" is a two part challenge of teaching management to think of their IT department as a source of creative energy and not bricklayers, while trying to get the engineers out of the mindset of bricklayers themselves after many years of being shoehorned.
You're doing the work of a higher order function there. You have my thanks.
I've worked in environments where this type of change has been attempted. It's not easy and does run the risk of running VERY awry.
In one case I've observed, the effort was _honest_. There was a real attempt to make IT have the same seat at the table as the rest of the business. That doesn't mean it was easy, and I wouldn't call it SMOOTH, but the transition itself wasn't that bad. Ironically I think if they had just 1 or 2 different people in the right places during the transition they would have done well enough for themselves I'd wish I was still working there.
In another observed case, well, the process did seem to shine a light on people who's primary duties at work were to make sure they still had a job... In that scenario it can get really ugly because the optics make it look like "We empowered IT and things got worse!" Of course ignoring how the gatekeepers would rather quietly ruin projects before giving another division a 'win'. Leads to a huge fear culture because you start to ask who's going to be the next sacrifice for the lack of real progress on anything.
