Comment by throwaway416430 | Hacker News Reader

Comment by throwaway416430 | Hacker News Reader

Parent Full thread

throwaway416430

I manage post sales support at a small company where this theme is present, however, I'm concerned that things may be slipping in the wrong direction. I need help dealing with this situation.

Our software engineering team is burdened with tech debt and aggressive product roadmap. Understandably, they often feel the need to push back and keep things under control. Our customers and the employees who are accountable to our customers literally lose sleep when things aren't going well. Our engineering team feels complacent to function on a 9-5 schedule and sleep on critical issues for weeks.

The only thing the engineering team appears motivated to actually own is the next iteration of the escalation process that somehow makes them even less accountable. Invariably the next iteration includes adding more details to Jira tickets that nobody will read.

Basically no one on that team is dogfooding the product. Broken features are being shipped and they are expecting us to actually sell and support this.

Here's what I'd suggest

1. There needs to be reframing of the engineer role in the team, by the leadership. It's not just to build things, but to help the customer. The job of the engineer is to build a good product for the customer, not just to "build", fix Jiras, ...

2. At the same time, get some engineers on customer calls. It doesnt need to be everyone, but you need to shorten the feedback cycle that engineers directly get signal from their users. A lot of information gets lost through Jira's, intermediates, ...

They dont have need talk, just listen. Will they pay attention? That comes back to the reframing of their job being to create a good product for users. If everyone understands that's the goal, they will.

If you have engineers building custom extensions for your database, because your CRM product needs some low level performance optimizations - it'll still be good but less interesting.

The goal is to get some engineers talking to customers, cause they'll talk to other engineers. And engineers know how to talk to engineers. It'll shorten the feedback cycle, and that's good for both speed + signal.

Now I don't know how much of that you already do, and they might even do all these things already, and what you see is the output of the worst issues already taken care of. If the latter is the case, there's some more cross team comms needed

Reply on news.ycombinator.com