Taking on some of the responsibilities for HR in my various company building experiences, I developed a lot more empathy for the work those teams do.
Untangling sticky situations with people isn’t always fun. Doing it well is extremely valuable, and requires a tremendous amount of expertise and skill. Working with a great people team makes such a difference.
And so I can understand the exhaustion and exasperation that people teams and leaders more generally feel for what we might call squeaky wheels. The random complaints that seem trivial in the bigger picture. The demands that don’t square with company goals or finances. Wouldn’t it be nice if people put their heads down and “just got it done”?
Much as I can see where people are coming from, this perspective has always irritated me on an intuitive level. It took me a little longer to flesh that out and turn that intuition into something more persuasive.
I think it boils down to the importance and value of listening.
Building a company is a lot more than building a product or service people want to buy. Unless you’re a solo operator, it also means building an employment “product” — the jobs you want people to fill — that people want to buy through offering their labor and commitment.
In the same way that you’d always want to hear out a customer or end user’s perspective on the company’s product-product (or service), I think people with concerns or issues with the workplace probably have something we can learn from. Paying attention to these squeaky wheels can be incredibly valuable. They can help identify issues when they’re small and treatable, so you can deal with them before they blow up into a real threat. We ignore them at our peril.
I’ve seen these dynamics at work in all sorts of situations. The internal developer experience is a great and obvious starting place.
When you’re in the earliest stages of building something, you have to be extremely expedient and, of course, there’s no existing developing tooling or scaffolding to work against. Unless you have serious backing and tremendous runway, you probably don’t want to spend the first six months of your company’s existence setting up the world’s most sophisticated developing tooling and experience. You’d be far better served trying to actually build out the product, so you can get validation and start the journey to product-market fit.
But eventually this has to change if you want to scale up the team. Certain patterns are too fragile to repeat. Others are too difficult for a newcomer to immediately pick up without an unreasonable amount of help and time.
If you were the first engineer to join a company, and your development environment accreted on your computer as the product and company grew, you may not even know how to reconstitute your development environment.
New people joining and inevitably complaining that it’s a giant pain to get going is an incredibly valuable signal. While it’s always possible you made a bad hire, odds are those are reasonable complaints worth taking seriously.
Far better to address the problem early — when there’s only one or two people struggling to get started and maybe only one complaints about it — than to put that off until you’re hiring ten people and waiting around to get that whole team started.
Certainly, this doesn’t mean that every complaint needs to get escalated and given the white-glove treatment. In the same way that not every issue or bug raised by a customer or end user needs to turn into a red-alert problem and addressed immediately. Maybe it doesn’t ever need to be fixed.
A great people and leadership team should be able to hear these issues, find deeper patterns, and triage them accordingly.
I’ve often found that people who have something on their mind may not even know what the solution is. Someone complaining about the bad internal developer experience may suggest someone write a 20-page set of documentation for getting the hodgepodge development environment set up. In reality, it might make more sense for someone to take that environment and get it set up in a containerized environment with tools like Docker at Gitpod, addressing the problem even more robustly.
It’s the same skill that I tend to look for in great product teams and product managers.
Nor does every squeaky wheel indicate the company needs to change something. It could just as easily be an early warning sign that someone isn’t as good a fit for a given position as you may think.
Early-stage companies are definitely not for everyone. A lot less has been figured out. The odds of you staying in a narrow lane with well-defined responsibilities — the way you might have at a very large, mature organization — are virtually zero.
In the early-stage context, complaints from my proverbial squeaky wheels asking for the kind of certainty you’d find at Microsoft aren’t an indication the startup needs to give people Microsoft-level role definition. Rather, it would indicate to me that person doesn’t want to work at an early-stage venture. It might be worth asking them a little more pointedly if this is the role for them — so you can find someone else who’s a better fit — rather than waiting for the issue to devolve to the point you’re caught out with one fewer developer or salesperson than you were hoping for.
Becoming the vessel and punching bag for people’s gripes and problems isn’t the most fun. It’s one of the many examples I give to people contemplating the leap into people leadership from a more purely technical role. But tempting as it may be to brush off complaints or see them as an annoyance coming from people who don’t see the big picture, I think that’s ignoring a set of valuable signals. These annoyances could be a blessing in disguise.
Enjoy this? Have an idea for something you’d like a perspective on? Drop me a line: I’d love to hear from you.