Because technical people are often innovators, we frequently face the trade-off between novel and established solutions to problems. If I have a cool new solution to something (a tool, method, etc.), should I use it rather than the old way we’ve done it so far? I’d like to argue here that the old but well-established way is often better, because team unity pays dividends.
Example: React vs. htmx
A few years ago my team at work had a decision to make. We have a web application that hosts purely internal tools. Thus far we had stuck with plain HTML/CSS with server-side rendering in our language of choice, Go. When a situation did arise for a more interactive tool, we introduced some basic React. A while later, another engineer wanted to introduce htmx for a new tool he was working on. (The details of these two libraries aren’t very important to the illustration; just know that for our use cases, React and htmx cover the same ground on web page interactivity. This post is not about favoring either tool or arguing they are identical.)
In most engineering teams, this engineer would simply use htmx or his own thing and move on. The war of opinions would be settled by people doing what they want. This is the “easy” way out, and technical leaders need to recognize the cost of letting this happen. For someone looking to modify these front-end tools, now they have another library to learn. Learning is not free. Cognitive load has increased. Changes have more friction. There are more libraries to update. One engineer or another departing (or moving to another team) is not as easily absorbed. The costs are long-term, for those with vision to see them. This is why our values state, “We value consistent, unified solutions over engineer-specific solutions.”
How did we resolve it?
The engineer advocating for htmx was a good mature one who knew our values and brought it up with the team. (If he had tried to just use it and push it through, I would’ve stopped him and made this discussion happen.) He presented his argument for using htmx rather than React and showed how it would look. In other words, he was given room to persuade us and encouraged to innovate, while respecting the fact that if the team decided against it, we wouldn’t use it.
In this case, team members weren’t persuaded. A majority felt like, despite the larger learning curve of React, we should stick with it. Based on that majority opinion I decided we wouldn’t go for htmx, so this engineer used React instead.
Lessons
This post is a call for technical people to value unity more than doing things “my ideal way”, and for leaders to facilitate this kind of culture.
Why was this engineer willing to submit to the majority opinion? There were several instructive reasons:
He’d been heard out
I encouraged him for well-intended innovation and told the whole team this kind of discussion is well worth our time
We have strong relationships and know it’s not personal
He recognized the value of using one solution rather than two
He was able to handle living in a world where he had to deal with a solution that, in his mind, was less than ideal
I find the last bullet one of the biggest hurdles. Having to deal with legacy ways of doing things can just feel unsatisfying to someone who wants clean, elegant solutions. But our world is a constant mix of good and bad we must learn to resolve.
In the Go world, all code is formatted using Go’s built-in go fmt command. A Go Proverb says, “Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.” This piece of wisdom makes the same point: being consistent about our formatting (small a thing as that might seem) is of greater value than whatever that formatting happens to be. Unity is usually more important than the ideal.
When to Introduce Novel Solutions?
To counter-balance this, there are obviously times to introduce something novel. It’s the role of a leader to simultaneously enforce consistency and encourage innovation. A good leader is in the unique position to help an innovative solution or tool become the new standard by giving freedom to experiment.
If you’re an individual contributor, keep looking out for opportunities to innovate. Present what you find. Persuade others. Get buy-in. Communicate in the way your leaders and teammates need to hear. If you don’t get traction, don’t be discouraged. Keep learning. In due time it will pay off.
Reflection
Do you seek unity in the way your team solves problems?
Are you able to deal with it when not given the option to use the solution (tool, style, method, etc.) that you prefer?
As a leader, how can you encourage innovation while enforcing consistency?
As an individual contributor, how can you discover and present innovations your team isn’t aware of yet?