Alice, Bob, and Charlie - Context Matters

Nearly a decade ago I had lunch with the founder of (IMO) a very successful company. We talked all things software and tech from programming languages to practices and patterns. We’ll call this founder “M.Z.”. As M.Z. and I talked about patterns and software methodologies, M.Z. shared a story with me about 3 characters, Alice, Bob, and Charlie:

Alice

Alice started a company. A technology company. It took quite a long time before her company was successful, but eventually they found a market fit and found success. As her product matured and her teams matured, they discovered ways of working that lead to their success. They worked as a team - an effective and efficient team, delivering value to their customers and to their people. Customers were happy. Employees were happy. Alice and her team found balance.

Bob

Bob was part of this success. He was a technical team member that loved to take a step back every so often and look at the big picture - the big system that was the product and the team. Bob wrote about the patterns he saw in the way the team worked. He wrote about what worked and what didn’t. He wrote about the “process” that the team had evolved.

He published his writing. Others read it. Others wanted to adopt it in hopes of finding similar success.

Charlie

Charlie read all that Bob wrote. Charlie never worked with Bob, or Alice. Charlie felt frustrations in the teams he’d worked with and knew there had to be a better way. Charlie became so enamored by the dream of working in such a well balanced way that he decided to evangelize the patterns and processes Bob outlined. He left his team to coach other teams. To show them “the way”.

Alice meets Charlie

As Bob was writing, Charlie was reading and coaching. Alice had eventually sold her company, taking some time off, and then decided to form a new company and a new product. She felt like she’d learned so much in her first experience and could make a much larger impact and achieve much more success a second time around.

She was right. She was successful. Her product and team grew at a rate that far exceeded her expectations. Her team was happy. Her customers were happy. The company was growing at an amazing rate. It was growing so fast that, Alice felt it might help to try something new and hire a coach. Scaling is hard and Alice felt as though a coach might help to guide the teams through this uncharted territory of growth.

Alice, by chance, happened to meet Charlie at a technology conference. Charlie was a speaker and Alice was intrigued by what he had to say. It, in some ways, reminded her of what her first team had stumbled upon.

Charlie never knew Bob, and had no idea who Alice was. Alice never knew that it was Bob’s influence and his writing that had influenced Charlie.

Alice invited Charlie to come on site and take a look at how things were going in her new company. He obliged. Charlie spent about 2 weeks on site, sitting in on team discussions, watching how the teams delivered.

After some time, Alice and Charlie sat down for a coffee to discuss what he’d learned.

“It’s clear that your teams can deliver, and that you’re striking a great balance, but there are some aspects of your process that could probably be improved on” Charlie commented.

In Charlie’s eyes, they were following much of what he’d read about and believed could lead to success, but Alice hadn’t adopted ALL of what he’d read about and followed it to the T.

What Charlie didn’t see

What Charlie didn’t see was that Alice had intentionally avoided some of the things that Charlie had read about and some of the things that she’d experienced in her previous team. This was a new team. These were new people, and this was a new product. The context wasn’t the same and as she navigated this new and uncharted territory she’d organically adopted her previous practices, avoiding things she knew might not work in the context she was now in.

To Charlie, Alice didn’t have all of the process in place to make this truly successful. To Alice, the process didn’t matter as much as the people and the product. She did what worked and scrapped what didn’t.

The point M.Z. Was trying to make was - context matters. There aren’t any patterns or processes that guarantee you’ll get the results you want all the time every time. Sure, there are things that work in certain contexts, but out of context, they might not. Even worse, out of context, they could lead to negative results instead of positive ones.

I agree.

Context matters. As I’ve grown in my career, I’ve become more critical of patterns, practices, and methodologies.

This is true at the lowest levels in code and at the highest levels in organizational operation and the way teams work.

I think it’s healthy for us to know what patterns, practices, and methodologies exist, but I believe it’s also healthy to be critical so as not to think that they’re some sort of silver bullet that will lead to success or the desired results 100% of the time. There are often too many variables to be true.

Think about this next time you reach for a pattern, practice, or methodology. Does it fit your context? Are there ways in which it might not? If you’re critical enough, you may find you don’t need all of it - just the parts that will work for you and your team.