For Better Handoffs and Team Cohesion

Better Handoffs, Science, and a Detective Show

Let’s explore common pain points in team collaboration and how we can improve our own habits through empathy and scientific method.

I propose: empathy and scientific method are not just useful, they are the right thing to do to help us be more intentional and more accountable in our shared creative works.

Also: taking cues from Columbo. Yes, the 1970s TV show. More on that later.

Let’s begin our exploration with a question: what happens when we handoff something in a creative process?

Collaborative Handoffs

Relay races, factories, and business teams have something in common. Work is assumed to be progressing if we observe something moved from one stage to the next - that movement is often a Handoff.

Where do handoffs happen?

• Role/skill specialties lead to handoffs.

• Accountability-shifting decisions lead to handoffs.

What do I mean by handoffs?

Universally: a handoff is a commitment to share something that is being expected by someone else. As individuals we may have an affinity or interest in some steps or parts of a problem and not others.

Some of us are more inclined to planning vs. making or troubleshooting vs. strategizing. That’s helpful for forming groups of people with the collective skills to take-on a shared mission. Teams allows us to solve more complex problems.

Handoffs happen at stages of creative progression.

Handoffs are where one discipline connects with another to collaboratively work in serial or parallel. Handoffs are possible at stages of creative progression and at discipline boundaries. Handoffs are decisive moments.

Name an industry and you’ll likely see some amount of role specialization and some need for different specialties to work together on products and services.

Regardless of the specialty or industry, roles and handoffs are everywhere.

In creative media industries such as in comics we can see specialized roles:

• Writer

• Penciler

• Inker

• Colorist

• Letterer

• Editor

In making digital products we have a variety of specialized roles:

• Sponsor

• Product Manager

• Backend Development Roles

• Frontend Development Roles

• Visual Design

• Experience Design

• Devops

• And many others - digital products is a space of many spaces within with different ways of interpreting the idea of making digital products.

I like to frame handoffs as decisive moments. Decisive moments happen as choosing paths among options both during handoffs and even before work needs to be handed from one role to the next. Decisive moments are a great place to be informed by one another’s roles.

Decisions via Compromises and Constraints

You’ve likely encountered and needed to use compromises in projects where constraints would have been more beneficial.

Constraints help guide the key choices that make a product or system into something that people find useful, useable, and maybe even delightful to use.

Compromise frequents projects where you find either a lack of empathy among collaborators or when the collaboration is being driven as a negotiation instead of a shared purpose.

A constraint is a useful creative limitation or reality. When you discover, understand, and embrace a constraint, it helps focus your creative problem solving and helps the team produce better designed solutions.

Whereas compromise also grows from misunderstandings and miscommunication, such as not understanding one another’s roles.

How do we relate better to one another’s roles? Framing intent is a good place to start. Ask: What’s driving you in your role? What are goals and principles informing what you’re offering?

Why are we doing what are we doing? These questions are a good place to begin to understand why others are doing what they do in their roles.

It’s easy to rationalize why a project isn’t going well.

It’s also easy to see things differently and disagree as a result.

Different roles value different things: their specialized methods, tools, and language can define, help, and distinguish their role.

Producing collaboratively with all these differences in roles is a sort of model UN exercise. Each of us promoting our values and attempting to share artifacts across our role cultures.

The risk of this much role-centric effort: it leads to an isolated definition of success instead of holistic which leads to compromises instead of constraints.

Collaboration across roles helps us identify constraints.

Applied Discipline

Being role centric means to advance knowledge within a given domain of study VS emphasizing a shared intentional outcome or goal. Much like the contrast between pure research and applied research.

PURE RESEARCH - expanding knowledge within a specific domain and therein lies the definition of success.

APPLIED RESEARCH - which may use the same knowledge but mash it up with a goal or need which dictates success through external measures such as audience size, profit, or learning in order to achieve those external measures.

In the APPLIED discipline realm, we’re shipping things and learning from what we ship.

To do this across and with our various roles and disciplines it takes curiosity, empathy, and investigative habits.

Enter Columbo

Which one of these doodles represents Columbo? Do you recall some of the things Columbo does? He’s a detective character, played by Peter Faulk in a long running murder mystery television series in the 1970’s - 2000’s.

As a detective he often showed his investigative habits and immense skill for interviewing. He pursues his goal to solve the crime with relentless dedication. He is not a Terminator character with a goal, Columbo doesn’t pursue a mission unquestioningly. Nor is he a Dirty Harry character with a goal, he doesn’t perform his role with extreme aggressive judgment.

Columbo started the "howcatchem" twist on the whodunit formula.

If you’ve not had the pleasure and a quick review for those who have, here’s a synopsis of the Columbo plot structure:

We don’t see Columbo in the first act. We see the perpetrator and their normal life until they choose to commit the crime.

Then we see detective Columbo, often having a seemingly absent-minded professor moment as he begins the investigation.

The stakes get higher and higher as Columbo explores the situation and the perpetrator feels they’re doing a good job fooling the annoying inspector.

Until finally we get our "one more thing" moment, where Columbo looks like he’s about to “not” capture the suspect in a net of logic and evidence. But he does! And once again Columbo prevails and we get to learn the howcatchem result.

Two significant factors in his success: his approachable demeanor as he’s interviewing suspects and he’s incredibly observant.

Relating to Columbo

What does that have to with collaborative creative projects? Traits that define the character of Columbo also outline good collaborative habits:

• ask questions, test ideas

• be very curious about the people and world around you

• be observant and find evidence

• have an approachable manner, show empathy

• gathering evidence is a good way to build confidence in a direction

How would Columbo examine a handoff? I think he’d ask if this going well, then explore why. Also, if the effort is going poorly he’d ask why, gather observations, then explore them to see what holds up.

Listen, ask questions, and listen some more.

Don’t stop talking with people across all the roles.

Let me state that again. Don’t stop talking with people across all the roles.

Integrate what you’re gathering. Share it and see if others relate to what you’re investigating and how they relate to your findings.

Just like Columbo you’ll be gathering, testing, and combining evidence of what’s working and what’s not working. It’s a sort of superpower to work across any role.

Watch Columbo work. He’s so collaborative-compatible as he interviews he’s so approachable, everyone answers in one way or another. He’s right there listening and observing.

Whether you are a troubleshooter, investigator, designer, analyst, or software engineer, researcher, in any collaborative effort role:

IF YOU HAVE EMPATHY, ASK QUESTIONS, STAY CURIOUS, AND STRIVE FOR EVIDENCE YOU WILL HAVE BETTER HANDOFFS!

However… Being human is a complicated business.

Gathering evidence is hard. Withholding judgment is hard. Why do they remain difficult even after we know they’re useful and are ready to try?

Even though we all perform some discipline or use processes we’ve studied and practiced: no methods or logical thought can stop our emotional side from influencing us.

Because: we all have biases and commit logical fallacies.

Cognitive Biases and Logical Fallacies

Cognitive biases can lead to perceptual distortion, inaccurate judgment, or illogical interpretation and logical fallacies result as an error in terms of reasoning.

We aren’t only filtering with biases and committing logical fallacies as we go about our day to day. These mistaken beliefs can mix with our habits and disciplines. Some examples follow.

The Dunning–Kruger effect is a cognitive bias - that puts us in the situation of: how do you know the extent of your skill when you don’t yet have enough skill to accurately understand your skill.

When the Dunning-Kruger research was being performed, it was also nick-named "American Idol Syndrome" where someone doesn’t have an accurate understanding of their own skill because they don’t have the skill to understand AND likely don’t have critical feedback.

That’s illusory superiority.

The opposite is also true. Another Dunning-Kruger effect is when someone who is highly skilled rates their ability as far lower than they should.

Sunk cost fallacy is also known as loss aversion. A classic example: if someone buys a non-refundable ticket to an event, many would use it even if something better comes along that they’d prefer attend.

On projects I consider the Sunk Cost Fallacy when I hear the argument: "but we made it this far… or spent this much of the budget already" as the main reason for continuing. That’s when I like to explore with the team to find more evidence and discuss what we discover to hopefully break out of the fallacy.

Empathy and Role Biases

Through experience and some self awareness I know I can be biased for and against other roles in making projects.

Do you look suspiciously at any role or work products from any role in particular?

For myself: I look askance at planning-focused roles vs. make-focused roles.

I’d love to be perfectly objective - at least that sounds like it’d be a useful superpower. What I try to live up to and advocate for is to discover our biases to be able to better manage them.

Empathy helps.

How can we improve our empathy?

We can borrow useful tools from the User Experience discipline to amplify our empathy for a given role or collaborator.

One tool in particular I find of use is the empathy map diagram. It’s a mental exercise that may not give you all the answers about someone’s perspective but it does give you a bunch of ideas to help move the conversation forward.

How do you make an empathy map? You need to make four lists. I like to start with the two lists that are observable as an outsider: what is the person you’re observing saying and what are they doing. From there, I can attempt informed guesses as to what they may be thinking and feeling.

Through this, you can capture questions that attempt to relate and understand their particular role.

For example, if conversing with someone in a visual design role with empathy is discussing a recommended change with someone in an engineer role with empathy:

Engineer Collaborator: *"I saw your feedback on the latest release - how strong of a concern are you expressing and are you recommending we delay this release?" *

Visual Design Collaborator: "I just learned we’re getting complaints and usage stats that show the call to action page is getting too many abandons. We need to redesign and implement a fix as soon as possible."

Engineer Collaborator: "I’m open to that - though I do want to understand the trade-offs and risks in how that may delay us vs. we ship on time and get it next iteration".

If you’re a fan of usability, pleasing design, and utility in the things we make, you’re already a fan of having empathy for one another.

We’re all end users for one another’s skills as we’re building stuff together.

Be Informed by More Than Biases

Seeking to improve upon your biases is a good place to start. It’s no easy task, but it can be fairly straight forward.

It’s a habit we’ve seen in both scientific method and art.

Critique.

Critique is how we can acquire some of Columbo’s super skills.

By critiquing our own arguments we can explore biases and fallacies Through that… YOU WILL PROVIDE AND HELP OTHERS PROVIDE BETTER AND MORE INCLUSIVE RATIONALE. This unlocks something even better than being an individual Columbo… your group will be FUNCTIONING AS A TEAM vs a COLLECTION of DISCIPLINES.

It’s true we all need practice with critique and to get used to providing feedback within your team. Do it often, until it feels comfortable. Critique is a critical skill we all need to learn how to give and receive. I will provide more specifics on good critique soon. Before that, let’s consider how teams help our collaborative habits.

Teams Help with Critique

Teams are critical to forming and supporting these habits. We are social creatures. Our roles don’t stand alone. Even Columbo doesn’t work alone.

Teams help with practicing.

You and your team practice and share skills, cultures, and tools.

Skills combined with tools and culture lead to advocacy across roles: code advocacy, design advocacy, business knowledge sharing, all kinds of advocacy.

Teams also provide a culture - what do you celebrate and how? Do you celebrate the reason you’re working together?

As a team, you share purpose.

Shared purpose can be a wide boundary. It begins with you and your team but it extends to everyone contributing to the final result.

The more clear and widely understood the shared purpose, the easier it becomes for the team to discuss tradeoffs and critique work in progress.

Giving and Receiving Critique

Feedback is how you know you are progressing or if you have arrived at a stage of completion or commitment.

Whether it’s expert opinion or other evidence from audience reaction and at any given stage, feedback is useful.

Feedback is observable evidence. And making space for feedback creates a place to practice good critique habits.

Critique can be an emotionally charged word. It doesn’t have to be. Good critique is a useful exchange of ideas.

What does good critique look like? It looks like a conversation.

What does good critique feel like? It feels like an interesting conversation.

Questioning and exploring a collaborator’s rationale builds context for critique.

Within that context it can make it easier to have potentially hard conversation because you create a safe place, allow for vulnerability, and can share ideas openly.

The observations (or critique) shared maybe not be new "answers", sometimes they are questions, new questions can be even more valuable for someone looking to make something better.

So how do you create a safe environment for critique? Start with these three parts of asking for critique or giving critique: explain what you made, why you made it for a given audience, and how you made it with given constraints.

Likely choices, tradeoffs, and resulting work will have many layers to it.

Good critique will be navigated by both the person asking for it and the person providing it.

Why makes bad critique bad? Delivery. It could be delivered in a very emotional wrapper. Or stuffed in an envelope of indifference. It could also be inconsiderate of the foundational constraints and tradeoffs necessary in the project.

Our motivation for requesting and for providing the critique is a major influence on the quality of the critique.

I’ve given bad critique. It wasn’t due to shouting, paper-chucking, or indifference. It was due to …. Once upon a time I was a tech and design lead for a content management system platform and fortunate enough where the platform became a defacto standard for the company where I was working at the time.

A project came to me for feedback and at the time I lacked the empathy to really understand their rationale, needs, and constraints. Instead I kept to the safety of my role as a multi-hat-wearing-lead and as a result, we didn’t have a the kind of conversation we needed. What’s worse for me looking back on it, I know that I also missed out on an opportunity to receive their critique in a meaningful way.

Not very Columbo of me. Just as good critique is a conversation, bad critique is an announcement.

The worst kind of announcement style critique: swoop and poop.

Swoop and poop is dropping off a package of reaction and assumption. Even if it is insightful, it’s tough to receive without the context of a trusting conversation.

To avoid or reframe a swoop and poop: remember you have options to renegotiate the situation you’re in to gather feedback. For example, you can offer to dedicate a separate time, place, and structure to explore the feedback.

Sometimes it’s awkward or intimidating to get the critique habit. Retrospectives are a great place to introduce critiquing habits to the team.

Critique of work in progress is useful as is critique in the form of reflection. A supportive team can learn from one another both via current perspective and by listening to be retrospective.

Retrospectives, are a time to gather the team and look back at the recent effort, activities, and results. Through that exploration, your team can list ways to improve what you do next and celebrate both what went well and one another’s effort.

Make Share Collaborate

The Make Share Collaborate Manifesto is a useful set of principles that serve to better team collaboration.

One day I got inspired to interview teams I work with about what they feel should be part of a healthy system, why, and how that ideally flows, looks, and feels.

Those raw interviews grew into the Make Share Collaborate Manifesto.

Read it, sign it, critique it.

I hope you do. Between now and then I offer a key principle from the document: let’s work WITH one another instead of working FOR one another.

WITH changes the dynamic and makes critique and collaboration possible for everyone present.

Dig Deeper Into Rationale with "Why"

If I were Columbo… at this point I’d be heading for the door. I’d also do a quick do-I-have-my-keys pocket patting check. Then after thanking you for your time, sure that you have a busy schedule, I’d pause.

I have just one more question to wrap this session.

Why.

Columbo asks why.

Why is like a magnet that sticks to how people see problems and solutions. It makes it easier to frame project decisions. You have a chance to see how your clients or collaborators see the situation.

Why is that?

Because why keeps us accountable the reasons that what we create.

The things we express are no longer implicit. Assumptions become explicit and out in the open to be observed and understood.

Why lets us open up our intent and see how that relates to our methods.

Why helps us connect more with our methodology, a technique, a given service, tools. It helps us accurately convey the benefit or value of those things.

As a habit, expect others to not just follow what you assume. Share both the narrative behind and the evidence behind what you’re proposing.

You’ll be demonstrating a huge step toward trust and accountability.

Here is an example: a designer asks the engineer…

Designer: Why must the API take so long to return a result? We’re losing conversions in our checkout process. We discussed making the busy animation more compelling - can't we do something more?

Engineer: It’s a tough problem. We have old system integration performance, we also purposely slow some things down so attackers have a high cost for them computationally. Also, it’s just a lot of data behind that page.

What if they share constraints and design a solution together?

Both Together: Perhaps we could stream data or get it in small parts, start showing the user something useful sooner - not just as a distraction.

UNDERSTANDING - one another’s trade offs, constraints, is how to build holistic solutions via constraints, goals of business, human factors, and wider system issues taken together in shared context.

Don’t forget to ask yourself why. It’s a healthy check in with yourself. It also helps practice for the time when someone else is asking you why.

If you build and practice evidence-based habits you’ll be able to avoid blind spots in your reasoning. You’ll make better informed trade-offs and handoffs with any project role.

You know you're on the right track when the project decisions are based on shared purpose instead of negotiation across roles. When the team is more informed by constraints instead of personality and bias compromises.

Collaboration Resources

Great books and resources related to this topic:

• Predictably Irrational: Shares studies on loss aversion from a Behavioral Economics perspective.

• Creative Confidence: Examples, methods, and adventures in evidence based design.

• dSchool site: Provides handy UX tools and guides such as the Empathy Map and so much more.

• Baloney Detection Kit by Carl Sagan will get you in a critical mindset.

• You’re not so smart podcast - An ongoing resource to learn and explore the science behind self-delusion.

• Lean UX book - An approachable lean+agile take on process and many useful techniques + examples.

• Any episode of Columbo (and other detective heroes: Veronica Mars, Sherlock Holmes, Batman the Animated Series)

Time to Be Columbos

Collaborating more like Columbo is a combination of practices. Share and seek critique, explore your biases, and do so with empathy for yourself and others. Ask "why" and find the constraints of everyone that serves your creative project.

If we choose to be Columbos as we make things together…

… collectively we’ll be FLOCKS of COLUMBOS making better creative products with better handoffs.

Afterward and Thanks

After performing this as a talk both at Agile Day Twin Cities 2014 and on the Lean Into Art podcast, each occasion has led to questions from the audience.

One question in particular that has me pondering: two people from an agency’s UX group, both consulting on a client site presented a challenging situation to asking why:

"I can probably ask why once, then it’ll cause a lot of defensiveness in my stakeholders. What should do I do to help them be open to being asked why?"

Sometimes it’s not safe to ask why.

Trust in all directions is important but not always a guarantee. When there’s less than enough trust for any of us to respectfully ask one another "why?" I propose we still have options:

• Consider switching from "why" to one of the other classic investigative questions: how, when, where, who, and what.

• Consider requesting feedback on your observations based on what is positioning the team well or poorly to accomplishing the shared purpose in question.

Finding a way to build trust is critical. There’s a good chance that you’ll be able to build some trust through some conversation other than the "why" conversation. Once you’ve built trust, you might have helped your collaborator with lowering their defenses enough to safely explore “why”.

Keep the conversation open and safe, keep their trust, and be your own Columbo.

Thank you reader! Also, thank you to DevJam and Agile Day Twin Cities where I initially shared this as a talk. Thank you to Jerzy Drozd for performing a version of this with me on our podcast. And extra special thank you to an incredible collaborator, editor, and inspiration who also happens to be my wife: Kate Shields Stenzinger.