6 ms·

And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves.

And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction. The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.

arcbyte 10mo ago
"Better people" solves a lot! But definitely not everything. But a lot!
_def 10mo ago
> Build out what that tech debt is costing the company and the risk it creates How to do that? Genuine question.
- orangebread 10mo ago
  In my experience development has become too compartmentalized. This is why this game of telephone is so inefficient and frustrating just to implement basic features. The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
- SatvikBeri 10mo ago
  If it's been around for a while, look at the last year's worth of projects and estimate the total delay caused by the specific piece of tech debt. Go through old Jira tickets etc. and figure out which ones were affected. You don't need to be anywhere close to exact, it's just helpful to know whether it costs more like 5 hours a year or 5 weeks a year. Then you can prioritize tech debt along with other projects.
  - theptip 10mo ago
    It takes guts to say “this 1 month feature would be done in a couple days by a competent competitor using modern technology and techniques”, and the legendary “I reimplemented it in <framework> over the weekend” is often not well received. But - sometimes drastic measures and hurt feeling are needed to break out of a bad attractor. Just be sure you’re OK with leaving the company/org if your play does not succeed. And know that as the OP describes, it’s a lot about politics. If you convince management that there is a problem, you have severely undermined your technical leadership. Game out how that could unfold! In a small company maybe you can be the new TL, but probably don’t try to unseat the founder/CTO. In a big company you are unlikely to overturn many layers above you of technical leadership.
    - nine_k 10mo ago
      > hurt feeling This is why I incessantly preach to my coworkers: "you are not your job". Do not attach to it emotionally, it's not your child, it's a contraption to solve a puzzle. It should be easy and relieving to scrap it in favor of a better contraption, or of not having to solve the problem at all.
      - hobs 10mo ago
        There's very few people whose brains work like this, it requires constant maintenance and people are ready to fall into the trap easily because they are held accountable for the outcomes, and its easy to pretend your ideas would have saved you from the certain disaster your fellows brought you to. Just like every league of legends game, it's not possibly your fault!
- hnthrow0287345 10mo ago
  If there's a legit, measurable performance or data integrity problem, start with that. If most of your production bugs come from a specific module or service, document it. If it is only technical debt that is hard to understand or maintain, but otherwise works, you're going to have a tougher time of building a case unless you build a second, better version and show the differences. But you could collect other opinions and present that. Ultimately you have to convince them to spend the time (aka money) on it and do it without making things worse and that is easiest to do with metrics instead of opinions
atoav 10mo ago
And all communication problems involve one or more senders and one or more receiver. The issue is you only got to be in control of one side. And even flawless massaging won't save you from incapable or unwilling receivers. As someone who has worked in IT support I have seen users habitually click away clearly formulated error dialogs that told them exactly what the cause of their problem was and how to address it. Only problem? They did not read it, as became clear when I asked them what it said. I have had people who I repeatedly had to explain the the same thing, made sure they got it by having them do it twice and a week later they would come again with the same question like sheep, not even aware they asked that one before. Some problems are communication problems. Others are actual people problems that could indeed be solved by getting better people. Anybody who says otherwise is invited to do first level support for a year.
codyb 10mo ago
This is why I built out a Shadow Sessions program for our internal tooling teams at my BigCo. The users are right there, go make friends. Learn what they're doing day to day. And how it fits into the larger picture. These sessions are lightweight, and auto schedule every three weeks with no required action items and people come out of it amazed every time, lots of little bugs have been fixed, and connections are being made. The culture of not engaging with the end users when they're so readily available is an odd one to me. And you can really get to say 80% of macro picture understanding and user experience design fundamentals with a fairly low lift. To do this I created a sign up form and an auto scheduler that interacts with the Slack API. The scheduling and getting folk on board is the hardest part. Also finding time if you do things outside the product road map.
- strifey 10mo ago
  A bit more heavyweight, but we implemented a rotation program when I was managing an internal tools team at a previous company. We'd trade an engineer from our team with an engineer from a feature team for a quarter. The amount of improvements to our collective understandings was super valuable. Feature devs got to help fix problems with their tools more directly (while also learning that it's not always as straightforward as it may seem), and we brought back much stronger insights into the experience of actually using our tools day-to-day.
- jon-wood 10mo ago
  100% this. Go and spend time with the people using your software. Even better, use it yourself. One of the companies I’ve worked for did food delivery, and in food delivery during Christmas week everybody works operations - either you’re out in a van with one of the regular drivers helping them carry orders that are three times larger than any other week, or you’re handling phone calls and emails to fix whatever problems arise. Either way without fail January every year would see a flurry of low effort/high value updates to the software those parts of the business used. Anything from changing the order of some interactions to fit the flow of dropping a delivery to putting our phone number in the header of every admin page. Absolutely nothing beats going out there and doing the job to discover where the tools you’re responsible for fall over. Bonus points if you can do it at the most stressful time of year when if anything is going to fail it probably will.
vjvjvjvjghv 10mo ago
I think it’s because companies don’t incentivize people listening to each other. Management doesn’t listen to the underlings and the underlings have to compete to get noticed. I have only a few people with whom I can discuss something in depth without anybody pushing an agenda. With most people it’s just about pushing through what you want to do. I am just going through a bunch of sessions where a director has engaged consultants to change our stuff to use a new platform. Nobody who works on the system thinks it makes sense but it can’t be stopped because of the director and a few yes men. Nobody listens.
- tcmart14 10mo ago
  Makes me think of something my dad and I both talked about with our time in the military. He was Army and I was Navy. But when the ability to promote is tied with ranking against your peers, if you really want to game the system, you essentially sabotage your peers. Which is the exact opposite you want in the military or really any organization. You want to foster a, rising tide lifts all boats with getting the work done. But it hard when your performance evaluations are the complete opposite of that, and I have seen people do it. I got qualified on our equipment quick and was in a position where I was training my peers who I was ranked against. If I were an asshole, I would have trained them poorly and drug it out. I didn't, but someone who is goal oriented to climb through the ranks as fast a possible, it is a logical action that I could have taken.
  - delusional 10mo ago
    > If I were an asshole, I would have trained them poorly and drug it out. That's of course the obvious way this goes wrong. Bad intentions. The much more insidious version is that you could have just been a terrible teachers, maybe you suck at training your peers, and you don't know. The end result is the same. You look like the only person who gets it amongst the riff-raff, but in this case you don't even have a choice. The system has produced a poor outcome not because anybody abused it, but because it was a bad system.
deleted 10mo ago
[deleted]
staplers 10mo ago
Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed. Ironically many of the first to be laid-off in a company are those that do this. That's why many companies flail during economic downturns and the problem exacerbates until better economic conditions prevail.
dyauspitr 10mo ago
That’s wishful thinking but not in the way you think. A lot of engineers just want to finish their tickets and get out of there, that’s the reality. They don’t want to be in more meetings with the end user or product. You might have 10% of folks that actually love the job and want to build products at most places.
- hexbin010 10mo ago
  > A lot of engineers just want to finish their tickets and get out of there, that’s the reality All the juniors I've known in my career never started that way. I wonder what happens along the way?
  - throwaway2037 10mo ago
    I have observed two patterns. I can only speak for young men, as I never really worked as an engineer with any women (very tiny ratio over my career). They are hyperfocused at the start of their career, as there is a lot of positive learning and feedback. The promotions (and pay rises) appear quickly. After about 5 years, this slows dramatically as people enter mid-career. This slow down incentivizes many good engineers to enter "cruise mode". Another big one: Family. (A) They get married and/or have children, so the focus of their life changes dramatically. (B) Or something outside of work becomes more important, like a sick parent or relative. I don't write about either of these patterns to criticize people. Did you never slow down? I certainly did.
deepGem 10mo ago
Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Because they want to feel superior as the ‘this was my idea and you executed on my idea’ nonsense. Their answers to most ‘why are we doing this ?’ ‘trust me bro’. I am perhaps generalizing and there are outlier product managers who have earned the ‘trust me bro’ adage, but most haven’t. This PM behaviour will never change. Engineers have said enough is enough and are now taking over product roles, in essence eliminating the communication gap.
- deleted 10mo ago
  [deleted]
- hexbin010 10mo ago
  This resonates very deeply with my experiences. > Their answers to most ‘why are we doing this ?’ ‘trust me bro’. I've profoundly annoyed so many PMs asking this question, I don't get it. I believe it's because they don't want to admit it's because it's an exec's-idea-of-the-week rather than market/biz/customer research and analysis. > Engineers have said enough is enough and are now taking over product roles Fingers crossed. It's about time we up our communication- and managing-upwards skills. I feel many PMs are sustaining their roles just because they're sycophantic yes-men to the execs, because execs got tired of engineers saying "no". Having read a few criticms of PMs on HN, I can imagine the "your companies just didn't hire the good PMs" comments incoming
  - nekitamo 10mo ago
    > Having read a few criticms of PMs on HN, I can imagine the "your companies just didn't hire the good PMs" comments incoming Everything you said in your post is true, especially about 90% of PMs being presenteeist yes men. Indeed most PMs are at best a waste of time, and at worst a net negative to the company and anything they touch. However, a good PM is worth their weight in gold. I maintain the cynical view that 80% of the work done at any large company is useless. That's why a good PM is so invaluable A good PM is the difference between your project aimlessly spinning its wheels and changing directions for 8 quarters (like most projects), or relentless execution with full focus and rewards from higher-ups. Clarifying what executives want, nudging their worst impulses towards something more productive, maintaining focus and clear communication amongst multiple teams with competing priorities, working with engineers to design features and schedule them realistically on the road map, exploring the company beyond your current team to find impactful projects to work on or to join forces with... All these things are exhausting, painstaking, and take a level of attention to technical details and human affairs which most of us don't have the patience or energy to deal with. It's more than a full time job. But if a PM does it successfully, you actually ship important stuff, and that stuff is so important that it moves the whole company forward, and improves the bottom line so much that no one can ignore it. And that's why the PM role continues to exist, despite most of its practitioners being useless suckups. The impact just one PM can deliver by shipping a successful and important project at a large company outweighs all the useless baggage that is the rest of their colleagues. And that's why you continue to invest in your PM org, and hope you get a few nuggets of gold amongst all those turds.
athrowaway3z 10mo ago
I like the phrase "in-house outsourcing shop"
mannanj 10mo ago
Most communication problems are hierarchical problems. Communication and relationships are inherently hierarchical and groups think and social behaviors, fitting in, understanding hierarchy and status runs communication more than we think. Remember that most communication is non-verbal?

arcbyte 10mo ago

"Better people" solves a lot! But definitely not everything. But a lot!

_def 10mo ago

> Build out what that tech debt is costing the company and the risk it creates How to do that? Genuine question.

orangebread 10mo ago
In my experience development has become too compartmentalized. This is why this game of telephone is so inefficient and frustrating just to implement basic features. The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
SatvikBeri 10mo ago
If it's been around for a while, look at the last year's worth of projects and estimate the total delay caused by the specific piece of tech debt. Go through old Jira tickets etc. and figure out which ones were affected. You don't need to be anywhere close to exact, it's just helpful to know whether it costs more like 5 hours a year or 5 weeks a year. Then you can prioritize tech debt along with other projects.
- theptip 10mo ago
  It takes guts to say “this 1 month feature would be done in a couple days by a competent competitor using modern technology and techniques”, and the legendary “I reimplemented it in <framework> over the weekend” is often not well received. But - sometimes drastic measures and hurt feeling are needed to break out of a bad attractor. Just be sure you’re OK with leaving the company/org if your play does not succeed. And know that as the OP describes, it’s a lot about politics. If you convince management that there is a problem, you have severely undermined your technical leadership. Game out how that could unfold! In a small company maybe you can be the new TL, but probably don’t try to unseat the founder/CTO. In a big company you are unlikely to overturn many layers above you of technical leadership.
  - nine_k 10mo ago
    > hurt feeling This is why I incessantly preach to my coworkers: "you are not your job". Do not attach to it emotionally, it's not your child, it's a contraption to solve a puzzle. It should be easy and relieving to scrap it in favor of a better contraption, or of not having to solve the problem at all.
    - hobs 10mo ago
      There's very few people whose brains work like this, it requires constant maintenance and people are ready to fall into the trap easily because they are held accountable for the outcomes, and its easy to pretend your ideas would have saved you from the certain disaster your fellows brought you to. Just like every league of legends game, it's not possibly your fault!
hnthrow0287345 10mo ago
If there's a legit, measurable performance or data integrity problem, start with that. If most of your production bugs come from a specific module or service, document it. If it is only technical debt that is hard to understand or maintain, but otherwise works, you're going to have a tougher time of building a case unless you build a second, better version and show the differences. But you could collect other opinions and present that. Ultimately you have to convince them to spend the time (aka money) on it and do it without making things worse and that is easiest to do with metrics instead of opinions

atoav 10mo ago

And all communication problems involve one or more senders and one or more receiver. The issue is you only got to be in control of one side. And even flawless massaging won't save you from incapable or unwilling receivers. As someone who has worked in IT support I have seen users habitually click away clearly formulated error dialogs that told them exactly what the cause of their problem was and how to address it. Only problem? They did not read it, as became clear when I asked them what it said. I have had people who I repeatedly had to explain the the same thing, made sure they got it by having them do it twice and a week later they would come again with the same question like sheep, not even aware they asked that one before. Some problems are communication problems. Others are actual people problems that could indeed be solved by getting better people. Anybody who says otherwise is invited to do first level support for a year.

codyb 10mo ago

This is why I built out a Shadow Sessions program for our internal tooling teams at my BigCo. The users are right there, go make friends. Learn what they're doing day to day. And how it fits into the larger picture. These sessions are lightweight, and auto schedule every three weeks with no required action items and people come out of it amazed every time, lots of little bugs have been fixed, and connections are being made. The culture of not engaging with the end users when they're so readily available is an odd one to me. And you can really get to say 80% of macro picture understanding and user experience design fundamentals with a fairly low lift. To do this I created a sign up form and an auto scheduler that interacts with the Slack API. The scheduling and getting folk on board is the hardest part. Also finding time if you do things outside the product road map.

strifey 10mo ago
A bit more heavyweight, but we implemented a rotation program when I was managing an internal tools team at a previous company. We'd trade an engineer from our team with an engineer from a feature team for a quarter. The amount of improvements to our collective understandings was super valuable. Feature devs got to help fix problems with their tools more directly (while also learning that it's not always as straightforward as it may seem), and we brought back much stronger insights into the experience of actually using our tools day-to-day.
jon-wood 10mo ago
100% this. Go and spend time with the people using your software. Even better, use it yourself. One of the companies I’ve worked for did food delivery, and in food delivery during Christmas week everybody works operations - either you’re out in a van with one of the regular drivers helping them carry orders that are three times larger than any other week, or you’re handling phone calls and emails to fix whatever problems arise. Either way without fail January every year would see a flurry of low effort/high value updates to the software those parts of the business used. Anything from changing the order of some interactions to fit the flow of dropping a delivery to putting our phone number in the header of every admin page. Absolutely nothing beats going out there and doing the job to discover where the tools you’re responsible for fall over. Bonus points if you can do it at the most stressful time of year when if anything is going to fail it probably will.

vjvjvjvjghv 10mo ago

I think it’s because companies don’t incentivize people listening to each other. Management doesn’t listen to the underlings and the underlings have to compete to get noticed. I have only a few people with whom I can discuss something in depth without anybody pushing an agenda. With most people it’s just about pushing through what you want to do. I am just going through a bunch of sessions where a director has engaged consultants to change our stuff to use a new platform. Nobody who works on the system thinks it makes sense but it can’t be stopped because of the director and a few yes men. Nobody listens.

tcmart14 10mo ago
Makes me think of something my dad and I both talked about with our time in the military. He was Army and I was Navy. But when the ability to promote is tied with ranking against your peers, if you really want to game the system, you essentially sabotage your peers. Which is the exact opposite you want in the military or really any organization. You want to foster a, rising tide lifts all boats with getting the work done. But it hard when your performance evaluations are the complete opposite of that, and I have seen people do it. I got qualified on our equipment quick and was in a position where I was training my peers who I was ranked against. If I were an asshole, I would have trained them poorly and drug it out. I didn't, but someone who is goal oriented to climb through the ranks as fast a possible, it is a logical action that I could have taken.
- delusional 10mo ago
  > If I were an asshole, I would have trained them poorly and drug it out. That's of course the obvious way this goes wrong. Bad intentions. The much more insidious version is that you could have just been a terrible teachers, maybe you suck at training your peers, and you don't know. The end result is the same. You look like the only person who gets it amongst the riff-raff, but in this case you don't even have a choice. The system has produced a poor outcome not because anybody abused it, but because it was a bad system.

deleted 10mo ago

[deleted]

staplers 10mo ago

Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed. Ironically many of the first to be laid-off in a company are those that do this. That's why many companies flail during economic downturns and the problem exacerbates until better economic conditions prevail.

dyauspitr 10mo ago

That’s wishful thinking but not in the way you think. A lot of engineers just want to finish their tickets and get out of there, that’s the reality. They don’t want to be in more meetings with the end user or product. You might have 10% of folks that actually love the job and want to build products at most places.

hexbin010 10mo ago
> A lot of engineers just want to finish their tickets and get out of there, that’s the reality All the juniors I've known in my career never started that way. I wonder what happens along the way?
- throwaway2037 10mo ago
  I have observed two patterns. I can only speak for young men, as I never really worked as an engineer with any women (very tiny ratio over my career). They are hyperfocused at the start of their career, as there is a lot of positive learning and feedback. The promotions (and pay rises) appear quickly. After about 5 years, this slows dramatically as people enter mid-career. This slow down incentivizes many good engineers to enter "cruise mode". Another big one: Family. (A) They get married and/or have children, so the focus of their life changes dramatically. (B) Or something outside of work becomes more important, like a sick parent or relative. I don't write about either of these patterns to criticize people. Did you never slow down? I certainly did.

deepGem 10mo ago

Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Because they want to feel superior as the ‘this was my idea and you executed on my idea’ nonsense. Their answers to most ‘why are we doing this ?’ ‘trust me bro’. I am perhaps generalizing and there are outlier product managers who have earned the ‘trust me bro’ adage, but most haven’t. This PM behaviour will never change. Engineers have said enough is enough and are now taking over product roles, in essence eliminating the communication gap.

deleted 10mo ago
[deleted]
hexbin010 10mo ago
This resonates very deeply with my experiences. > Their answers to most ‘why are we doing this ?’ ‘trust me bro’. I've profoundly annoyed so many PMs asking this question, I don't get it. I believe it's because they don't want to admit it's because it's an exec's-idea-of-the-week rather than market/biz/customer research and analysis. > Engineers have said enough is enough and are now taking over product roles Fingers crossed. It's about time we up our communication- and managing-upwards skills. I feel many PMs are sustaining their roles just because they're sycophantic yes-men to the execs, because execs got tired of engineers saying "no". Having read a few criticms of PMs on HN, I can imagine the "your companies just didn't hire the good PMs" comments incoming
- nekitamo 10mo ago
  > Having read a few criticms of PMs on HN, I can imagine the "your companies just didn't hire the good PMs" comments incoming Everything you said in your post is true, especially about 90% of PMs being presenteeist yes men. Indeed most PMs are at best a waste of time, and at worst a net negative to the company and anything they touch. However, a good PM is worth their weight in gold. I maintain the cynical view that 80% of the work done at any large company is useless. That's why a good PM is so invaluable A good PM is the difference between your project aimlessly spinning its wheels and changing directions for 8 quarters (like most projects), or relentless execution with full focus and rewards from higher-ups. Clarifying what executives want, nudging their worst impulses towards something more productive, maintaining focus and clear communication amongst multiple teams with competing priorities, working with engineers to design features and schedule them realistically on the road map, exploring the company beyond your current team to find impactful projects to work on or to join forces with... All these things are exhausting, painstaking, and take a level of attention to technical details and human affairs which most of us don't have the patience or energy to deal with. It's more than a full time job. But if a PM does it successfully, you actually ship important stuff, and that stuff is so important that it moves the whole company forward, and improves the bottom line so much that no one can ignore it. And that's why the PM role continues to exist, despite most of its practitioners being useless suckups. The impact just one PM can deliver by shipping a successful and important project at a large company outweighs all the useless baggage that is the rest of their colleagues. And that's why you continue to invest in your PM org, and hope you get a few nuggets of gold amongst all those turds.

athrowaway3z 10mo ago

I like the phrase "in-house outsourcing shop"

mannanj 10mo ago

Most communication problems are hierarchical problems. Communication and relationships are inherently hierarchical and groups think and social behaviors, fitting in, understanding hierarchy and status runs communication more than we think. Remember that most communication is non-verbal?