What does productive look like in your workplace? There has been a lot of metaphorical ink spilled over how to make software engineers (and knowledge workers more generally) “productive.” In the past ~three years or so the discussion has reached a fever pitch, first with the shift towards (and back away from) remote work, and then the introduction of AI tools. Middle management all around the world are meeting in shady conference rooms and hushed Zoom calls, whispering amongst themselves, all asking: is there a silver bullet for productivity?

What brought this to my mind recently was something that, on its face, seems unrelated. There has been a dust-up in the Rust For Linux kernel project recently, causing some maintainer churn and technical (and non-technical) debate. The (overly simplified) argument against introducing Rust code to the Linux kernel is that makes the kernel a polyglot codebase that is harder to maintain. It’s an interesting debate if you’re interested in kernel drama, and I’d recommend the Ars Technica article above and the LWN.net write-up as well.

Some version of this debate has come up on most of the teams I’ve been on: Should we make big change X, or stick with Y? I can’t say that I’m innocent, or that I’ve never tried to garner support for some new thing I’m trying out… I’ve noticed that when the issue is raised by someone (usually a single person) who is trying to get the team to adopt a very different language, framework, or other way of working, it tends to kill the team vibes. When I’ve seen this (and to some degree, when I’ve been this), the person who is trying to introduce something new is unhappy with the way something is currently done. Perhaps the team agrees, or perhaps they don’t; however, even if they agree, they will probably not go all-in on the new thing unless there is some mandate from a higher authority, because they are comfortable enough with the status quo to get stuff done without any changes. The slow pace (or complete lack) of change is likely to make the instigator more frustrated with the situation, and their attitude starts to infect the rest of the team. Vibes: killed.

It seems like it would be in management’s best interest to curb this behavior, but it’s difficult since it is not something that originates in management to begin with. One of the most “productive” projects I worked on in my early career was at Shopbop, a subsidiary of Amazon. My team made widgets for different aspects of the Shopbop site, including a product carousel for a recommendations section. One of the last projects I was on at Shopbop was for an integration with Amazon.com, and we wanted a product carousel there that was similar to one we already had on the main site. We didn’t copy-paste a ton of code, but since we all knew what we were doing, we were largely the same team that shipped the previous widget, and we agreed on the tech stack, we turned out the new widget very quickly.

We were all pulling in the same direction! That’s a rarity, in my experience - but why? I don’t think there’s a single answer, but it’s probably a mix of attitudes from above and below. A common activity for tech company leadership is to (at least performatively) encourage experimentation in the lower ranks, and this can create a culture among engineers of using many different tools across the company. This doesn’t have to be a bad thing, and evolution is good - but the drawbacks have to be acknowledged to, like how it can limit code reuse for repetitive tasks.

Another aspect is the engineers themselves. Sometimes people come into a new team with preconceived ideas about how things should work - and lest you think I sit comfortably in a glass house throwing stones, I do it to! Everyone does this. There’s a certain type of person that I’ll call a “purist” that can be particularly difficult to deal with. They are the person in the situation above who is always trying to get the team to shift towards their preferred stack or methodology, and I’ve seen this attitude kill teams, even when the purist is well-intentioned. If every single work item is an argument about doing X, Y, or Z thing is bad, that’s obviously a grind!

So, what can we, as engineers, do? If you’re struggling with one or people directly, I’m not sure there’s much you can do to reform them, or even that you should. What you can do is recognize when you are in a good situation and hold onto that - they don’t come by often, and they don’t last forever, so enjoy it while you can. As you advance in your career, you can exert your soft power within your team to encourage people to pull in the same direction, and discern when someone is suggesting a change for change’s sake, or if it is something that would make the team culture better. Outside of that, you can learn more about what makes you productive and try to foster more of that. This is something I still struggle with sometimes, because “enjoying work” and “being productive at work” are often correlated, but they are not the same thing (although “not enjoying work” and “not productive” are related I think!) This is something that definitely comes down to team culture, since “pulling in the same direction” is not a technical problem - it’s a people problem.