3 ms·

How about this? Treat software engineers like they actually know something. If an engineer thinks something is a bad idea, actually listen to them instead of

How about this? Treat software engineers like they actually know something. If an engineer thinks something is a bad idea, actually listen to them instead of pretending to listen. It amazes me how many companies see software engineers as extremely low tier, but I think a lot of that stems from most engineers lacking direct involvement with decision makers and other personnel. This is why I am pessimistic about the concept of having project managers act as an interface between engineering and the rest of the company. On one hand, it relieves engineers of a certain amount of responsibility but the tradeoff is that now one or two individuals have an incentive to do things to please both parties at once. The result is that no one really knows what that engineer guy Al actually does around here. Perhaps a lot of problems around engineering morale would go away if we eliminated the middle men and only engineers themselves to interface with the rest of the company and advocate what they think makes sense rather than what makes sense to a project manager who will only do what results in the least amount of hassle for them. It would be up to the engineers themselves to make sure they aren't culturally segregated and made low tier. If you're an engineer and your company gives the sales people their own desks while you have to share a desk, consider how much that company actually values you.

wreath 5y ago
The alternative is to have engineering managers be the interface between engineers and business, product managers partner up with the engineering managers and team leads do the project management part along with EM. Product tells the team what business problems are worth solving and then gets out of the way completely. EM and Team lead are who decide on timeline and deadlines after consulting with the rest.
- ravenstine 5y ago
  That's essentially what I'm arguing against, although what you are suggesting is somewhat common and is slightly better in that at least someone whom is supposedly an engineer is involved. My problem with your solution is that, practically speaking, engineering managers often end up being glorified vice project managers because of the number of meetings they end up in. As a result, they can be significantly disconnected from the actual technology being used and the perils they are fraught with that can cause complications when implementing even simple features. At least an EM knows something about engineering. And an EM is a role that indeed should exist in some capacity, whether or not that's the exact title they are given. What I believe would be better is for engineering teams to be involved in the early to middle stages of planning and pre-development, and for either an EM or team lead to have the authority to prevent product owners and other departments from applying undue pressure on individual engineers. That should be the primary role of a lead, and they should otherwise step out of the way and let engineers speak for themselves since they are the ones working directly with the software and APIs being used. Otherwise, we end up with a similar problem to the one I witness, which is that the EM in your approach would end up being incentivized towards diplomacy more so than serving the needs of either side. A leader-as-an-interface shields both parties from each other but also facilitates alienation. An EM that works in tandem with the engineering team can make sense, but standing between engineering and other company operations to me is an anti-pattern. Middle men are better off not existing at all even if it means having no EM or PM. All they do is remove power from both sides rather than become involved on an as-needed basis.
  - wreath 5y ago
    Interesting, I guess I've been lucky in this configuration. PMs in this setup have no authority to apply pressure on delivery, thats expected from the EM though. I think a lot of it depends on the characters of people who take on these roles. The diplomacy part you're describing sounds very familiar too and i've seen the complete opposite.
Tarucho 5y ago
We are treated like low tier because in most software companies we are low tier. In command and control structures value is given by position not by contribution. We might be expensive but still low tier. The rockstar programmer, etc. are just silly lies they told us.
- ravenstine 5y ago
  You've a priori concluded that we are low tier, but that's only because companies have a pattern of deciding that we are. This ignores an actual diagnosis and a prescription. Let's put aside for a second that there are many lackluster programmers who happen to also be expensive. The idea that there's "tech companies" and then there's the rest of the economy doesn't make sense, and probably has always been a false dichotomy. Small companies to BigCo fundamentally run on technology. Small hiccups in that technology cause gigantic interruptions. Until we are automated out of existence, they can't get away from us engineers. One might say that software engineers are glorified digital plumbers. While there's a lick of truth to that statement, this is ignoring the fact that you wouldn't necessarily hire a plumber rather than a structural engineer when designing and constructing a building. Just as a structural or civic engineer must do research and calculations for every single job they are tasked with, software engineers necessarily must research and solve unique problems 99.9% of the time. You can't train a software engineer to do one thing repetitiously as what could have been done with a Ford assembly line worker. In software, there is simply no equivalent to being trained to turn the same bolt hundreds of times a day and that becoming your only job. This isn't to say that there aren't repetitious aspects of the software developer's job. Many projects share certain qualities (ex. CRUD apps), and some repetition results from the role of a developer being overloaded. I believe you are mistaken in suggesting there are no "rockstar" programmers. While I would shy away from such a cringe term, though rare they are, I've encountered a few "rockstars" in my time. They tend to do at least 80% of the work, perhaps 90%, by virtue of their cognitive capacity and ability to adapt. Do they make proportionally more than most other developers? Of course not. At best they are viewed as liaisons for their respective teams. I am by no means saying that developers should be the backbone of a company. Although that can and does happen, and my have benefits, developers aren't necessarily qualified to manage or make high-level decisions that will take the business in different directions. Arguably, the hierarchs of companies are of a higher tier than developers because, while the developers are navigating, ultimately those hierarchs are the ones at the steering wheel, to use a somewhat flawed metaphor. On the other hand, developers aren't of equal value to the janitorial staff. They aren't equal value to sales or customer service. They aren't even equal to design teams, since design teams usually can't ship a product themselves, and a product with poor design that does its job well is far better than a Figma document, which on its own is essentially nothing. And yet many companies privilege these other departments over engineering, sometimes even when their core product is software. To put it bluntly, while there certainly are some excellent companies out there that treat engineers properly, too many companies mistakenly view software engineering as a necessary evil and as something that can and should do anything that is thrown at it because they themselves often aren't of the engineering mindset themselves. Most people get educated, "finish" those educations, and thus fail to understand that engineering can't possibly work the way they've treated their own specialties. There is simply no reason why mid to senior level software developers can't be more closely involved with in pre-development and actually be listened to. My hypothesis is that having engineers sectioned off while a project manager or team lead acts as the sole interface with the rest of the company simply doesn't cut it, and it results in the demoralization of engineers because their voice is rarely heard or respected. Engineers think they don't want to be involved with the rest of the business, and while there's a benefit to avoiding possible distractions from coding, this non-involvement comes at an unseen cost. > In command and control structures value is given by position not by contribution. While that is true, and to a large respect is inevitable, that doesn't mean that its logical extreme should play out. No matter what, power politics always emerges. It even emerges among engineers themselves. I'd go as far as to say it's a law of the universe. Yet what happens when that law is amplified to such an extent that one party loses too often? They become alienated and demoralized. Not across the board, mind you. I am not suggesting that all or even most software developers experience these mental health issues because of where they fall in typical corporate structures. But when the problem exaggerates itself, even reaching its logical conclusion (which I have experienced myself), enough people can lose their sense of self worth that no amount of money can compensate for it. In the worst case, the personnel that companies lose are the rockstars, so to speak. To expand on that last point, I myself have experienced being taken to the far end of the spectrum. I once worked for a team that went from having their own offices to a room with their own desks, to a bigger room with shared desks, and finally to a supply closet in the center of a building with no windows. All the while, sales and HR all got their own desks and cubes and were given frequent recognition even though this company's business was selling software. We went from being treated like experts to being sectioned off from the rest of the company and not being consulted for anything. This all happened within a year, and the first people to go were the ones with the most talent (fortunately one of them ended up at Apple and has been there for years now). Yes, that's an extreme example, but this plays out to a lesser degree at many companies. Those whom are solving fundamental problems are often viewed as less than they actually are. By no means am I trying to glorify software development, because there's a banality to it at the same time. But it's not nothing. In fact it's the closest thing to reality that exists in companies that sell digital products. Without solving problems with logic and mathematics, everything else is just fantasy. Businesses will have a better chance at achieving excellence and adapting to problems if they cut out the monkeys in the middle and allow engineers to be involved earlier in processes. Though sadly the vast majority of businesses are actually disinterested in excellence of any kind since excellence conflicts with the traversal of power structures through politics. If businesses fail to hold on to software developers and struggle to hire new ones, it shouldn't be a mystery to them why they are facing that struggle. Maybe developers are more important than some of the traditional roles that they venerate. So no, I don't agree that we deserve to be treated as low tier as we often are.

wreath 5y ago

The alternative is to have engineering managers be the interface between engineers and business, product managers partner up with the engineering managers and team leads do the project management part along with EM. Product tells the team what business problems are worth solving and then gets out of the way completely. EM and Team lead are who decide on timeline and deadlines after consulting with the rest.

ravenstine 5y ago
That's essentially what I'm arguing against, although what you are suggesting is somewhat common and is slightly better in that at least someone whom is supposedly an engineer is involved. My problem with your solution is that, practically speaking, engineering managers often end up being glorified vice project managers because of the number of meetings they end up in. As a result, they can be significantly disconnected from the actual technology being used and the perils they are fraught with that can cause complications when implementing even simple features. At least an EM knows something about engineering. And an EM is a role that indeed should exist in some capacity, whether or not that's the exact title they are given. What I believe would be better is for engineering teams to be involved in the early to middle stages of planning and pre-development, and for either an EM or team lead to have the authority to prevent product owners and other departments from applying undue pressure on individual engineers. That should be the primary role of a lead, and they should otherwise step out of the way and let engineers speak for themselves since they are the ones working directly with the software and APIs being used. Otherwise, we end up with a similar problem to the one I witness, which is that the EM in your approach would end up being incentivized towards diplomacy more so than serving the needs of either side. A leader-as-an-interface shields both parties from each other but also facilitates alienation. An EM that works in tandem with the engineering team can make sense, but standing between engineering and other company operations to me is an anti-pattern. Middle men are better off not existing at all even if it means having no EM or PM. All they do is remove power from both sides rather than become involved on an as-needed basis.
- wreath 5y ago
  Interesting, I guess I've been lucky in this configuration. PMs in this setup have no authority to apply pressure on delivery, thats expected from the EM though. I think a lot of it depends on the characters of people who take on these roles. The diplomacy part you're describing sounds very familiar too and i've seen the complete opposite.

Tarucho 5y ago

We are treated like low tier because in most software companies we are low tier. In command and control structures value is given by position not by contribution. We might be expensive but still low tier. The rockstar programmer, etc. are just silly lies they told us.

ravenstine 5y ago
You've a priori concluded that we are low tier, but that's only because companies have a pattern of deciding that we are. This ignores an actual diagnosis and a prescription. Let's put aside for a second that there are many lackluster programmers who happen to also be expensive. The idea that there's "tech companies" and then there's the rest of the economy doesn't make sense, and probably has always been a false dichotomy. Small companies to BigCo fundamentally run on technology. Small hiccups in that technology cause gigantic interruptions. Until we are automated out of existence, they can't get away from us engineers. One might say that software engineers are glorified digital plumbers. While there's a lick of truth to that statement, this is ignoring the fact that you wouldn't necessarily hire a plumber rather than a structural engineer when designing and constructing a building. Just as a structural or civic engineer must do research and calculations for every single job they are tasked with, software engineers necessarily must research and solve unique problems 99.9% of the time. You can't train a software engineer to do one thing repetitiously as what could have been done with a Ford assembly line worker. In software, there is simply no equivalent to being trained to turn the same bolt hundreds of times a day and that becoming your only job. This isn't to say that there aren't repetitious aspects of the software developer's job. Many projects share certain qualities (ex. CRUD apps), and some repetition results from the role of a developer being overloaded. I believe you are mistaken in suggesting there are no "rockstar" programmers. While I would shy away from such a cringe term, though rare they are, I've encountered a few "rockstars" in my time. They tend to do at least 80% of the work, perhaps 90%, by virtue of their cognitive capacity and ability to adapt. Do they make proportionally more than most other developers? Of course not. At best they are viewed as liaisons for their respective teams. I am by no means saying that developers should be the backbone of a company. Although that can and does happen, and my have benefits, developers aren't necessarily qualified to manage or make high-level decisions that will take the business in different directions. Arguably, the hierarchs of companies are of a higher tier than developers because, while the developers are navigating, ultimately those hierarchs are the ones at the steering wheel, to use a somewhat flawed metaphor. On the other hand, developers aren't of equal value to the janitorial staff. They aren't equal value to sales or customer service. They aren't even equal to design teams, since design teams usually can't ship a product themselves, and a product with poor design that does its job well is far better than a Figma document, which on its own is essentially nothing. And yet many companies privilege these other departments over engineering, sometimes even when their core product is software. To put it bluntly, while there certainly are some excellent companies out there that treat engineers properly, too many companies mistakenly view software engineering as a necessary evil and as something that can and should do anything that is thrown at it because they themselves often aren't of the engineering mindset themselves. Most people get educated, "finish" those educations, and thus fail to understand that engineering can't possibly work the way they've treated their own specialties. There is simply no reason why mid to senior level software developers can't be more closely involved with in pre-development and actually be listened to. My hypothesis is that having engineers sectioned off while a project manager or team lead acts as the sole interface with the rest of the company simply doesn't cut it, and it results in the demoralization of engineers because their voice is rarely heard or respected. Engineers think they don't want to be involved with the rest of the business, and while there's a benefit to avoiding possible distractions from coding, this non-involvement comes at an unseen cost. > In command and control structures value is given by position not by contribution. While that is true, and to a large respect is inevitable, that doesn't mean that its logical extreme should play out. No matter what, power politics always emerges. It even emerges among engineers themselves. I'd go as far as to say it's a law of the universe. Yet what happens when that law is amplified to such an extent that one party loses too often? They become alienated and demoralized. Not across the board, mind you. I am not suggesting that all or even most software developers experience these mental health issues because of where they fall in typical corporate structures. But when the problem exaggerates itself, even reaching its logical conclusion (which I have experienced myself), enough people can lose their sense of self worth that no amount of money can compensate for it. In the worst case, the personnel that companies lose are the rockstars, so to speak. To expand on that last point, I myself have experienced being taken to the far end of the spectrum. I once worked for a team that went from having their own offices to a room with their own desks, to a bigger room with shared desks, and finally to a supply closet in the center of a building with no windows. All the while, sales and HR all got their own desks and cubes and were given frequent recognition even though this company's business was selling software. We went from being treated like experts to being sectioned off from the rest of the company and not being consulted for anything. This all happened within a year, and the first people to go were the ones with the most talent (fortunately one of them ended up at Apple and has been there for years now). Yes, that's an extreme example, but this plays out to a lesser degree at many companies. Those whom are solving fundamental problems are often viewed as less than they actually are. By no means am I trying to glorify software development, because there's a banality to it at the same time. But it's not nothing. In fact it's the closest thing to reality that exists in companies that sell digital products. Without solving problems with logic and mathematics, everything else is just fantasy. Businesses will have a better chance at achieving excellence and adapting to problems if they cut out the monkeys in the middle and allow engineers to be involved earlier in processes. Though sadly the vast majority of businesses are actually disinterested in excellence of any kind since excellence conflicts with the traversal of power structures through politics. If businesses fail to hold on to software developers and struggle to hire new ones, it shouldn't be a mystery to them why they are facing that struggle. Maybe developers are more important than some of the traditional roles that they venerate. So no, I don't agree that we deserve to be treated as low tier as we often are.