“Many Meetings” from “The Lord of the Rings” by Howard Shore 🎵
Teddy Roosevelt theoretically once said “Comparison is the thief of joy.”
It’s ironic that once a year we all then engage in an activity that is exactly that.
I know, I know. Reviews are a needed part of the job. We’re all signed up for annual performance reviews, managers and individual contributors together. It’s just that…
We compare ourself against ourselves. We talk about breath and depth of our career, whether we were able to achieve progress. For the most part, we look back and realize just how much we did and celebrate those wins, realizing we weren’t standing still as much as we thought. This is the great part about it.
But we’re scared others won’t see it. We work really hard to tell our stories. We hope our leadership was on the quest with us – any good manager should have been. We hope our teammates will take the time to write thoughtful contributions.
We say what we want to do moving forward with starry eyes and the knowledge that business will sometimes come in with a new quest we have to get on. We explain the adventure. We quantify our goals. We get through it.
We don’t quantify our happiness.
We know happiness can come with the outcome of the review and the recognition of those results.
But sometimes I wonder, “I know we did all these things, but were we happy?“ I ask it a lot – are you happy? Some people, myself included, will actually drive very hard at hard problems and put this second. Thinking that as long as we hit the outcome, that happiness will be there in the future in the form of praise or reward and that sacrificing it now is worth it. Sacrifice it for a month. 2 months. 6 months. A year. All in pursuit of the problem and the eventual reward.
Performance reviews do not quantify happiness, yet so much of our career and our value, who we are, is about our constant quest of it. I’ve thought what career paths should be doing is enabling happiness most of all and that shouldn’t wait until the review cycle to accomplish that as a result.
Over-Criticism Kills Real-Time Motivation & Happiness
I once saw a manager who wrote about a failed demo.
The demo was on a live stage to the CEO of a Fortune 100 company and other SVPs – it didn’t work and broke in front of everyone. Afterward, the manager was so focused on the “perception of his team” to others that he failed to realize what was happening to his key engineer. This engineer was responsible for the bug, and he was beating himself up. Even though the engineer fixed the problem, he quit a few months later. The engineer was de-motivated. There was not enough care from those above him to see how he felt, not enough “thank you,” that he left the company – humiliated. Thinking he had no path anymore.
They all finished and could put it in their review cycle…The manager however didn’t get promoted. Not because of the failed demo. But because he failed to manage the single most important thing in the process of failure: Retention.
I have absolutely worked with people who almost never praise their teammates in real-time or who design systems completely around escalation culture. If I’ve ever given feedback that I believed what someone did to another team was nit-picking it was because if one believes the pursuit of happiness requires people to see positive impact of their changes, even during failure, then you know there is such a thing as over-criticism. Believe me, engineers are often already beating themselves up when there is a failed change and great engineers own their fixes fast – If that’s the engineers you have, then during a moment of failure, it requires managers who knows when a failure has happened to not focus on the COE (correction of error) nearly as much as championing their people in real-time. They are already fixing the problem. Adding any more baggage to that in the name of over-communication is actually being rude.
I’ve worked with other managers who fall on their sword the moment their team makes a mistake, with the expectation they will regurgitate that failure back to their team, and a customer has negative feedback, not realizing that their team was already beating themselves up trying to fix it. This is a challenging place to be as you have to balance accountability with motivation. When I see this in another manager, I immediate move to support and say “Hey your team did a great job.” Because I realize that the only thing that should have happened was (1) fixing the issue (2) a lot of praise to the team fixing it as fast as possible to (3) prevent people from getting demotivated in real time which comes from the word “Thank you,” not constant criticism which they already have for themselves. Criticism overkill is the best way to end up ensuring your team doesn’t even have a review cycle because they will have left.
We can’t wait for the end of a review cycle to praise our people, that includes those who we are directly responsible for, but also those who work around us. And if all we ever do is call out when something is broken and never appreciate the effort, if that’s all anyone ever sees from their managers and partners, a culture has a real problem.
Happiness can’t wait for a review cycle which is focused on comparison, the thief of joy, to hold up a year’s worth of events that challenge motivation.
Moving Around the Problem
At the same time as this cycle kicks off for so many people, a workload I had been struggling with for four years, came back into view. There were so many blockers for build farm migrations 3 years ago and in ’23 many of those blockers were unblocked. Specifically, in Kubernetes.
Kubernetes used to scare the utter crap out of me. It scared me because I had 0 time to learn it – I was focused on all the other problems that came with build farm workloads – namely trying to help developers troubleshoot that Unity does work on Linux, that you can split the build process into two parts across Linux and EC2 Mac, how to use it with Secrets Manager, and how to solve for storage. Everything people did and did not like about Perforce in cloud providers. I had gotten to the point where a lot of answers had been found about everything but containerization of builds and especially Kubernetes in that context.
In ’22 after studying Kubernetes for months, I wrote myself into a Kubernetes job at Zynga. I moved around the problem.
I kept trying to get closer to understanding what the blockers still were that prevented developers from truly getting everything they wanted containerized. I needed to look at it from different facets. I got more contexts. New problems to solve. And I wanted to more importantly help the people solving these problems because I thought, scaling other people, was a better way to solve the problem.
We Don’t All Solve Problems The Same Way
Marco, a fabulous person at Zynga, had our organization take a personality test last year and I believe I got something along the lines of “Advocate” (one of those INFJ-A or INFJ-T I can’t remember…). I realized, oh “That’s how I solve problems.”
Which is to say, I will constantly spurt out what others have learned, championing their knowledge “so far” until finally we solve every single part of a challenge together. And that takes years. I can clearly look back on most of the projects and draw a direct connected line “moving around” the problems. The jobs were just a way to get in the right perspective to be able to do what was next.
This brings me back to performance reviews – I think a lot of people quest around the problems they are trying to solve but are forced into boxes that may not fit that quest. They try to move up career trees that tell them they have to have influence, build champions with other leaders, do talks, do a lot of interviews. These are all tactical moves that are some ways to solve problems. They are suggestions.
It sucks to look at a box for someone and see “Oh they haven’t interviewed enough people.” We have both a market right now that has a lot of people looking for jobs and simultaneously not enough open headcount at any company to check boxes like that. Good managers are going to look at this and not judge that way. Performance reviews should be done within the context for the year that everyone has had.
But also, I’ve been asking a lot for engineers, “Do they have to move in this specific way to become what is next for them?” Which is to say – do you have to move around in teams or in roles to demonstrate scope? Or can problems grow in depth but still be valuable to the business while still staying exactly where you are? Can scope increase underneath an engineer?
And I think the answer is yes.
Kubernetes, oh how I feared you so much, but you are what taught me that. The landscape around K8s has gotten more complicated in the last 2 years, not less. More providers are building on it. More kinds of workloads are moving to it.
I can’t imagine rewarding for a demonstration of breath that requires engineers to gain scope by moving around as the one way to transform their career, when I’m looking at a space that requires so much depth and complexity of knowledge as a business need. Kubernetes is a space that teams will continue to build on and is growing its own geode of new facets to look through.
You Need Both
I have moved around problems for 15 years and now that it has a name, “advocate,” I guess I can say that being able to “solve problems” that way has made me happiest. Though it’s not the best for building tenure or retirement portfolio.
I also know that those who grow depth by staying in the cavern of reflections illuminated within new landscapes – those individuals also have value to an organization and redefine scope. They explore what is often scary territory, Mines of Moria[2] if you will, with years to uncover and no guides – at the risk of being seen as “not flexible” when it comes time for reviews. I believe that companies and teams need both types of problem solvers to be successful in challenging times. They need both those who stay on the surface and bring supplies into the cave constantly reporting back out to the world, and those who go spelunking. Both aim to unite perspectives.
You need people who are willing to be flexible and adapt and move around within your organization (or in and outside of it), but you also need people who are willing to get exceptionally deep and stay in their same team because some things take that much time to bloom a whole portfolio of engineering patterns.
And I’ve started to recognize those who are flexible and want to move around the problem across people as one type of engineer, who is often rewarded for this flexibility, and those who are flexible in the caverns of “the problem” as another, often overlooked because they stayed too deep within their trajectory of focus. It’s the second that often feels trapped from happiness and progress when forced into the exercise of “comparison is the thief of joy.”
And it’s the second that often is used the most without the words “thank you” nearly enough and has the most risk for demotivation when organizations do not value that type of depth. Yet we are completely dependent on them for success.
I’ve come to realize, when we put these two types of people side by side, they both move around the problem in necessary ways. Comparison doesn’t have to be the thief of joy. We only have to have appreciated for a full year the facets of comparison people bring so that when we get this cherished time to reflect not only on ourselves, but on each other, we can look back and say, “They were happy.” and that this time is just one final “thank you” in what should have been a years worth of gratitude to overcome the work that challenges our motivation.
Header Image by Sergio Garcia from Unsplash.
–
[2] This is the second clue to the puzzle.
