Building trust to learn as a team

4 min readJul 31, 2018

Yes: Pigs and Chickens trusting each other and line’s blurring so they can learn as a team!

Giving up control over outcomes to unleash the creativity in your team is a good start, while building toward actual lasting change within your team to take chances, learn together, and feeling safe to do this crucial work, requires trust that:

Ideas won’t be shot down
Every team member’s time is equally valuable
Respect for each other and, as Joshua Kerievsky puts it, “safety is a pre-requisite”.

Q: Who moved my cheese?

A: The market moved your cheese.

Over time, customer needs and expectations change, competitors change their offerings and strategies, markets converge, and new niches form. As no market stands still for your best laid plans, if you’re not learning where your market is moving, your business is slowly dying!

It’s amazing that so many “safe bets” are made each day while avoiding new information from the market. The assumption driving these choices is that incremental change and benefit doesn’t create a hidden, more menacing risk as soon as we turn our senses away from the market and settle into risk aversion. Tick, tock!

It is against this backdrop that Agility rises to embrace change over rigidly following plans. You see, at its core, Agile is a product risk reduction strategy, not a way to build software faster.

Building trust

This doesn’t need to be complicated:

Step 1: Team agrees to solve problems and leaves opinions to the customers.
Step 2: No exceptions.

That was easy, right?

We can even take advantage of automated testing, Behavior Driven Development (BDD) in particular, to let software determine when a solution is ready for customer feedback. That’s a completely objective, automated conclusion!

The ultimate arbiter of whether a problem is solved and whether it delights customers is the market: not the product leader, not those providing strategic vision for a company, not always “the user”. Customers willing to pay for a product (sometimes these people are also “the users”) in exchange for the value it creates are the market.

Benefits of trust

Operating this way moves a team away from trying to please stakeholders and guessing what they are willing to “accept”/churning to satisfy matters of taste and opinions (everyone has one, particularly when there is a user interface involved). This builds trust that everyone’s time and ideas will be respected by the team and a safe environment to take chances and innovate!

Problem solving teams that commit to leaving opinions to customers are liberated to experiment and focus on seeking proof that problems are solved and to better understand the market. That is, frankly, a better use of team resources than trying to find an oracle to lead them.

I’ve seen teams with this level of trust begin to worry about more efficiently solving problems with ruthless simplicity to keep the “complexity costs” in check that Kris Gale describes in “The One Cost Engineers and Product Managers Don’t Consider”. How are you supposed to embrace change if you are building unnecessary barriers to it such as complexity that bogs down the frequency of feedback?

The greatest gift you can give anyone is empowerment: to take chances, to be creative, to take ownership, and to leave their comfort zone

Learning together and redefining success

“Several people fist bumping over a busy workspace” by rawpixel on Unsplash

Your team will test a hypothesis and “fail”, guaranteed. The reality is, you’ve just eliminated a wrong path. Celebrate it! Being “right” about a hypothesis (in the sense of having accurately predicted the outcome) doesn’t make a great team, knowing what to do with what you learned will!

The definition of success for this enlightened team shifts from “getting it right” to learning more efficiently from every hypothesis tested and becoming proficient at what Eric Ries calls “Innovation Accounting”.

Let’s add one new and improved step below to keep the whole team enlightened:

Step 1: Team agrees to solve problems and leaves opinions to the customers.
(NEW AND IMPROVED) Step 2: No gate-keeping customer interactions, the whole team participates.
Step 3: No exceptions.

Conclusion

Without a gatekeeper, the team listens, digs deeper to understand problems, pivots, and develops their next set of hypotheses together: building team wisdom about what they learned.

This pattern develops a whole team of customer advocates building empathy and pushing to solve problems for customers with faces and names who’s pain they understand. That’s way better than just one oracle, right?

Shout out to Rob Gordick who believes in celebrating learning and who presents frequently in the Agile conference circuit. Check him out, you won’t regret it!