[tppiotrowski]

Companies isolate devs from customers by using Product Managers. PMs interview customers and then decide what to build. By the time the tasks get to the dev it’s hard to understand the motivation and impact. The best companies I’ve worked at put the engineers and customers in close contact so they understood the impact and shortcomings in their work. Alternately you need to foster a culture of shared purpose where you have “faith” that your work has impact.

[wreath]

I've seen more engineers completely disinterested in anything customer related (and even calling users stupid!) more than I've seen PMs isolating devs. Every time I ask a PM if I could interact with a customer (not asking for permission, but to hook me up) they were delighted. Every single time.

Another way to solve this problem is to have engineers on customer support rotation of some sort. This way, engineers get to see how their software is used in the wild and interact with customers, and PMs get to see how unrealistic expectations and deadlines comes back to bite you in the ass in a form of your engineers being busy fixing half assed crap.

[reader_mode]

I agree about PM/dev/customer part but disagree on dev/support rotation.

This sounds great in theory, in practice working on any non-trivial software means there are parts you know little-nothing about. Having spent time on support duty I'd end up pinging team members for help (disturbing people without having a sense of priority since I don't do support), budding into other people's stuff without the capacity or desire to follow it up long term.

The best way I saw to get devs into customers shoes is to let developers be involved in client rollout - like ship then on-site and see how people use the feature they wrote.

But frankly even then, devs shouldn't be making a lot of these ae user facing decisions, send the UX guy.

[wreath]

I think it depends on how teams are organized already and the size of the company.

Few things I noticed that made this work in practice:

* Engineers pair up for few rotations with other engineers who are experienced in interacting with customers, triaging issues, troubleshooting issues across the system and identifying which internal service is causing issue and ping the team that supports it and/or move it to their support queue.

* The goal is not to fix every single bug or issue in the queue. Prioritize incoming tickets and gather as much information as possible before moving it to some team's backlog. Solve only problems that you think are manageable within the length of your support rotation.

* One engineer per team or owners of a set of services should on the rotation (this again depends on how teams are organized already).

* Pair with customer support or customer success agents when dealing with difficult customers, situations or need help communication-wise in general.

* Bring in these bugs to your team and make sure stakeholders are aware of them. This is important especially when the team ships something and moves on to the next thing thinking they have 100% capacity for the new project. This is another feedback channel that PMs should be aware of.

* Engineers on support rotation are exempt from their team duties while on support. Again, this communicates what capacity the team will be operating on in the next week or two.

I learned so much about other parts of our product and APIs, how users interact with it, and most importantly (for me at least, since that was the new part) working with people in the company who are not in engineering or product!

[krageon]

> disagree on dev/support rotation

I've worked (as a dev) in a customer-facing industry where devs are generally divorced from customers. Working in support has helped me understand the codebase better (because yes, you usually don't know it all that well if you just fix bugs and build features) and helped me to (at the time) connect with the value some people get out of it. That was nice.

What was less nice is dealing with the angry minority of customers. That was I would say significantly more unpleasant than dealing with the happy minority was pleasant. For that reason I would not recommend interfacing with customers for anyone. There is a reason support agents have such a high turnover.

[kevinmchugh]

The best PMs I've worked with have very clear understandings of customer workflows and needs (or work towards developing them) and communicate those to the dev team. They also make sure to share customer feedback, whether constructive criticism or excitement/thanks.

It's really motivating to hear customers are happy and I don't know why a PM wouldn't share that good news.

[tialaramex]

It is valuable to have someone for the customer to talk to that is on their wavelength (often less technical and sometimes more domain knowledge), and who has more soft skills than you might seek in developers. Calming down an angry customer is a useful ability and that's not what you hired me to do.

However, sometimes the problem is just technical, and every game of telephone makes it worse. I have had two week back-and-forths which were eventually resolved by the agreement that OK, this nerd who does our implementation (me) can be on a teleconference with your nerd who does your implementation so long as us grown-ups are also in the call - and then it takes maybe five minutes to get to "No the digit five. Not the word five, the digit five." "Oh! Oh Wow. I never considered that. Sorry. Yes, it works now." and we're done.

I really valued time spent shadowing people using my software, one of our tools was for call takers, and I could see that the thing they're all kinda used to but have to keep working around is a thing I can fix with a CSS tweak, whereas the change their manager tells us should be prioritised is going to take months. I can land the tiny improvement next week, and make their lives better while their manager argues with my manager about whether the big piece of work is P2 or P3 and so on. The role I'm in theory taking next (if they get their act together and issue me a contract to sign) is more user contact again, and I look forward to being able to make people's lives better directly.

[Aeolun]

Yeah, it’s sometimes a bit distressing to interact with the users directly if you haven’t done so for a while, because you find out they spend hours a day on tasks you never even considered and can literally take away with a few minutes of work.

Asking them to tell you next time doesn’t always work since they just cannot imagine that the thing that takes them hours a day can be fixed in 5 minutes, forever. I think they unconsiously don’t want their hard work devalued like that.

[kevinmchugh]

They also don't have any idea where complexity lies in an opaque system. More than once I've heard about users wanting more control over how a certain view sorts records. Users will pitch strange ways of getting some kind of stable sort. When you realize they want a field tracking creation order or update time they think you invented the idea. (Good PMs can figure this out, too)

[tppiotrowski]

Outsourced operations like contractors are often neglected in the feedback loop. So are SRE’s and parts of the business that are less customer facing. This can lead to lack of purpose. Good companies make sure everyone knows their contribution to the whole.

[davidivadavid]

Documenting and communicating motivation and impact are often pretty high up the priority list for PMs, otherwise you're just a context-free ticket factory, which typically results in subpar products.

[tppiotrowski]

Not in my experience or maybe large companies have so much hierarchy that the PM gives kudos to the dev manager that never trickles down to the individual devs

[formerly_proven]

The project I'm currently the "lead developer" on never had a PM, so we directly communicate with users/customers. Often we are able to implement changes and make them available in a test environment within the hour - people are amazed, because they're used to everything taking days at the very least, usually weeks or months, with a lot of stuff never being fixed and so on.

[mattwad]

just be careful, without a PM you can end up building lots of little features for each client, making individuals happy, but then you end up losing sight of what problem you were trying to solve, and suddenly your product feels very "heavy" for everyone...

[andreilys]

Why do you need a PM for that?

That’s what a good tech lead with a robust roadmap is for.

PMs sprung out of the notion that engineers are anti-social and need someone to keep customers/internal teams at bay so eng can focus on coding.

Of course in reality there are plenty of highly competent tech leads who can both negotiate with customers on a roadmap and build it.

[dahart]

It’s true, there are plenty of engineers who are capable of dealing with customers. PMs, however, did not come from an idea that engineers are antisocial, you’re making assumptions. PMs have long existed in other industries where the very same is true as software; the people building the product are often capable of talking to customers, but don’t.

The reason PMs exist is because it’s a full time job, just like most roles. Being an engineer and/or tech lead is also a full time job. In larger companies, we tend to split out full time jobs. Often in small startups, people have multiple roles. So in a small company you might see someone talking to customers and engineering. In a large company, it’s far more likely that the engineer and the PM are two different people.

[didibus]

The work involved in keeping up with a roadmap, convincing execs that the roadmap is worth investing in, communicating it with the marketing teams, content teams and support teams, tying it back with customer demands and needs, and all that really ends up taking most of your time as a tech lead, and you no longer have time to work on tech design, architecture, training, reviews, coding, testing, etc.

That's where you'd want a PM brought in, the tech lead ideally would work together with the PM on the roadmap, in that technology must be considered when designing a roadmap, feasibility, effort needed, technical complexities, needed tech dept pay backs, needed redesigns, infrastructure upgrades, security considerations, etc. As well as being consulted for what can tech realistically provide as means to solve problems, etc.

That's why I think a PM is needed, so the tech lead can focus on leading the technology, while the PM focuses on capturing requirements, getting funding, coordinating the launch, and all that.

Ideally, there's also a separate dev manager, so the tech lead doesn't have to worry about employee resourcing, project allocation, hiring, compensation, promotion, needs/wants, vacation time, performance, etc.

For all these things, the tech lead should be consulted and have a voice, but freeing them from all this work is definitely a plus, why have your most experienced developer do all this management work?

[robertlagrant]

I think we'd call them PMs once the job gets big enough to need that work done (almost) full time.

[lmm]

Keeping up with the technical side, keeping up with the product side, and keeping the rest of the team informed is usually too much for one person.

[shoto_io]

I am not sure if it's correct, but I have heard that Apple does not PMs in their main product because of that?