Learning by Shipping

In the course of figuring out what to do on a project (plan, code, collaborate, marketing, …) inevitably you will get to a point where two parties (two people, two teams, two disciplines) don’t agree.  Figuring out how to move forward is not only essential, but is something that can make or break a team or project.

Focusing a discussion on disagreement in the abstract is a good way to approach this, rather than using specific examples. This allows the dynamics to be discussed here without the distractions of picking sides.  When it comes to disagreements, even the specifics are usually much less important than the overall context in which the disagreement is taking place.  More often than not, a focus on specifics tends to hide what is really the root of a disagreement.

This post was suggested by a reader as a topic worth discussing.  Suggestions are welcome and I’m always on the lookout for comments and tweets with suggestions or email me at steven@learningbyshipping.com, perhaps with something going on at your organization right now that is a generally interesting topic (specifics always removed).

Organization

Organization plays a key role in the context of building consensus (more on organization in a follow up post).  Is your team managed step by step through a hierarchy, deferring to the management chain?  Is your team one where the most senior manager gets involved in many choices?  Is your team dominated by a strong de facto leader that leads from within the team?  Is your team a small group of peers that seem to usually agree on everything?  Is your team subject to swoop and poop from outside, bringing disagreement to you?  There are quite a few ways that disagreements can surface and/or get resolved and those are a few.

The first step in working through disagreement is to know how your team is structured to make choices, which might be different than the org chart.  You want to know not just how you want to decide things, but how do others in all 360 degrees expect to resolve things.

The 360 degree view has been something I have often worked through (and certainly not perfectly).  In a team with a plan and a strong organization, it is the organization working with a decision framework, the plan, that decides.  Those new to the team or even those on other teams often see a team operating this way and assume a hierarchical or top down model—otherwise how could things appear to work and stay on track with a large project.

In practice what that means is that there is a mismatch in how to handle disagreement.  Some assume that you have to go to the top and “get things changed”, while folks at the top are saying “did you talk to the people doing the work.”  This type of cultural mismatch is the first thing to overcome.  On a team of empowered creative folks, they have gone to great lengths to say what they will be doing and how they will decide what is yet to be discovered.  That’s always been enough for me.

Roles and responsibilities in an organization, not hierarchy, are also important.  Are disagreements between people within the same discipline or across disciplines?  Often agreements can be settled by recognition of where the responsibility rests.  For example, in projects with user interface many people can have opinions about the UI but the team should be operating with acknowledgement that the accountability rests with the discipline (design, program management) that is doing the work to design the UI.  Having a clear view of how specialties work in the organization is an important part of knowing how disagreements will be resolved.

Organization can cause disagreement to flourish in two main ways.  First, management can structure things such that goals and/or accountability are unclear.  This means things need to be integrated or reconciled “up” where there is always less information/data, thus driving meetings, debate, and campaigning for decisions.  Second, members of the team can fail to defer to the empowerment and decision making structure in place (plans, disciplines, accountability). This is a case where disagreement exists when individuals on the team could take time to step back and let the organization do the work.

These organizational elements are an important part of the context around disagreements.

Context

What is it that makes disagreement so pervasive and so difficult to work through?  Are there really so many arguments to be had while building a product or service once you decide what can and should be built?

I’ve always been fascinated by the dynamic of how something turns into a big decision to be made.  For me, work is progressing and sometimes things come up that are hard or unforeseen.  Then all of a sudden there is a crisis and something needs to be decided and that decision has expanded to involve a lot of people.

Knowing the context is always the most important first step.  The following are some examples of reasons or context behind disagreement:

Decision or an argument.  A first consideration is if there is truly a decision to be made or what is really going on is an argument.  What this means is to ask if someone questioning your general approach or is this a real challenge to the choices you are making.  It is only to your advantage to engage with members of the team who might have a different point of view.  You don’t have to accept it or escalate into a fight, but it is always good for everyone on the project to be heard.

Naysayers.  Sometimes a decision gets created that is not really all that important, but is being used to drive a wedge for any variety of reasons.  Often these look like “let’s take a step back and ask the following question.”  So you thought you were having a discussion about a schedule estimate and the next thing you know you are in the weeds debating agile v. waterfall.  You have to ask yourself if the real issue is the meta-issue, a lack of faith in everything going on, or if you really have something that is the source of a disagreement.

First of many.  There are times when points of difference get raised in a “death by 1000 cuts” sort of way.  In other words you might find yourself disagreeing over a specific topic but as you’re talking (constructively) it becomes clear that this is going to be the first of at least a few disagreements.  Folks might use this approach to test the waters or to probe for a weakness overall.  An approach here is to work to smoke out all the disagreements so you can have a discussion with the full context.

Symbolic or material.  Sometimes a disagreement is really an effort to raise a more symbolic disagreement with the broader context of the project.  Helping to work through and discuss how material a given disagreement is to the whole project is especially important here.  In this context, a disagreement can turn into a broader view of two parties not connecting.

Accountability.  Ultimately disagreement needs to factor in accountability.  If the first step of a disagreement is “who gets to decide” it is likely the answer will itself become a disagreement.  Almost all disagreements I have been part of scream out the person who should be deciding.  If it doesn’t the question is really more about accountability—not who should make a specific choice, but who is accountable for a broader set of issues.  Is that person not doing a great job incorporating lots of viewpoints and information?  Did that person not enroll everyone in a broader framework?

Context is everything.  In the heat of a disagreement people, especially for engineers who tend to distill things into concrete facts or algorithms, will often get very focused on the details of winning the argument.  It is a good idea to understand the context of the disagreement before trying to win on the merits.

What can go wrong?

As you’re working through a disagreement, there might be a few patterns you run across that are used to resolve the disagreement—patterns that might not be the most productive.

The key thing is to keep the dialog focused on the context of a choice.  In a sense, what I think everyone knows is that any disagreement free of context can have a different outcome than if considered in the context.  A classic is “add this feature.”  Absent the context of schedule, resources, and most importantly the holistic view of a plan/product, almost any feature sounds like a good one to add or any change seems reasonable.  The flip side is that just about everyone sounds like an idiot arguing against security, performance, quality absent the context that an engineer might have.  No one sounds smart arguing against a revenue opportunity, until you consider the cost, alternatives, and so on.

There are patterns that are bad ways to resolve disagreement because the technique removes the context:

Single choice.  Sometimes when there is a disagreement, something that seemed small starts to take on a life of its own.  You come to a meeting and you’re all of a sudden having a debate over the color of tooltips in a toolbar (true story) when that is not really the disagreement as all.  What has happened is a disagreement over a broad set of issues has morphed into what appears to be a single choice.  The context was lost and a complex, multi-dimensional problem space has been replaced by one, seemingly, trivial option.

Escalation.  Sometimes disagreements get created as a way to get in front of the boss or as a way to encourage the boss to get in front of the other party.  This type of disagreement is never good and my first reaction is to pull back and “de-escalate” like cops do on reality shows.  Something I have always tried to practice is the notion that to escalate is to fail. But the real challenge with escalating a disagreement is that the context and knowledge about a situation is reduced as you move up the management chain, so escalation is really a way of saying “decide with less information.”  There are subtleties and nuance to this (for example if you haven’t done your work to incorporate the context from outside your specialty in creating a plan).  New information can change things and the question is whether you are being too heads down to incorporate new information. The key is that once you escalate you lose the context of the choice.  Similarly, to pull a decision up (the organization) creates the same dynamic of deciding with less information than might be available.

Decision maker.  One way to remove the context from a disagreement is to introduce a debate over who gets to decide, as mentioned above.  I’ve been part of all sorts of “tools” that are supposed to help you decide—tables of who reviews choices, approves things, or “responsibility assignment matrices.”  As well-intentioned as these are they don’t really scale and they encourage all choices to get broken out into elaborate decision-making processes.   At some point you can rationally ask how to even decide what decisions go through a process like this or is this an attempt to circumvent accountability or an attempt to game the system.

Accountability shift. Accountability gets to the heart of most disagreements.  Those disagreeing feel on the hook, accountable, for some outcome and the choice being discussed impacts the potential for achieving the assigned goal. By shifting the dialog from the disagreement to accountability, things get emotional very quickly.  The discussion turns into talk of “failure” which is a lot to place on the shoulder of a single choice in a complex product.

Tools and approaches

In practice the tools to reconcile disagreements are rather personal—they rely on the skills, tone, and temperament of the individuals.  Most everyone can lose their temper or go silent (essentially the same thing).  Most everyone has sent a late night mail they regret (subject line, “thoughts”).  Most everyone has behaved the way they criticized someone for behaving.  I’m there with you and don’t have magic answers to resolving disagreements.  Here are a few tools I have used:

Expertise.  Where is the most expertise?  As a general rule, too often decisions are made in meetings where people are presenting cases and someone is in the middle trying to referee or decide.  At that moment, a decision is being made by a committee or by a group, yet the people that have the expertise might not even be in the room.  As a general practice, pushing decisions to those that know the most yields better decisions.  Many times teams convince themselves that there are implications that go beyond the expertise (“yes this might be a security problem but the business has different issues”).  The best thing then is to figure out how this type of context is not making it to the domain experts—what was missing from the day to day flow of information that got a team in a situation to begin with?

Plan.  Most disagreements are essentially disagreements with a broader view—at the highest level or at the level of what a feature or marketing message should accomplish at the core.  In other words, while the discussion might be about a specific, it is a disagreement about a broader theme.  I return back to the plan (the one you got buy-in about because you talked about it broadly).  I try to understand what has changed or what have we learned since the plan.  Plans are dynamic of course.  But one needs to be careful about changing direction without a real change in the business or product landscape.  If you do change plans, you need to think hard about the relationship of one change to the big picture.

Culture.  The best tool for resolving disagreements is one you have to put in place upstream, which is a culture that allows and respects the decisions being made by the right people.  Developers might not like the advertising, but marketing people decide that.  Marketing might not like the wording of a license, but that’s a decision for lawyers to make.  But because a team should be operating with a shared view of customers, the decisions should be ones made outside of silos of expertise or narrow views of success.  There’s definitely magic in there and in a big project achieving this uniformly is extremely difficult, at best. The tool everyone should ask for in a culture is a management chain that supports the culture.  It isn’t about being “backed” in a decision but about being consistent in the notion of delegation and accountability.

Accountability.  Related to culture is the notion of accountability.  Rather than saying “test is accountable for quality” the tool is really for management to reinforce that everyone is ultimately responsible for the overall result.  If something is successful you can bet that everyone on the team will feel they contributed to the success.  There’s nothing stopping the team from acting that way while the product is under development.

When to say when.  Finally, the best tool any individual can have in the course of a disagreement is knowing when to say when.  Projects are marathons (no matter how long a particular coding sprint might be).  If you choose to turn every decision into the most important and biggest one, you’ll run out of reserves long before the finish line.

One final consideration is if you agree to disagree then you have to mean it.  It means you can’t remind folks at every opportunity that you saw things differently.  It also means you’re tabling the disagreement for good and that you’re not inadvertently establishing a dreaded accountability dodge or told you so for later on.

There are innumerable decisions in any project—each person, then each team, then teams, and more each make choices dozens of times a day.  Every line of code, every word in a spec, every automated test, every part of a plan, every data sheet, PR script, and more are decisions.

People tend to forget this in the heat of the moment.  Time heals, and forgets, most every small decision in a project.  In fact, I would bet that any disagreement you are dealing with at this moment will be a distant memory and chances of it determining success and failure of your project are small when viewed in the context of all the work, and decisions, yet to be done.  Om.

–Steven

Reminder – please see the recently added disclosure page.

###