by Cate Huston*
- Wanting to be right in the workplace - and beyond - can actually hinder progress, says this engineering director.
- Arguing a point with the sole purpose of being right can be a waste of energy.
- Rightness is in the mechanics, she says, while effectiveness is in the outcomes.
- Within disagreements, it is important to agree on the problem, so there is an understanding of what the solution is meant to do.
My partner and I had a hellish move recently. We were lucky in that our landlords are nice, reasonable people, and unlucky in that they were quite disorganized and hadn’t done everything they needed to, like ordering furniture and thoroughly cleaning up after the last tenant.
So as this played out, living in a hotel, in a new (to me) country, trying to juggle his new job, my existing job, and the absolute chaos of everything, our differences started to play out.
My partner, a software engineer, said “they should do these things”. I, an engineering director, started to develop a risk mitigation strategy.
Unfortunately, as we didn’t reach agreement on a strategic level, my risk mitigation strategy was incompletely implemented, and once we were finally able to move in, I spent a week being slowly asphyxiated by residual cat energy.
Now my partner and I, we’re good. And we probably won’t go through something like this again soon, as we’re unlikely to make an international move more than every couple of years. But I see similar dynamics play out at work every day. Specifically, I see software engineers, who relish being right, and I ask them, “Do you want to be right? Or do you want to be effective?”.
And periodically I get into an argument, and I ask myself the same question.
Being right versus being effective
It’s understandable to want to be right, especially in things like software engineering; our “rightness” is how we get the work done. We take a problem, decompose it, implement it, and ship it. Some people take it too far. They say “works on my machine” or “problem between keyboard and chair”, but even the less obnoxious ones take comfort in the concreteness and measurability of their work. It passes the test. It moves the metrics. It’s correct.
Inherently, as we scale, we start working with more people—and when we still search for that definitive correctness, we can miss the overall point. If you’re running a project that requires A and B to ship in order for it to work, and one of those fails to ship, well, your project has also failed. And you can reasonably push that problem to the team that didn’t ship (being right). But if you can rewind, see the problem coming and mitigate the risk, then you can be effective.
The risk of being right is that it optimizes for the wrong things. Rightness is in the mechanics, the architecture, the test coverage, everyone doing exactly what they committed to. Effectiveness is in the outcomes.
Agreeing on the problem
Often when I spot a right-versus-effectiveness disagreement, what I find is that people wanting to be right propose an answer, without first agreeing what that solution is meant to do.
Not that long ago, one of my teams was having an argument about whether or not to run the incident playbook (our standard emergency response procedures) when we have to do a hotfix (unplanned programming to fix a bug in a live system). It seems like an esoteric process point; how can it matter that much? But people were getting really dug in. However, once the conversation became about the problem - measured with data (ie, how many hotfixes we had done recently) - the team quickly resolved both the disagreement and the problem.
When you find a discussion unconstructive, try asking, “What problem are we trying to solve here? How does it manifest? What impact does it have?”. If you’re trying to institute a process change, first get really clear on what you’re trying to solve and sell the team on that.
It’s nice to be the person who proposes the solution and fixes the thing, but shifting into the mindset of effectiveness means you let go of needing to be the person who fixes things and instead embrace the role of facilitator who moves things along. If you get the team to agree on the problem and then someone else proposes the solution you had in mind, that is a huge win. What it means is the solution was never the issue - the lack of insight into the problem was.
Choosing to put your energy into arguing - or not
There’s a great XKCD comic about not being able to get up from your desk because “someone is wrong on the internet,” but both on the internet and at work, you can allow people to be wrong - especially if it doesn’t really impact you.
If someone believes they need to wear their lucky socks on release day, or that 1:1s should never be held on a day next to a full moon, that might seem pretty bizarre, but if those ideas don’t really affect anyone, why worry?
On the scale of actual problems, disagreements about style - someone likes blue, someone likes green, two spaces after a full stop or one - are just… disagreements about style. Feedback and forget. Quote a style guide. State your preferences and move on.
Ages ago, I witnessed a 100-message argument in an email thread about whether code conditionals should be ’var == const’ or ’const == var’. I couldn’t believe the time and energy that went into that thread, but the person who started it had enjoyed the argument - right up until the end, when someone chimed in to say what I had been thinking all along, that so much thought going into something so minor made them wonder what else wasn’t being thought about as a result.
Some people genuinely enjoy arguing. But it’s fine if you don’t. There is no requirement for you to engage in petty debates about things the compiler checks anyway. In fact, if you don’t like arguing, all the more reason not to. Save that energy for things that really matter.
When I’m coaching someone (or myself) through whether they want to argue about something, I ask:
-Why does this matter to you?
-How does it impact your effectiveness?
-What would make it a problem?
These questions help us to uncover the real problem - or if there is one - and allow us to arrive at the conversation we want to have as a result.
If something significantly impacts your effectiveness, it makes sense to fight hard on it. If your biggest problem is hiring, and a particular change will make hiring significantly harder, well, then your job is about to become significantly harder, and that’s something you should explain and push back on. If your overall delivery is pretty good, but you worry this change will slow delivery a little while people get used to it, that’s probably manageable.
When we ask, “What would make it a problem?”, it articulates the second-order effects that we’re worried about, because often the disagreement is not about the present decision, it’s about the impact on future decisions if they go the same way. Maybe a high-profile hire got out-of-band compensation. Is the problem that specific hire and that specific salary? Is that where you want to argue? Or is the problem that if this happened repeatedly, it would completely negate the band system that you have and make your existing engineers underpaid? Perhaps the real argument is that a full compensation review should be triggered if this needs to happen again - and it will probably be easier to get people to agree to that, versus convincing them to sacrifice someone they clearly want and see as exceptional in some way.
Whether arguing for the long term or the here and now, remember: making disagreements shorter and more constructive can be just as impactful as arriving at the outcome you hope to create.
Disagree and commit
During a reorganization at a previous job, the leader of an affected group left for another team. The architect of the reorg was annoyed at this, and framed it as the lead being unwilling to “disagree and commit”. Someone pointed out that “disagree” and “commit” are in fact two separate things. If the lead couldn’t commit, it made sense for him to go to another team.
It completely reframed how I think about the concept of disagree and commit. Disagreement can be an ongoing conversation; we can emphasize different aspects based on why and what we disagree with. If we disagree vehemently, we should think deliberately about what we are and aren’t willing to commit to. By consciously breaking down our disagreement and being judicious about what arguments we engage in, we’re more likely to know the difference.
At my last job, one day my peers and I were having a lengthy argument about whether to bring in an engineering level system to define career progression. There were good reasons to do it; it can help give people a sense of growth and reward, which is why it’s an industry standard. My view was that it would not be a panacea, especially not at that organization (where it wouldn’t be affirmed by or connected to compensation), and I was doubtful it would be a net win overall, because running a promotion process takes a lot of time, and you don’t just get to promote people, you also have to tell people they didn’t get promoted. Anyway, this argument went on until I said, “Well, I’m not going to be the person who does it”. And then it ended. I’m not sure if they had expected me to do it, or if that clarified that no one else was willing to do it either.
“I’m not going to be the person who does this” is something that I would deploy extremely selectively but that experience did clarify on some level the power I had. Being willing to commit to using something is not the same as committing to doing something.
After working in a place where people would greet new hires with “welcome to the chaos”, in order to maintain my equilibrium, I think about things being right enough to allow me to be effective. Not everything has to be perfect. It just needs to be good enough, so that we can get things done together.
*Engineering director, DuckDuckGo
**first published in: www.weforum.org
By: N. Peter Kramer
