I’m going to allow myself to talk about this problem because I was once one of these precious snowflake engineers. Acting like a snowflake hurts everyone involved. In my work with tech executives, I see this originating from sympathizing too much with your staff or a tendency to put your people on a pedestal because the market is crazy and you fear angering someone.
Nevertheless, this extra coddling has the bad effect of slowly degrading the R&D team’s ability to move rapidly and provide a decent ROI. Letting things go on like this might be easier right now, but that’s a classic case of sacrificing the long-term success of your team for some quiet right now. Not the kind of tradeoff I’d counsel people to make.
Here are some snowflake-generating patterns to help you assess whether you’re complicit in this cultivation.
Allowing Special Treatment
If you’ve been leading engineers for more than a day, you’ve heard complaints about the way others in the company are doing their work. Product is not creating specs that make sense. The design team “doesn’t understand how the web works.” Don’t get me started about QA. Right?
I’m not going to say that none of this criticism is worth hearing out. I want to stress that many people—and R&D people seem more prone to this than others—are overly attentive to others’ mistakes and not enough to their own. That is why we feel like it makes sense to demand perfectly defined specs before we start the work—to save every precious millisecond of coder time—but shrug it off when our pull requests routinely get marked with lots of misunderstandings and little bugs.
Do not tolerate the “us vs. them” mindset because it is harmful to the company’s health and will make most cross-functional product team structures unmaintainable. In The Tech Executive Operating System, I write about these sorts of culture adjustments.
Tech Glorification
Naturally, engineers tend to like software, code, new tools, and learning it. That’s often what makes them good at their craft. For me, the issue starts when they are allowed to steer things in directions that make no business sense just to allow them to remain happy. You know the drill: a couple of engineers demand that you let them write the new micro-service in Rust, and you agree because you’re afraid of stymieing their creativity.
That then triggers a snowball effect where the team gets used to creating tech for tech’s sake. With time, this creates a disconnect between them and the actual product they work on. You get people who join the team just because they were passionate about a new programming language and couldn’t care about what the code is eventually doing. This tech-product gap is the recipe for a team that cannot deliver real business impact.
No Harsh Feedback
Another form of coddling is the overprotection around any real feedback. When this happens with the less experienced staff, it entrenches them as Peter Pans: employees that remain juniors forever. In my opinion, though, this is most problematic for the more senior staff. These are the people that are already quite adept at what they are doing, and so leadership can often shy away from providing them feedback or actively working with them to become better.
Lacking the ability to tell them the truth, the willingness to confront them with areas where they need to improve or the courage to coach them is detrimental to their professional improvement and your team’s long-term health.
This can also manifest in forming organizational debt as you work around those people that didn’t get real feedback or that you were afraid of angering. For example, they didn’t prove to be good managers as the team grew and so were left managing a small token team. Or they were given a unique role and responsibility only in order to make them happy and ensure they didn’t leave.
The more snowflakes you gather around you, the harder it is going to be to create a world-class engineering organization. In my opinion, that’s not much of a choice.