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.
How to do that? Genuine question.
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.
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.
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.
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.
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
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.
Just like every league of legends game, it's not possibly your fault!
This is actually harder for more senior/managerial folks, as often they'll build/buy/create something that's big for their level and now they're committed to this particular approach, which can end up being a real problem, particularly in smaller orgs.
Once upon a time, I worked for a lead who got really frustrated with our codebase and decided to re-write it (over the weekends). This person shipped a POC pretty quickly, and got management buy-in but then it turned out that it would take a lot more work to make it work with everything else.
We persevered, and moved over the code (while still hitting the product requirements) over a two year period. As we were finishing the last part, it became apparent that the problem that we now needed to solve was a different one, and all that work turned out to be pointless.
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.
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.
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.
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.
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.
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.
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.
And it's such a blind spot in the industry that the people most able to build and estimate features and software are left to be the least equipped to see through the end user's eyes.
As such, when you encourage user oriented engineers, these common and often low effort issues can be avoided at the outset which improves velocity organizationally and results in better software and user experiences for projects now and in the future.
Companies that sell to other companies .... don't care about the users. It's one bunch of managers sleezing up to another to make a sale. Whether the product is good to use doesn't matter to them because none of them use it.
A "good" company wouldn't allow this to happen but it happens often enough.
Another bad smell is when developers themselves never use the whole product and simply work on their little bit.
It's how they get to be the experts that are needed.
Replacing their code IS replacing their expertise and therefore them. How would you expect words to change that?
The user, ethically, is another piece of evidence - especially in real time and at huge scale.
So you are so right about the user. The user comes first, the technology second, and when the service of the latter benefits the former, greatly, at scale, the people problems become, well, people solutions - i.e., the user.
A great company basically opens on its first day and 48 hours later there are a ton of well fed customers who come back, not incidentally, again and again for what they perceive, is great.
But apropos feeding customers, if you can't 'eat your own food' dog or otherwise, why expect the user to want to do it ..
Use it. I agree.
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.
> 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
All the juniors I've known in my career never started that way.
I wonder what happens along the way?
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.
I'm guessing you're a PM or have been? You did the classic 'opening agree to disarm, then disagree with a long sales pitch' that they're so good at ;)
It seems to me you're vastly overselling the impact of even the 50th percentile of PMs
I think project management is useful (I'm not going to get in the weeds of PM vs PM vs PO etc). But I feel we've over-promoted classic project managers into roles driving product direction without them having the experience or acumen for it.
I agree with everything else you wrote. Especially the bit about over promoted project managers. That's my thinking as well.
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.
Remember that most communication is non-verbal?