Hacker News Reader

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.

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.

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.

Yep, exactly, and amazing.

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.

Not using it themselves is why my managment at various companies wouldn't let anyone do sensible things.

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.

Eat ones own dog-food, or in other words, get the company cooking something great together and sharing the results.

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.

I once worked at a company where I couldn't a single person who would have used our product even if they could. "Well, I guess I am not in the target group for our product..." was the most often used excuse. It was very frustrating.

This is evidence that there is a prior element to this 'problem', which is that - in order for Technology to exist, Ethics have to be aligned well enough to deliver, effectively, the result of the technology: a product.

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.

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.

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.

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

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.

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

> Build out what that tech debt is costing the company and the risk it creates

How to do that? Genuine question.

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.

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.

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.

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

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!

More importantly, you are not your code.

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.

but it is their code. It's their achievement. It's their mark on the world that says they were needed and did something useful. They struggled and their passion gave them the strength to get through it.

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?

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

  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.

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.

> 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?

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.

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?

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.

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

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

Yes that's a nice sales pitch for PMs to exist. I have never criticised PMs as being totally pointless. I've worked with some decent enough ones.

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'm an engineer. I don't think I'm overselling the impact of them, I called the majority of them useless lol.

I agree with everything else you wrote. Especially the bit about over promoted project managers. That's my thinking as well.

I like the phrase "in-house outsourcing shop"