Pick Your Disagreements

So you think you can lead a team?

I’ve been talking and writing a lot about leading a software engineering team in 2025. I started thinking about it more deeply the year before when I decided to give a colleague, who was moving into team leading, some advice:

• 'Doing the work' isn't the only way to add value
• Remember to delegate
• Pick your battles
• Talk to your team every day

Out of this came a talk, “So you think you can lead a team?” which I gave at work, at meetups and at conferences in various different formats during the first quarter of 2025. I am also turning these ideas, and more, into a book I hope to release towards the end of 2025. I’ve already explored delegation, you can read about it here: 

https://paulgrenyer.blogspot.com/2025/04/remember-to-delegate-triangle-of-trust.html 

And Seeing the Bigger Picture, you can read about it here:

https://paulgrenyer.blogspot.com/2025/05/see-bigger-picture-and-look-around.html

When I started writing the material for my talk for ‘Pick your battles’, I thought about all the lead roles I’ve had and I realised that I am dreadful at it! This is a real slide from my talk:

Over the years I have tended to jump into every issue, argue every point, and wear myself out over things that, in hindsight, weren’t worth the energy. Recognising that was uncomfortable, but also liberating. It made me realise how much I need to develop in this area. Not just to protect my own peace of mind, but to be a better team lead and person. Hopefully this will be part of that development.

Pick Your Battles

When Gail Ollis, a now retired software veteran and good friend of mine, watched one of the videos of me giving my talk on team leading, they, with good reason, expressed concern about my repeated use of the word ‘battle’. As I’d used the phrase ‘Pick Your Battles’ as a starting point, I’d subconsciously framed the rest of the section in terms of battles. 

Before trying to find something which more closely fitted what I was trying to say, without potentially aggressive undertones, I wanted to understand where ‘Pick Your Battles’ came from, so I asked ChatGPT and it told me:

The origin of the phrase comes from "choose your battles wisely," which reflects the strategic thinking required in military contexts. The idea is that a good commander doesn't engage in every possible fight, but instead focuses on the ones that are most important or winnable. This principle is ancient, but the modern idiomatic usage probably became popular in the 20th century.

Possible Influences: 

• Sun Tzu’s The Art of War (circa 5th century BCE) expresses a similar idea: “He will win who knows when to fight and when not to fight.” 
• The phrase started to appear in parenting and self-help literature in the mid-to-late 20th century, emphasizing the idea of not wasting energy on unnecessary conflicts.

Software development in a team is lots of things, but it isn’t war. I started to look for alternatives. Conflict isn’t much better as it means a serious disagreement. However, disagreement is a much better fit as it’s a difference of opinion.

Software engineers, including team leads should: ‘Pick their Disagreements’. Disagreement is not as wide a term as ‘battle’, so I am extending it, for my purposes here, to include when engineers decide to try and influence other engineers. 

Let’s look more closely at how and why software engineers disagree.

Pick Your Disagreements

Why do Software Engineers Disagree?

Disagreement and the need or desire to influence others is part of everyday life, software engineering in general and a big part of team leading. Software engineers, including team leads, are among the brightest people you will meet. They have to be; writing software is hard, writing it well is harder. In my experience they are also very sure of what they know and sometimes they might even be considered stubborn. I am no different, but I’m trying to be better.

One of the reasons software engineering is hard is that there is rarely only one way to solve a problem. What is considered good practice, in any software engineering context, often comes down to someone’s experience, opinion or even current fashion. This means that often, two or more software engineers can have very different opinions about how a problem should be solved. This often leads to disagreement.

Most of the teams I have worked on have been made up of engineers with varying levels of experience. Sometimes these differences were formalised with titles like junior, mid, senior, and lead. In most cases the teams operated in a flat structure when it came to discussion and disagreement. Everyone’s opinions were listened to, regardless of their title or experience. At the time I assumed this was just how teams worked. However, after further investigation and lots of talking to people both inside and outside of software engineering I’ve come to realise that this approach is more common in software engineering than in many other fields. In software engineering, flat hierarchies and open discussion seem to be the way, especially on high functioning teams. 

Outside of software engineering, however, I’ve heard more about rigid hierarchies, where decision making often follows formal lines of authority rather than shared reasoning. This contrast has deepened my appreciation for the inclusive, idea-driven culture that many software teams strive to cultivate. This openness creates space for people to bring strong ideas and strong opinions to the table, which naturally leads to disagreement.

In his book How To Win Friends and Influence People Dale Carnegie points out:

"...a successful person loves: the game. The chance for self expression. The chance to prove their worth, to excel, to win. The desire for a feeling of importance."

Healthy competition between team members, team leads, teams and even organisations will inevitably cause friction and disagreement. As a team lead you should be open to your team disagreeing with you. One of your team leading responsibilities is to guide, but those you are guiding will often not agree.

Disagreement is a natural part of software engineering, especially in teams where intelligent, opinionated individuals work together to solve complex problems. With no single right answer and practices shaped by experience or trends, differing views are inevitable. 

Now that we have a better idea of why software engineers disagree, let’s take a look at some of the things they disagree about. 

What do Software Engineers Disagree About?

Software engineers can, and do, disagree about anything and everything. I won’t even try to list it all, there is just too much. What I do want to do is give a flavour of the breadth of things we disagree about. Often it’s not even the technical details. 

Changing Requirements

Change is inevitable. I’ve already mentioned that being a software engineer is hard. Software is also complicated, but easy to change. If you compare software development to the mechanical aspects of engine design and development (putting aside that all modern engines use a lot of software), the pistons, cylinder, crank shaft, valves, etc. are relatively easy to understand. You can hold and understand the relationships between the components in your head all at the same time. Conversely, software systems have more moving parts (pun intended) and it is often difficult to hold the complexity of just one part of the system in your head, let alone how it all relates to the others. If you need to change something in an engine, the part takes time and cost in people and materials to redesign, manufacture and test. Whereas in software development, you change or throw away the old code and write more code relatively easily.

For example, if your Formula 1 car is racing in Australia tomorrow and you realise you can make the car lighter by redesigning a part, you’re stuck because it has to be redesigned and manufactured back at the factory in the UK and shipped out. However, if you realise you can go faster by changing the point at which a valve in the engine opens, the software can be changed there and then and uploaded into the car in minutes. If the part does arrive in time and it’s not right or it breaks after 10 laps, there’s no time to change it. If the valve timing makes the car go slower, you can change it again in minutes.

The complexity of software means that it is more difficult to predict what is needed and how it will work. However, It is also easy to change and therefore requires less up front design. Often we, as engineers and the client (the person or organisation who needs the problem solved) learn new things after the development of the software has started and sometimes even as a result of developing the software, and change is then required. This is why Agile development is usually a better fit than Waterfall for most software projects.

Change is inevitable at all stages of software development and can cause friction and disagreement.

Change often invalidates previous work. Engineers naturally want to feel that their efforts are building towards something stable and valuable. When code is thrown away or rewritten due to changing requirements, it can feel like wasted effort, even if it’s part of a necessary learning process. Multiply this over a large, fast-moving project, and frustration builds, especially if changes seem avoidable or poorly justified.

Timescales

A few years into my career I had a manager who often said “....you’re not working in a vacuum, you know!” They were frustrated because I was always focused on doing what I thought was technically right, without considering the wider organisation. I wasn’t seeing the bigger picture, I was focused on the engineering, sometimes for the sake of it, not the purpose of the engineering. This is common in engineers, but gets better with experience.

Organisations have goals and priorities; which they employ software engineers to help meet. Sometimes they shift due to things like changes to the market the organisation operates in, changes in people at the organisation, regulatory or compliance changes, and for many other reasons. This can mean, for example, that a new feature might need to be delivered in a shorter than ideal space of time or that a new feature may not be released for some time after it is ready. This can cause frustration for software engineers if we don’t feel we can deliver software of the right quality in the timescale or our work feels wasted when it’s ready and not being used.

As with requirements, changes to timescales are inevitable at all stages of software development and can cause friction and disagreement.

Coding styles

Should an IF statement always have curly braces, even if it only contains a single statement? Should you use tabs or spaces for indentation? Should library functions and models be declared close to where they are used or grouped at a higher level? These are examples of things in software engineering which can be considered ‘style’. They don’t cause the software to break, but can, arguably, make the code easier to maintain, read or navigate. Sometimes there are guidelines which cover style, but not always. Without agreed guidelines there is plenty for engineers to disagree about.

Non-technical

Many, if not most, software engineers would prefer the majority of their time at work to be spent writing code. That was certainly how I felt for about the first ten years of my career. Unfortunately there is more to working as a software engineer than writing code. As a bare minimum you need to interact with your team, your team lead and/or whoever gives you the requirements. In larger organisations, especially those which are large corporates, there is even more: technical training, non-technical training, team building, large organisation meetups - especially in distributed organisations or those whose staff working remotely or hybrid - having to give a presentation, set personal goals and more. 

Engineers are often reluctant to engage in these often soft skill focused activities and it is often a source of friction and disagreement, and often difficult to avoid. I’ve included a more detailed example later on.

What colour it should be?

Ideally a cross-functional team includes a designer who is an expert in how the software should look and how it should work. That’s where accountability should lie. Analytics should be used to measure how users interact with a UI and the results of A/B tests used to determine how it looks and how it works. Not every team is this fortunate, however, and even when they are there is often disagreement.

An organisation may be considering two different colour schemes in a rebrand. One or more engineers may prefer one to the other. Two different teams who have components in the same UI may disagree on placement as they have differing and competing driving forces. One engineer may feel it’s better to have an accordion which allows a user to enter their address open when the user lands on the page and another thinks it should be closed. I would expect all engineers to agree that consistency is important: if the button is red on one page, the same button should not be green on another.

I was in a meeting where one of my engineers was demonstrating the work they’d done, on a User Interface, to our designer. The designer noticed a button which was not on the new designs and asked the engineer to remove it. The engineer argued that the button was needed. The two couldn’t agree and eventually I stepped in to make the decision.

When it comes to the way user interfaces look and work there is plenty to disagree about.

Software engineers are bright, experienced people with broad opinions, so they often disagree with each other, their team lead and those around them. However, not all disagreements are worthwhile, so let’s look at what you should consider before you disagree.

Before you Disagree

How to Win Friends and Influence People by Dale Carnegie is an excellent book which, in my opinion, everyone should read at least once. It has helped form a lot of my opinions and practices related to how people should be treated and what I would like my leadership style to be. The book was published in 1953 and is a book of its time, so where I’ve included extracts I’ve also updated some of the language.

The book is divided into four sections and the third is about How to win people to your way of thinking. Each section has a number of chapters and each chapter ends with a principal. The first chapter in this section is You can’t win an argument and the principal is:

“The only way to get the best of an argument is to avoid it.”

Carnegie uses lots of examples to get his points across and a few statements. The statement that really stands out for me here and demonstrates the principle is:

“You can’t win an argument. You can’t because if you lose it, you lose it; and if you win it, you lose it. Well suppose you triumph over the other person and shoot down their argument full of holes.... Then what? You will feel fine. But what about them? You made them feel inferior. You have hurt their pride. They will resent your triumph. And a person convinced against their will is of the same opinion still.” 

What  Carnegie is telling us is that when you disagree with someone, consider what you might gain or lose by raising that disagreement with that person and whether the outcome and the side effects of the discussion are worth it. 

If the only way to get the best out of a disagreement is not to discuss it, when you feel yourself disagreeing with someone, stop and ask yourself three questions:

• Does it matter? Do I really want or need to die on this hill?
• Is it my disagreement?
• Is now the right time?

If the answer to the first question is no, that’s great, you can just move on. If it’s yes, then it needs to be your disagreement to have and the right time to have it. Let’s examine each one in turn before exploring some strategies for disagreeing.

Does it matter?

Every year, at a holiday company, all their employees have to complete some basic online training. It covers everything from how to detect fraud and avoid data breaches, to which fire extinguisher to use and to how to handle a virus outbreak. Most of the training is not relevant to the software engineers who work for the organisation and there is a reluctance among them to do it. Inevitably the deadline passes and some of the engineers haven’t completed the training.

I can be quite competitive and one year I decided that not only would my team complete all the training on time, we would be first. I asked my team to make the time for the training and get it done. Most of them did, but one kept putting it off. I often reminded them and they continued not to do it. I let myself get quite annoyed to the point that I was complaining to my boss about it.

I was expecting support and advice on how to get the engineer to complete the training, Instead, my boss looked a little perplexed and commented that it was a funny hill for us both to want to die on. I went off a bit irritated, but kept thinking about what they said.

Not long after I realised that the only thing at stake here was my ego. I wasn’t accountable for whether the engineer completed the training and it wouldn’t affect the team or the engineer’s ability to meet the goals I was accountable for. So I called the engineer, told him I was wrong and apologised. Then I let it go. Of course I completely failed to get the best from this disagreement, but I learnt my lesson: it didn’t really matter.

Is it my disagreement?

Sometimes, something outside of your accountability or responsibility will not seem right, and you’ll have the desire to put it right by discussing it with the person responsible. In most cases, "outside of your accountability" will mean another team or something else in the organisation which doesn’t affect you or your team, directly or indirectly. But should you? Sometimes you should; sometimes you shouldn’t.

Some organisations have a clear separation between software engineering and platform engineering. While I am predominantly a software engineer, I also have an interest in and some experience with platform engineering. 

I’d been working on a new way of storing secrets (e.g. API keys) in AWS with the platform engineer allocated to my team. The new way solved a number of issues we had, such as removing the need to duplicate secrets and making secret rotation easier. Soon after I heard about another team who were, it appeared, about to store a new secret in the old way. 

I contacted the team’s platform engineer and started saying I thought it was the wrong approach, and what the right approach was, and they had checked with the platform engineer on my team. They said that they were sure it was the right approach, but they would check.

A few minutes later I had a message back from my platform engineer saying that the other team were using the right approach and pointing out what I had missed in the code I reviewed. I was sure I was right, so I rechecked the code. But I was wrong.

Not only had I interfered with a team whose work I was not accountable for, I'd gone off half cocked (we’ll talk more about that later on). If I’d asked myself ‘is this my disagreement to have?’ and answered it properly, I would have paid more attention to the fact that I wasn’t accountable and not wasted the other team’s time and my own on a disagreement which wasn’t mine. 

Is now the right time?

There is a further dimension to the engineer who was reluctant to complete the basic online training. They were actually going to leave my team to join another before the training was due to be completed. The move had been in the pipeline for a while and was amicable. So not only was the completion of the training not a hill I wanted to die on, it was going to sort itself out in time anyway. All I needed to do was wait.

It’s something I’m actively working on avoiding, but sometimes I still see red and spark an unnecessary disagreement - this results in me losing, even if I win. Perhaps I’ve read something in an email about a change which affects me or my team and I feel I haven’t been consulted. Or someone says something in a meeting which triggers me, or reminds me of something which I disagree with that I wouldn’t have chosen to raise at that point and I dive into a disagreement I don’t need to have. In a lot of situations, if you stop, think and maybe even count to ten, a disagreement can be avoided or shifted to another time when it can be more constructive. Often, I don’t yet have all the information, and just giving things a bit of time, having open conversations, calming down, or waiting to see if the missing details show up, can be enough to avoid a disagreement.

Sometimes technical things can wait as well. Most teams are reliant on other teams or third parties for things. A team I was working with needed some enhancements to an authentication system so that a user could move from one application to another without having to log in again - you’ll most likely know this as single sign on. The other team described how the current single sign on mechanism worked and, in my opinion, it was less than optimal and they should build something different instead. I bit my tongue and waited as the team lead on the other team described how they knew it didn’t fit the requirement in the best way and that they were already working on a better solution which was coming down the line. Had I jumped in and expressed my misgivings about the current implementation too soon, I may have sparked an unnecessary disagreement.

Always wait, until you’re sure it’s the right time. The right time may never come, which is great as the disagreement will be avoided. When the right time does come, wait, count to ten and be sure.

If you must disagree, make sure you disagree in the right way. Let’s look at how to do that.

If You Must Disagree

If you’ve found a disagreement:

• that is worth having
• that is within your sphere of responsibility
• and now is the right time to have it

then the only thing left is to have the disagreement. It is important to disagree in the right way for the person or people on both sides of the disagreement. 

Don’t Go Off Half Cocked

The phrase "going off half-cocked" means acting or speaking without thinking carefully, planning properly, or having all the facts. It often implies someone is impulsive, rash, or jumping to conclusions too quickly.  It comes from old firearms, if a gun's hammer was only half-cocked, it wasn’t ready to fire properly. Trying to shoot it in that state could cause a misfire.

I’ve lost count of the number of times I’ve jumped to the wrong conclusion, haven’t understood all the facts or everyone's point of view and dived into a disagreement I didn’t need to have. It usually gets heated quite quickly, especially as the engineer immediately feels judged, blamed and defensive. At some point, I realise I’m wrong and I end up feeling bad and embarrassed and have to apologise to all concerned.

I was reviewing some code written by one of my senior engineers. It was late in the day. I didn’t read the code properly or I missed something because it was late and I felt that it wasn’t up to the standard I’d expect from a senior engineer (and this engineer in particular). I added my comments about why I thought the code was wrong and left a comment asking what had happened as the code was a bit of a “dog’s dinner”. Despite it being late, the engineer looked at the review that evening. He was hurt by the comments and was still hurting the next morning, when we went through the code together. To make things worse, I was wrong. I’d misunderstood. Not only had I gone off half-cocked, I hadn’t created a safe space for the feedback. Of course I apologised, and although it is mostly brought up in jest now, the engineer still remembers that I called his code a “dog's dinner”.

Even if I hadn’t been wrong, I handled it badly. I did what Carnegie describes as “A sure way of making enemies”. I contravened his second principal of Winning People to Your Way of Thinking: 

“Show respect for the other person’s opinion. Never say, ‘You’re wrong.’” 

Telling them they’re wrong will seldom bring someone around to your way of thinking, as few people are comfortable to lose face.

Before you disagree, ensure you have all the necessary and available information. Then consider allowing the other person to speak first. As we’ll see next, and in the example with The Head of Engineering later on, it may be that the other person has some additional information or has changed their mind and the disagreement may no longer be necessary.

Create a Safe Space

In his book, Non Violent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships, which was recommended to me by my boss (read into that what you will), Marshall Rosenberg explains that non violent communication is:

“...getting people to exchange words in a way which excludes judgement, blame and violence.”

Other than stories I’ve heard about some members of a team I worked with at an investment bank, I’m not aware of physical violence happening in software engineering teams. The violence that Rosenberg is referring to is verbal violence. We, especially as team leads, must be mindful of how we speak to people. Even when things have not worked out as they should. It is important not to judge, blame or allow any frustration you may be feeling to affect the conversation - remember to always count to ten. 

A team planned to make changes to a component they owned, which is used by an application my team maintain They had asked us to update our application to accommodate the changes. During our initial discussion, the update seemed straightforward, but I requested that they provide a written set of requirements to clarify what needed to be done.

When the requirement came it consisted of a couple sentences. It was sufficient to get across what was needed, but lacked some of the context and other detail one of my team’s tickets would include. Although I wasn’t accountable for the ticket, I could see that there was room for improvement.  Instead of pushing back, I asked the engineer if they were interested in looking into ways they might improve their requirements. I created a safe space where they could take me up on the offer if they wanted to.

They told me they were always open to new ideas, so I sent them our ticket templates and recommended a book that they could learn more from. They thanked me and went away happy. 

Always create a safe environment where it is possible for everyone to finish the disagreement feeling positive.

Let the Other Person Start

If I need to have a conversation with someone after something has gone wrong, such as a feature taking too long to build and deploy, a bug making it into production, or them acting out of character or in an unacceptable way, I try to keep things simple. I let them know what I want to talk about, but with as little detail as possible, and ask them to explain what happened from their point of view. I might not have all the facts, or I might feel differently once I’ve heard their side. They may already be feeling bad, acknowledge the mistake, and want to get it out in the open. Letting them begin the conversation helps avoid blame and judgment, and sometimes it turns out not to be a disagreement at all.

In every situation I can think of where something has gone wrong, the engineers responsible were doing what they thought was best and acting with good intentions. The only exceptions I’ve heard about are a few exit stories, including one where a disgruntled engineer filled their organisation's version control system with pictures of Ainsley Harriott. That kind of behaviour calls for an entirely different kind of conversation.

Admit When You’re Wrong

Sometimes you’ll be wrong. I am all the time. Carnegie suggests starting disagreements with:

“I may be wrong, I frequently am. Let’s examine the facts.”

Because “no one objects to that” and it allows for when you are wrong. Did I mention I often am?

There are lots of ways in which you might be wrong. Sometimes, while explaining something, you gain new insights yourself - a phenomenon known as rubber ducking - and sometimes, the person you're discussing it with might even offer a better idea. You need to be ready for when you might be wrong, know how to handle it and not just brazen it out (continuing confidently despite being in the wrong).

Broadly speaking there are three things you can do when you discover you’re wrong:

• Brazen it out and make the engineer do it your way anyway
• Let it slide, but let the engineer do the right thing
• Admit you’re wrong and then the engineer does the right thing

When you’re wrong, don’t just let it slide, admit you’re wrong and ensure the engineer does what you both decide is the right thing. Admitting you’re wrong demonstrates your vulnerability in a powerful and constructive way and your engineers will respect you more for it.

When you know you have to admit that you’re wrong, and you know that the other person is going to be unhappy about it, Carnegie has the following advice:

 “If you know you’re going to be rebuked anyway, isn't it far better to beat the other person to it and do it ourselves? Isn’t it much better to listen to self-criticism than bear condemnation from another person?”

A Head of Engineering I worked with once, and who was senior to me, handled a tough situation perfectly and adeptly. I’d been asked to build a service for a number of other teams to use. I built most of it and then hit a blocker that stopped me from getting any further. After talking to various people to try and get unblocked, I discovered there had been a miscommunication on the Head of Engineering’s part, and the service wasn’t needed after all.

I’d put a lot of time into it and was really looking forward to seeing it used. I get a massive kick out of seeing the things I build in action and adding value. I was very annoyed, to say the least. I set up a meeting with the Head of Engineering, and my boss, mainly to vent and explain how frustrated I was.

But as soon as the meeting started, and before I could say anything, the Head of Engineering immediately apologised. He took full responsibility, admitted it was his mistake, and said he completely understood how and why I felt the way I did.

It completely disarmed me. His honesty and ownership diffused the situation instantly. We talked it through, both got what we needed from the conversation, and moved on without any lingering tension.

When you’re wrong, admit it. Never just let it slide.

If You Can’t Agree In The End

As a team lead, you should be able to explain your point of view clearly and, in many cases, with enough technical detail and reasoning to convince your engineers. 

But what if you can’t reach an agreement with your engineers? It’s important to remember: your engineers are responsible for doing the work, but you’re accountable for it. And in my view, that accountability gives you a meaningful say in how the work is done. You don’t want to end up in a situation where an engineer goes against your guidance, a bug makes it to production, and you’re the one explaining to stakeholders why it happened. You’re also the one responsible for getting it fixed and dealing with any fallout. Even if the engineer ultimately resolves the issue, the accountability still sits with you. 

You should always avoid saying “...do it because I said so.” It risks undermining your engineers’ respect for you and eroding their sense of ownership and importance. However, as fellow team lead Alex Leslie once reminded me, there are times when the stakeholders in your organisation dictate that something must be done a specific way, and in those cases, your role is to pass that on.

If the disagreement is of a non-trivial nature then it may be appropriate and beneficial to bring in another party to help mediate. If agreement cannot be reached, it is likely that there are strong arguments on both sides and another person, such as another engineer, another team lead or even your boss, may be able to reach agreement. 

In the chapter Leadership style: The Perception of Things of Leadership and The One Minute Manager, Ken Blanchard uses a conversation to explain what he thinks should happen in this situation:

“If there’s a difference of opinion and you can’t decide, who decides?”

“The One Minute Manager decides.” 

The team lead is still accountable in this situation and I am inclined to agree. If agreement cannot be reached, the team lead should decide what to do.  However, my friend, colleague and fellow team lead, Will Johnston gave me a valuable counterbalance to my view:

In software engineering, there are countless ways to solve a problem or implement new functionality. While a team lead can provide direction and offer advice on how to approach a task, I believe the engineer should have autonomy over the specific implementation.

When reviewing code, I might not always agree with the chosen solution. However, if the approach is performant, easy to understand, aligns with the repository’s standards, and adheres to the organization’s methodologies, then I see no issue with it.

In these cases, providing feedback as anything more than a suggestion can be counterproductive. It risks undermining the engineer’s confidence and can give the impression that changes are being made for the sake of it. Worse still, it might suggest the lead is unnecessarily asserting authority, which brings little to no value.

Ideally, it should never come to the point where an engineer is forced to make a change against their judgment. If it does, this can signal a breakdown in trust and may lead the engineer to question the lead's confidence in their abilities or even their own.

As a team lead, I believe accountability means being prepared to make the final call when a disagreement can’t be resolved without defaulting to authority, but owning the outcome when it matters. However, if an engineer’s solution is solid and aligns with standards, it should stand, even if the lead disagrees. Preserving trust and autonomy can outweigh enforcing preference. Good leadership needs balance between guiding with responsibility and stepping back with respect. As my friend and colleague, Akshata Rao says:

“A team that grows along these lines, where engineers have some autonomy and arrive at a common understanding of acceptable code, eventually reaches a values based alignment, where disagreements naturally reduce over time. Early-stage disagreements help the team build toward more efficient communication in later stages.”

Do what is right for both your accountability and your engineer’s responsibility.

Finally

Disagreement is part of software engineering. Intelligent, opinionated people tackling tough problems will naturally see things differently. There’s rarely one “right” solution, and what’s considered best practice is often shaped by experience, opinion, or trend. That ambiguity, combined with a culture of flat hierarchies and open discussion, means differing views are inevitable and valuable. Disagreements can be frustrating, especially as a team lead, but they’re also a sign of engagement, care, and healthy competition. If everyone agrees all the time, something is wrong in the team.

"When a manager and a team member agree on everything, one of them is unnecessary."

Ken Blanchard 

Software engineers disagree about almost everything, from how code should be styled to which libraries to use, how long something should take, or even what colour a button should be. It’s the complexity of software, the ease of change, and the fluidity of requirements that allow for much of the friction. Disagreements are inevitable in this environment, but not all of them are worth having.

Before jumping into a disagreement, it’s worth pausing to ask: does it matter, is it mine, and is now the right time? Through personal experience, I’ve learned that many disagreements arise from ego, misjudged accountability, or bad timing. However, it is possible to avoid needless disagreements and instead influence more effectively, with empathy and purpose.

If you’ve thought it through and a disagreement really is worth having, it’s vital to approach it constructively. That means creating a safe space free of judgement, blame or ego. And if agreement still can’t be reached, remember that while collaboration is key, as team lead you remain accountable. That doesn’t mean using authority to shut things down, but it does mean sometimes you’ll need to make the final call.

As a team lead, your response to disagreement sets the tone for team culture. You don’t have to be right to lead well, you just have to be open, intentional, and accountable.
Bibliography

Bibliography

So you think you can lead a team?: The Reading List 

Thanks

There’s a lot of people to thank for this one! People have been very giving of their time with reviews, stories and helping with research into how teams disagree both inside and outside of software engineering. I couldn’t write this without you!

Emma Andrews
Sam Berrington
Laurent Douchy 
Harvey Gwynn 
John Hegarty
Will Johnston
Simon Lee
Shannon Lee
Alex Leslie
Jim Marshall
Molly Marshall
Jon Moore
Gail Ollis
Sam Pennington
Akshata Rao
David Robertson
Arunas Silanskas 
Timothy Straughan 
Janet Wallace
Lee Wiseman

 

I had to cut down the “Pick Your Disagreements” chapter for my book - reviewers all felt it was too dense. That left me with some extra content, portions of which I’ve shared here.