Conflict Resolution

Recently, my friend shared this story over dinner. He is an iOS developer.

He had been tasked to create a core component for his company’s design system: a container view that sweeps over other views. But there was an issue with how padding was applied. The designer in charge of the component insisted there should be a fixed padding set for content. Most developers who used the component wanted to define custom padding. He was getting lots of requests by others in the company saying their designs can’t be achieved with the new container’s implementation.

Those who worked with me on frontend projects know, bad margins and padding really drives me crazy. They seem to be the trickiest thing for large companies.

My friend goes back to the design partner to change the requirements for the padding. “Let’s set it to zero and let people put things inside a layout view”. The designer explains, “design system needs to be opinionated; all views inside the container need to have the same padding set for consistency”. The tennis match was one of stamina. Conveying how practical usage is suffering didn’t really matter. My friend got tired and gave up after running around the court.

Conflicts like this happen all the time. Perhaps, it would help to think through a framework that helps both parties arrive at shared understanding and agreement.

—

Eliyahu Goldratt, in the book It’s Not LUCK, guides conflict resolution towards finding common objective. Each action in conflict is motivated by a requirement, which in turn, is motivated by an objective. If we can work back to find the common objective in a conflict, we have the opportunity to inspect underlaying assumptions and work towards resolving the conflict.

So in our story, we have…

Developer: [A. Leveraging the design system to unlock consistency]← [B. Flexible system that matches feature designs] ← [D. Remove default padding]

Designer: [A. Leveraging the design system to unlock consistency] ← [C. Consistent component behaviour through fixed values] ← [D’. Apply default padding]

My favourite thing about this framework is its invitation to show empathy. It forces us to inspect motivations on both sides. Conflicts are part of working as a diverse group of individuals. Being able to understand differences and learning to view problems from many lenses helps teams do amazing things.

—

Let’s take another piece of wisdom from (the super awesome book) Crucial Conversations by Kerry Patterson to help us.

Often, a conflict exist because each party doesn’t have the full picture. Much like a Venn diagram with two partially overlapping circles, each party has unique knowledge with some shared understanding between the two. We should approach conversations with a level of curiosity to close the gap on shared understanding (bring those circles closer together). What do you know that they don’t? More importantly, what do they know?

Going into a debate thinking you want to “win it” yields no favourable outcomes; only annoyed people having formed a poor opinion of you.

Again, this is sounding a lot like empathy.

—

A. Leveraging the design system to unlock consistency

Going back to our conflict, I played the designer and debated with my friend. We both asked “why” a whole bunch and tried to explain the differences of theoretical and practical issues.

This is where we arrived (if you care for technical details)…

Some containers describe layout patterns while others define interaction patterns. For example, a Card is a way to lay content out. A Dialog or a Split View may be more of an interaction pattern. Perhaps, we need to have an a rule in the design system on how to approach these two types of components. It make sense for layout views to pad content. How about interaction patterns? Perhaps the rule is to pair interaction components with a layout.

This seemed like a path forward to figuring out how to resolve the conflict.

—

Conflict resolution is all about empathy. Empathy builds great teamwork, which builds great products.

Do "basics" well

High performing teams are about interperson chemistry that is built on a foundation of the “basics”.

Take sports for example.

Learning to play a sport require you to learn the rules and develop basic skills to play. For soccer, it would be passing, tackling, lobbing and shooting.

When you join a team, there’s drills, runs and short set plays. These are repeated over and over during practice. During a full game, these disconnected pieces mix together to form fluid play. Play together with your team for long enough and magic starts to happen — team members anticipate each others moves to outplay opposition.

Drills, runs and set plays allow you to improve and build on the basic skills: passing, tackling, lobbing and shooting. They improve player fitness and execution during gameplay.

The act of continually working on the basics seem to lead to continued advancement. This is an interesting idea as it would be easy to assume the opposite — to advance further, one has to work on increasingly complex drills. I think it comes down to the fact that most complex things are built up from very basic elements. The more confident and efficient we are with basics, the more opportunity we have to put them together to do complex things.

Therefore, I believe, basics and chemistry form important attributes for any team.

Chemistry can be a complex thing to establish, with time, environment and the individuals themselves. It’s a whole other discussion.

It is easy to establish basics when talking about soccer. What are the basics outside the context of sports? I’ve been trying to figure out what forms the basics for a software engineering team. Is it design patterns or code reviews? Is it practicing readiness to production issues? Or perhaps, it is our ability to document and capture tasks in Trello? These seem to be the essential building blocks in a life of an engineer; solving problems by applying technical concepts into code, that outputs a product to deliver value.

Software is more than just code. At the heart of it, it is empathy and collaboration. It is a bunch of people, observing and acknowledging pain felt by themselves or others, deciding to take upon themselves to resolve that pain. Solutions doesn’t just come from one individual. It is the work of many, fusing their minds, disciplines and skills together to make something truly valuable. For me, the basics for a team are contained in these core values.

Basics has to be more around the idea of problem solving. That is all we do as a team, every day. Even our individual disciplines themselves are various ways dimensions of problem solving — research, design, engineering, analysis etc.

This idea became clearer when I recently read the book “The Culture Code” by Daniel Coyle. The book investigates the elements of highly successful groups. There is a great case study around Danny Meyer’s wildly successful restaurants. In a restaurant, how should one go about preparing staff for both conveying the right feel to customers and be able to react to new and complex issues that come up? It is impossible to cover all the bases and situations.

Danny uses the idea of “heuristics”. He captures the behaviours and his ideology in short, catchy phrases that are used in high frequency. Staff learn to apply these heuristics in every day complex situations, leading to very delightful customer experiences. Applying these heuristics seem to be the basics Danny get his staff to focus on.

These “heuristics” aren’t the same as rules. They are shortcuts for understanding and applying “guiding principles”. They convey a behaviour that is core to situations that arise in a restaurant environment. They allow staff to be thoughtful and creative, while being aligned towards providing customers with a unique, delightful experience.

Heuristics based in problem solving… these can be our basics.

Here are some ideas for heuristics I’ve been collecting with the help of others:

• Just start.
• Try and try again.
• Optimise for fast recovery.
• Act like it is your company.
• Coaching over management.
• Challenge assumptions.
• Understanding the problem is half the solution.
• Ask why.

“Just start” — we can apply this heuristic over and over in many occasions, whether people are stuck on a decision or unsure of estimates. It embraces the culture of a “maker” in having a bias for action.

Whenever someone asks me why we allowed a bug to go to production, I like to say: “Making mistakes is part of the job. We’d be better off if our system was optimised for fast recovery instead.”

We do workshops to help everyone understand how to write a good problem statement. Because “understanding the problem is half the solution.”

I believe that practicing these basics of problem solving can lead to powerful teams. They can provide the fundamentals that enable magic to take place.

Keep practising. Keep doing basics well.