5 ms·

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

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.

cpitman 7y ago
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.
- arbitrary_name 7y ago
  Very interested in this topic, as I work in IT and analytics org redesigns and tech strategy. If you have some content or thinking you'd like to share, it would be appreciated!
- sk5t 7y ago
  Are you saying part of your job is to solve learned helplessness in the software engineering workplace? Are you effective?
- to11mtm 7y ago
  > 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.
  - braindouche 7y ago
    how did that change go for you? because I'm living through that transition right now at my company and it's not been smooth.
    - to11mtm 7y ago
      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.
silveroriole 7y ago
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.
- Aeolun 7y ago
  Don’t you have any issues with delivering a product full of crap? I’ve tried not giving a shit, but I feel it’s just fundamentally impossible.
  - Drew_ 7y ago
    Yeah not caring about your product is a quick and easy way to make garbage and then be forced to work OT finishing/fixing your garbage.
  - silveroriole 7y ago
    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.
- plutonorm 7y ago
  This works if you have the right kind of personality. For others it's just impossible and will lead to depression/burnout.
EthicalHacker03 7y ago
This. 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.
- harimau777 7y ago
  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.

cpitman 7y ago

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.

arbitrary_name 7y ago
Very interested in this topic, as I work in IT and analytics org redesigns and tech strategy. If you have some content or thinking you'd like to share, it would be appreciated!
sk5t 7y ago
Are you saying part of your job is to solve learned helplessness in the software engineering workplace? Are you effective?
to11mtm 7y ago
> 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.
- braindouche 7y ago
  how did that change go for you? because I'm living through that transition right now at my company and it's not been smooth.
  - to11mtm 7y ago
    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.

silveroriole 7y ago

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.

Aeolun 7y ago
Don’t you have any issues with delivering a product full of crap? I’ve tried not giving a shit, but I feel it’s just fundamentally impossible.
- Drew_ 7y ago
  Yeah not caring about your product is a quick and easy way to make garbage and then be forced to work OT finishing/fixing your garbage.
- silveroriole 7y ago
  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.
plutonorm 7y ago
This works if you have the right kind of personality. For others it's just impossible and will lead to depression/burnout.

EthicalHacker03 7y ago

This. 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.

harimau777 7y ago
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.