by jeffheard 15 hours ago
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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?
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!
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
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.
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.
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.