Most of what I’ve written about in this series covers well-worn ideas and concepts you can find in countless frameworks, books, and courses. But one thing has always struck me as odd: none of them focus on advocacy as the ultimate goal of change management.

And to be clear, I’m talking about corporate organizational change management, not advertising or brand promotion. In marketing, advocacy is the endgame. It's why companies put logos on clothing and turn customers into brand evangelists. But in corporate change initiatives, advocacy is rarely positioned as the final stage.

Why? I could speculate on many reasons, but ultimately, true advocacy requires a level of ownership that most organizations are either unwilling or incapable of fostering. You cannot force people to become advocates from the top down. The old joke--"The beatings will continue until morale improves"--feels painfully relevant here.
​
The unfortunate reality is that most people reading this article will never get the chance to implement true advocacy in their workplace. And that’s a shame. It speaks to how modern organizations view work—as something transactional, rather than something people feel a deep sense of ownership over. The best part is that ownership does not require abandoning a true life-work balance. 

The idea that advocacy is the final stage of change management isn’t new, nor is it mine. In my previous article, Facilitating Real Change, I outlined a pattern I recognized in behavioral change:

Awareness → Understanding → Acceptance → Adoption → Advocacy
​
For most of my adult life, I’ve been fascinated by this idea: What does it take to get to advocacy? It has shaped my approach to leadership in both professional and personal ways.

​The first time I truly understood the power of advocacy was when I served as president of the parent association at my children’s school.

I was approached in our second year at the school because the organization was struggling to find a leader. What I found was a top-down volunteer group where parents were disengaged. Meetings dragged on because everyone had to navigate the internal politics of the president. As a result, very little actually got done.

What struck me was that people were already passionate about the cause, but they just didn’t feel ownership over the organization itself. I found a lot of parallels with ideas I explored in my master’s thesis on the motivations of university major donors. Unsurprisingly, the biggest predictor of lifelong giving was a donor’s sense of ownership of their school, often formed through deep involvement in student programs.

That idea stuck with me. People give back because they feel connected to something bigger than themselves and want to shape its success.
So my goal with the parent association was simple: maximize ownership and autonomy for volunteers.

Over many years, we overhauled the structure, replacing top-down leadership with autonomous committees. Each year, we ran a retreat where parents planned and prioritized work based on their passions and alignment with the school’s mission. The most passionate individuals chaired committees and controlled the work.

The only two things that remained “top-down” were the fundraising campaign and teacher appreciation week. Everything else was entirely committee-driven. Board meetings became status updates, not approval sessions. We even explicitly labeled each agenda item as:
​

• Inform (just sharing updates)
• Input requested (seeking feedback)
• Approval needed (formal decision-making)

This structure allowed those doing the work to retain control, preventing their efforts from being derailed by well-meaning but misguided comments like, “Have you thought about…?”
​
After 10 years leading the organization, I finally stepped away. And here’s what didn’t happen: it didn’t collapse. In volunteer organizations, when a strong leader leaves, things often fall apart. But years after my departure—even after the disruptions of the pandemic—the group is stronger than ever. The advocacy model worked. The structure enabled advocacy to sustain itself beyond any one individual.

In previous articles, I’ve talked about mob programming and other techniques my teams have implemented, but at its core, what made this work was a deep sense of trust and vulnerability. The team set aside ego, embraced failures as learning opportunities, and focused relentlessly on finding the best solutions.

A few key things made this possible:

1. Small, low-risk iterations – We took in work in small enough increments that mistakes were minor and easy to fix. This removed a lot of fear from the process.
2. Psychological safety – Every two weeks, we measured psychological safety, clarity, energy, work-life balance, and confidence. These became leading indicators of success, allowing us to track how changes in process or workload impacted team morale.
3. Continual refinement – If something wasn’t working, we fixed it immediately. The process evolved constantly.

After 6 to 9 months, this approach became the glue that held the team together. They couldn’t imagine working any other way. More importantly, they became advocates and were willing to spread these ideas across the company.
​
And then...leadership changed.

The new executive team didn’t understand or value what we had built, and they dismantled the system almost immediately.

Normally, when leadership blows up a successful initiative, teams just accept their reality and revert to the old way of working.
​
But not this team.

They fought to preserve what they had created. Even in a radically different environment, they worked to incorporate elements of what they had built into their new teams. They had gone from initial skepticism to embracing the model to championing it despite adversity.
​
That transformation—from resistance to advocacy—is the greatest professional achievement of my career.

For much of my life, I viewed advocacy as a mythical end state—something possible in theory but nearly impossible to achieve in reality.

The fact that I’ve now seen it happen twice still amazes me.

But I want to offer a cautionary tale about what happens when advocacy goes too far. When advocacy isn’t built on a proper foundation, it can turn into zealotry.

When people feel deep ownership over something unique and successful, it can become part of their identity. That’s when advocacy risks turning into dogmatic enforcement. It happens all the time. You see it in tech teams that refuse to consider new methodologies, in corporate cultures that resist change in the name of preserving their "ideal" state, and in movements that turn rigidly exclusionary.

As a leader, the best way to combat this is to question everything.
​
Creative teams are never static. What worked six months ago may not work today. The world changes, and we must be humble enough to recognize that and brave enough not to fear it.

Advocacy isn’t just about sustaining change. It’s about making it self-reinforcing. If you can build something that people want to protect and evolve, then you’ve achieved real, lasting change.

But true advocacy requires ownership, not just compliance. It cannot be mandated from the top down.
​
And it must remain adaptable.

Because even the best systems, if left unchecked, will eventually become the very thing they once sought to change.

Have you ever wondered why some teams thrive while others stagnate? The difference often comes down to one thing: the ability to experiment fearlessly. 

In a previous article, I defined autonomy as the ability to make decisions and act independently without constant approval. While that definition doesn’t explicitly state that these decisions should focus only on known solutions, that’s where most people naturally start. However, to truly succeed, you can’t stop there. 
​
For creative teams, building something new is often a peak experience, but too often, organizations get in the way of that happening.  

If you were to ask a musician, chef, or visual artist why they constantly create, you’d likely get a look of incredulity. The very idea of not creating would seem absurd. 

We eagerly anticipate new albums, pre-order books months in advance, and line up for opening nights at the theater. Clearly, we understand the value of creativity in the arts. 

So why don’t we think of business and technical teams in the same way? Why don’t we afford them the same creative freedom? 

The answer is simple: risk aversion, short-term performance pressures, rigid processes, lack of real support for innovation, and traditional leadership models all work against experimentation. 
​
The problem isn’t just that organizations limit creative latitude. Your best talent won’t tolerate it forever. They’ll either move on to a place that values their contributions or disengage, giving you only a fraction of what they’re truly capable of.  

If you’re lucky enough to work in an environment where experimentation is at least tolerated, if not outright encouraged, your job is much easier. Your main challenge is fostering a mindset that embraces creativity. 
 
When I was writing code full-time, I made it a personal challenge to try something new in every project. Even if the project was nearly identical to past work, I found a way to push my skills forward. 

You can instill the same mindset in your team by rejecting the first idea instead of settling for the obvious solution and pushing for deeper exploration. Another effective method is to create small competitions where team members independently propose solutions to a problem and discuss them the next day. Encouraging learning through doing is also essential. Too often, teams feel pressure to be perfectly efficient, but real progress comes when they take time to explore and refine ideas. 

One key challenge will be managing expectations. Many organizations pressure teams to move fast and minimize perceived inefficiencies. This means you may need to advocate for time and space to experiment, both with your team and with stakeholders. 
​
Over time, as the benefits of experimentation become clear, this process becomes self-sustaining. When a team sees firsthand how experimentation fuels progress, the energy it creates is unmatched.  

​But what if you’re in an environment where experimentation isn’t just ignored but actively discouraged? 

Many of us have worked in deadline-driven, metrics-obsessed environments where anything short of pre-planned perfection is considered failure. If that’s your reality, I won’t sugarcoat it. This is harder. 

Still, even in rigid environments, there are ways to introduce experimentation, but you have to start small. 

Tactics for Navigating Risk-Averse Environments
​

• Build buffer time into estimates. If you have control over timelines, add a little breathing room for creative problem-solving. 
• Take responsibility for risk. Your team may not be willing to take the chance themselves, so you’ll need to absorb the risk as their leader. 
• Understand your stakeholders. If an experiment fails, ensure you can still deliver the original plan. If it succeeds, make sure the value is undeniable so leadership supports future risks. 

 
I won’t pretend this is easy. Experimentation in a risk-averse company requires careful navigation, but when done well, the payoff is significant.  

I once worked in an organization obsessed with tracking every minute of engineering time. Work was rigidly divided into “maintenance” and “new development,” with strict limitations on how much time could be spent on each. 

This made experimentation nearly impossible, at least on the surface. 
However, one organizational loophole gave us a way in. There were few expectations around personal performance goals. 

I used this to encourage my team to explore new ideas within the context of professional development. Whenever possible, we aligned these explorations with anticipated future work so they could be framed as pre-planning. 

​Not everyone embraced it equally, but for those who did, we created team demonstrations and celebrated their discoveries. This built a culture where experimentation wasn’t just tolerated but quietly encouraged.  

On the other end of the spectrum, I once had the rare opportunity to lead a team with significant flexibility for process and technology experimentation. 

This experience fundamentally shaped my understanding of self-managing teams and what’s possible when autonomy and trust align. 

But even in this ideal scenario, we faced an unexpected challenge: fear of releasing new ideas. 

The team became so comfortable with research and planning that they hesitated to move from learning to execution. They had embraced experimentation as a way to learn but hadn’t yet made the leap to using it as a tool for delivering value.

To address this, we shifted from a study-then-execute approach to a learn-as-you-go model. The results were striking. The team moved faster, confidence increased, and productivity rose significantly. 
​
The lesson? Even in environments that support experimentation, momentum matters.  

Whether you’re in the best-case or worst-case scenario, the core principles remain the same. 

1. Encourage External Growth
Encourage your team to seek out new ideas beyond your organization. I avoid the term best practices because what works in one environment won’t necessarily work in another. 

One of my go-to interview questions is, “Where do you go to learn new ideas?” I never use the answer as a negative, but I do see it as a signal since many organizations don’t encourage continuous learning
. 
2. Promote Creative Freedom
This can be as small as an individual learning goal or as big as a fully experimental project. 

But beware of the hero mindset, where one person always has the answers. That kind of culture stifles creative freedom before it even starts. 

3. Shift Toward Self-Organization
If risk-taking and experimentation are only driven from the top down, teams won’t truly own the process. When teams take accountability for their own risks, they are far more invested in the outcome. 

4. Create Space to Learn Without Immediate Expectations
If your organization is hyper-focused on metrics, this will be difficult. Creativity isn’t an assembly line process, and treating it as one kills innovation. Your job as a leader is to carve out protected time for exploration. 

5. Beware of Over-Measuring Productivity
Measuring creative teams like a manufacturing line is a guaranteed way to destroy both creativity and productivity. 
If you don’t control how your organization measures success, at least be aware of these dynamics so you can set realistic expectations for experimentation.  

Organizations and modern society often reinforce the idea that experimentation is dangerous. The longer someone has been in that kind of environment, the harder it is to shift their mindset. 
​
But if you can build a team of risk-takers, the pride, loyalty, and energy you create will be incredibly powerful.

In all my years of interviewing, I’ve never been asked how I approach adaptability. Sure, I’ve been asked plenty of indirect questions about how I handle changing situations, but no one has ever asked about my overall philosophy on adaptability. And yet, I’d argue it’s one of the most important characteristics a person can have at work and in life.

My theory? Most interviewers focus so much on whether a candidate can do the job today that they overlook whether they’ll thrive as the job evolves. That might be a broad generalization, but in my experience, it holds a lot of truth.
​
When I was managing project-based consulting practices, I struggled to find people who could truly succeed in that space. Every project, every client, and every problem was different from the last. People who weren’t adaptable at their core, no matter how smart or skilled they were, simply couldn’t succeed. Eventually, I developed an interview technique that, once refined, completely eliminated unsuccessful hires. I’ve used it for over a decade.

Anyone who has worked with me over the last decade probably knows about Hank, the sandwich shop owner.

The scenario is simple: Hank has been running a sandwich shop for decades in the same location. He is very much a Luddite. But in the last few years, a technology park has sprung up around him. His customers love his sandwiches and desperately want to order online. Eventually, he gives in and asks for help. That’s where the interviewee comes in.

I’d set the stage and say:
"Hi, I’m Hank. So, now what?"

This wasn’t a theoretical discussion. I became Hank. The interviewee had to role-play, speaking to me as if I were the small business owner asking for help.

This exercise was invaluable. Unlike standard interview questions, this method got to the real person, not the polished, rehearsed version. You can’t fake adaptability in a live interaction. If a candidate made assumptions, Hank had no idea what they were talking about. If they threw out jargon, Hank pushed back. Sometimes, Hank was a bit skeptical. After all, the person on the other side of the desk didn’t know anything about sandwiches. Within minutes, I could tell whether they were truly adaptable or just good at giving prepared answers.
I wasn’t just looking for technical skills. I wanted to see how they reacted when their initial approach didn’t work.

The second part of this technique was even more revealing. Right after the role-play, I gave the candidate direct feedback, as if I were their manager reviewing their work. Did they get defensive? Did they listen, process, and adjust? Could they reflect on what they’d do differently next time?

I’m not exaggerating when I say that after implementing this technique, I never made another misaligned hire.

One of the most memorable responses? A candidate started with:
"You should just sign up for Uber Eats."

It was so brilliantly simple it caught me off guard. I hired them.

I have a couple of dozen articles I plan to write before I leave this mortal coil, but this one felt particularly important this week.

I’ve been actively job searching for a year now, and I’ve never had an interview like this. In an industry addicted to accelerating change, why is adaptability never the focus?

Companies, Microsoft in particular, love to talk about the importance of a growth mindset. For the record, I love that book, that philosophy, and try to live by it. But to me, you can have adaptability without a growth mindset. Adaptability feels like a more fundamental, elemental trait. It is something you need regardless of whether you’re actively seeking growth.

I asked ChatGPT why interviewers tend to zoom in on isolated examples of adaptability rather than assessing it as a broader characteristic. The response?

Interviewers structure interviews around their own perspective, biases, and what they think they need for the role.

And I have to agree.
​
Making an unsuccessful hire reflects poorly on the hiring manager. So, the instinct is to control as many variables as possible to minimize risk. But in doing so, they end up chasing a fear of failure instead of pursuing the possibility of success. (I know that last sentence feels like a cliché, but I couldn’t help myself.)

On my morning run, I was thinking about the roles I’ve held over the past twenty years. It should be obvious that I’m highly adaptable. I’ve succeeded at every level, in every environment and those successes were anything but linear.

But there’s a bias that cuts both ways:

• "You’ve never worked at this level before, so you couldn’t possibly do it."
• "You’ve worked at a much higher level than this. Why would you want to do something different?"

In my case, sometimes my role changed by choice. Many times, it didn’t. And yet, every time, I adapted and (eventually) thrived.
​
One of the most profound experiences of my career was transitioning back to managing an engineering team at Bluetooth SIG. I wasn’t sure I was up for it as it had been well over 15 years since I had written any code. In the end, it turned out to be one of the most fulfilling jobs of my life. I watched my team embrace adaptability—not just as a necessity but as a strength. I know the organization was stronger because of it. That experience is what started me writing about my philosophy of management: https://www.syme.info/writings/cultivating-self-managing-teams.

If you’re a hiring manager staring at a stack of resumes, take a second to think about who might actually help Hank the most.

Don’t just ask for a single example of adaptability. Find out how they think about it. Because the best hires aren’t just good at handling change when it happens.
​
They expect it.
They embrace it.
And, when the time comes, they drive it.

​Autonomy is the ability to make decisions and act independently without needing constant direction or approval from others. In most workplaces, this is usually a privilege reserved for only the most senior employees. More junior people can strive for autonomy but frequently spend an extraordinary amount of time justifying and getting permission to follow their instincts. I spent two years selling one big idea in my first career role. It was transformational for me and the company, but I can’t count how many times I failed to sell an idea before that one was a success. This cost-benefit ratio isn’t worth it for many, so we create a workplace culture that rewards the “we-have-always-done-it-this-way” mindset. Because of the prevalence of taking the safe path, many folks early in their career aren’t even aware that there is another choice.

​There is a reason I wrote three articles about creating a safe space before writing about autonomy. Too many organizations have made the price of autonomy far too high, and undoing that damage takes more than just a presentation or an afternoon workshop. Building and maintaining a self-managing team is not a zero-sum game. The amount of autonomy you empower should be proportional to the level of psychological safety your team has established.
 
I want to make one critical point about the rock star—the team’s source of all new ideas. This person is likely the hero I referenced in Collective Accountability and Quality. If you are still working on collective accountability, there is a good chance that your hero can quickly derail your work. They will do this in one of two ways: Passively, by projecting that they are the final arbiter of new ideas; actively, they quickly jump to the end state of an idea and say why it won’t work. I’ll talk about ways to address this in the next section.

How do you know when the stage is set? One of the easiest is conducting periodic anonymous survey asking people to rate their psychological safety on a scale from 1-10 and track it over time. You can also use more subjective measures like meeting participation, retrospectives, and how often new ideas are presented.

I promise everyone has ideas about how they want to see things done. For many people, those muscles may have atrophied, and some initial ideas may need some extra time to develop. Here are some techniques I have used to encourage autonomy.
 
Performance Review Goals:
Performance review goals provide tremendous opportunities if you work at an organization that allows performance review goals centered around the individual’s or team’s interests. Encourage (even direct if necessary) everyone to explore novel solutions to existing problems as their goal. Then, set the expectation that the team will all present to each other at the end of the review cycle. Ideally, there is no overlap in the goals, so everyone can own their idea without being compared to anyone else. Not all the results will turn into an actual implementation. Still, it begins to establish everyone as an individual with their ideas and reduces the focus on the team hero. This technique is also very effective in aligning the hero while allowing them to shine when it is their turn to present.
 
Reject the Default Solution:
Rejecting an idea requires a degree of expertise in the team's work, as there is a right and a wrong time to use this approach—the wrong time is when the default solution is the only solution. You can gently reject the default solution by asking, "How would you do this if you were starting from scratch today and didn't have time and budget constraints?" Chances are they won't get exactly what they want, but it will open a dialogue about alternative approaches that could be partially adopted. Watch out for the hero explaining why you can't start from scratch. This exercise may feel like a waste of time and won't be the most efficient use of time. As such, you must ensure you have enough trust that the team will indulge this "ridiculous" question.
 
Ask What Problem We Are Trying to Solve:
Most people want to jump to a solution, especially in software, where we frequently hear things like: "Just add a button on this page at the top." We have conditioned teams to accept that a request that includes the implementation is normal and expected. It is not. A self-managed team will respond by asking what problem we are trying to solve and save the "how" for after that understanding is attained. By focusing on what needs to be accomplished, you invite everyone to share their perspective on what implementations could achieve that goal. The more skills and disciplines you have in the room when asking that question, the better the options you will get. Having differing expertise in the room will also help align the hero, as they probably won't be the loudest voice from every perspective.
 
Mob Programming/Group Work:
Mob Programming is one way to institutionalize the three previous steps. You make the default working method where people from multiple disciplines bring their ideas and find the optimal answer. This takes time. Even if you can jump into mob programming, you will still have to work to establish that deep psychological safety.

​Autonomy is scary for everyone, and there will always be reasons not to do it. Here are some common objections and some techniques that you can use to work around them.
 
Deadlines:
Deadlines are a necessary evil (mostly) and, unfortunately, are the rationale for many bad implementations. Working around deadlines will require you to take the long view. How long depends on the severity and flexibility of the deadline, but they don't necessarily preclude any autonomous thinking. One technique I have used is to once again ask, "How would you do this if you were starting from scratch today and didn't have time and budget constraints?" Take that answer and create a reference solution. Refer to that reference solution every time relevant work is being done and look for solutions that still meet the deadline while moving closer to the reference solution. In some cases, this can require a very long view and a lot of cheerleading on your part.
 
Silence:
Some people may not want to or cannot participate in autonomous thinking within the existing framework. The solution to this is going to be very individualized. If you aren’t already meeting regularly with your team individually, start doing that. Ask questions and listen. In time, most people will share what is holding them back. You will then need to be creative to help find ways for them to use their voice. One big step will likely be recognizing what you have been doing to hold them back. Humility and compassion will go a long way in opening communication channels.

​Organizational Resistance:
Sometimes, your organization may reject anything but the tried and true. Resistance could be from an old guard that won't cede control, regulatory/governance requirements, or a complete lack of incentive. Unfortunately, there may not be a lot you can do in this case. However, if you are determined to give it a go, find a low-risk/low-threat problem that hasn't risen in importance enough for anyone to do anything about. Come up with a new solution, and if possible, just fix it. If you can't do it and just ask for forgiveness, propose a way to fix it without any negative impacts on the organization. This approach is tough, but with enough perseverance, it might just be possible.

In my opinion, teaching autonomy is the hardest part of cultivating a self-managing team. But when done correctly, this step in building a self-managing team can fundamentally alter the trajectory of your team's careers. They can graduate from being people who execute tasks to people who own a problem and find a solution. I have witnessed one of my self-managing teams run circles around a team twice their size because they understood how to own the problem completely. Perhaps the most rewarding part of that team was the sense of autonomy, and ownership didn't end when I was no longer managing the team. They had internalized this mindset so entirely that when moved to a team that didn't practice this way of working, they kept doing it anyway. They also tried to influence the way the other team worked. I can't imagine a better validation of our approach than that.

There was a point in my life when I loved being the hero. I would pull all-nighters working on a technical problem. The thrill of finding the solution muted the sheer terror I felt at 3:00 AM, knowing that I had nowhere to turn for help. The problem with being the hero is that you soon become the bottleneck, and the praise for the initial solution is lost due to the frustration of stalled progress.
At some point, I decided this was no way to live. The stress of the hero going on vacation, quitting, or being so overloaded that nothing could get done drained everyone and greatly informed how I structure and manage teams. It turns out that the simple idea of having no heroes was a stepping stone to profound changes in accountability and quality. In most organizations, each team or system has a hero—the person who is always called upon for anything related to the need. Removing the hero helps move beyond individual accountability to collective (shared) accountability. In hindsight, the connection is obvious, but I came to this understanding organically.

The examples below for removing the hero are from an engineering team I managed, but these concepts still apply to any creative team (see Cultivating Self-Managing Teams). Here is the sequence of tactical changes I made:

• If the same person always picked up a particular type of work, I encouraged (and later directed) others to do it, even if it took longer. This was moderately successful but quickly broke down when something was urgent, or the team was overloaded.
• I stopped going only to the most senior person on the team when there was a production issue. I posted the problem in a team forum. Every single person rose to the challenge.
• We adopted mob programming (slowly). Mob programming is basically group design and initial coding, then often (not always) moving to individuals to complete the implementation.

Mob programming was the turning point. After a lot of trial and error, the following ended up happening:
​

• The person who knew the system the best shared everything they knew. The team asked questions and collaborated on the change. Later, this led to organic refactoring (making old stuff better).
• Everyone understood what design decisions were made and why they were made. This made pull requests (code reviews) a formality that took virtually no time.
• The engineers regularly pulled in Product Management during design, which eliminated implementation surprises that needed to be changed late in the process.
• Within a year, anyone on the team could handle any technical issue or task. This is not hyperbole. Everyone on the team was genuinely interchangeable.
• All of this upfront communication increased the team's throughput by 25% simply because they caught most changes before the final implementation.
• What did it do for quality? We basically eliminated all production regressions (breaking things that used to work). Every substantive design was discussed from multiple perspectives. Rework was dramatically reduced.

​

• We continually gave the team space to learn and make mistakes. They learned to trust each other and their management (see Foundation of Trust).
• The team created their own working agreement and continually updated it as we evolved. This codified what collective accountability looks like.
• We made transparency paramount (see Foundation of Trust).
• Everything they did was viewed through the lens of a team, not an individual. It quickly grew to include Product Management, UX, and IT as actual team members.

​The necessary elements to make mob programming (or any team creative endeavor) work lead to accountability and higher quality. Both grew organically from a sense of safety. Always do everything possible to resist a hyper-focus on accountability without an established trust/psychological safety baseline. In addition, the team should establish what accountability (working agreement) looks like to them. That base level of ownership will permeate everything and turn into collective accountability.

​Despite the glut of collaboration tools and frameworks today, fostering an intrinsically collaborative mindset takes tremendous work to make it part of your team's core identity. It is worth it.​

Trust is one of those things that we don’t discuss a lot in the work environment, but I guarantee it affects you daily. Who do you reach out to when you experience frustration? Who do you have to help you solve a problem? Who are you most likely to admit to making a mistake? How about when you have a big win? It’s probably the people you trust the most. Who don’t you go to in those same situations? The people you trust the least. 
If trust is so important, why don’t we do more to nurture trust at all levels of our organizations? While there is no one answer, I think one significant reason is that trust is hard. Trust requires vulnerability. Trust takes a two-way commitment. Trust must be earned every day. It can be lost in an instant. It is a high-effort, high-reward activity that you may only realize you have after you have had it for a while. There is no certificate for passing the trust test. However, I would argue that the cost of not continually earning trust is far higher in terms of time, work, and emotional toll.

Here are some of the ways we expend unnecessary effort when we don’t have trust:

• Over-scrutinizing information we share to avoid it being used against us.
• Choosing safe, established solutions over potentially new and more efficient ones because the new approach might fail, and we don’t want to be blamed.
• We do precisely what is asked (nothing more or less) even though we know it won’t meet the requestor’s needs, and we will be asked to change it.
• Spending a lot of time hiding our failures or calling out others instead of learning and improving. 
• Viewing the mistakes of others that negatively impact you as intentional.

What would your day look like if you could just stop doing all those things? How much better could you do things? How much less decompression at the end of the day would you need? It would be amazing.

Here are some things I have done to build trust in my teams. 

​You don’t need to buy a cake. While it rarely feels like a celebration, you should keep the conversation as positive as possible. Try phrases like, “Now we know that won’t work. That’s something new we learned.” “Thank you for being bold.” and “I would have thought that would work, too.” 

I usually try to generalize my descriptions, but this is one where I think it applies incredibly well to software development. However, it should resonate anytime individual work streams converge for a single deliverable.

I have vivid memories from my time as a software developer. At times, I was terrified of a technical problem I was tasked with solving alone. I pulled many all-nighters working on those problems. The elation of eventually finding the answer kept me going for a long time, but it came at a high cost.

I had been intrigued by paired or mob programming for years. When I finally got to try it with a team, there was a lot of resistance. Everyone assumed that working individually and in parallel was faster. It turns out that in all but the most routine tasks, individual silos were slower. Why?

• Poor choices were made because the person making them had only their own limited perspective. This led to rework.
• The added time it took to explain and combine work.
• Not realizing someone else already knew how to do something.
• Individuals would become paralyzed and overanalyze what they were being asked to do.
• Fear of admitting that you don’t know something and remaining stuck.

It took a few months to work out how to do it. Although not linear, we went through all of Tuckman's stages of group development again (forming, storming, norming, and performing). See my post on facilitating real change. Once we did figure it out, the impact was significant. Work (code) reviews could hold up the team for days. When everyone was involved in doing the work, they were almost instant. Rework was virtually eliminated. Testing and development ran in parallel. In many cases, we were working up to 75% faster. All those metric improvements are enormous, but trust made the difference.

Everyone realized everyone else had insecurities, too. They stopped trying to hide them and just worked together. Great ideas from quiet team members began to surface much more frequently. There were no more heroes. In time, everyone on the team understood most of everything we were responsible for. Time off and sick days were no issues, as anyone would pick up almost any work. The trust grew to include Product Management and IT operations. Over the course of a couple of years, they grew from a team that found any excuse to avoid trying something new to a team that would commit to the unknown and just work the problem together. 

I recently had a member of that team comment on how much the psychological safety of that team made all the difference in their work life—and I suspect their personal life, too.

The main thing that all these activities have in common is fostering a sense of psychological safety. There is a ton of research over the past 50+ years on the positive (and some negative) impacts of a sense of psychological safety. It was a core component of how we chose to work. We used to measure psychological safety, among other things, at the end of every two-week development cycle. It was a simple, anonymous rating on a 10-point scale. We tracked the results from cycle to cycle. Allow people the space to learn and grow. Sometimes, you'll need to push people out of their comfort zones, but I promise that doing the work to earn trust has payoffs in virtually every measure of happiness and success.

Rebuilding trust after it's lost takes time. One phrase I consistently use to remind me of the best approach is “Curious, not furious.” Very rarely is malintent involved when trust is broken. So, taking time to understand the intent of the parties that broke the trust and helping them understand the impact on those for whom the trust was broken is an excellent way to start. In the software world, many teams will do a retrospective at the end of a development cycle. If done well, that retrospective can be a mechanism to continually exercise the impact and intent muscles so that when you do have a larger breach of trust, the activities you need to go through to regain that trust are something that the team is familiar with and has become part of their core identity.

​I put the team in a situation where they had to learn trust to succeed. I had the runway to take the time to ensure it worked. It worked beyond my wildest dreams. To reiterate an earlier point, there was no point where we all got a certificate of trust. We worked on this daily. There were some tough conversations when trust was broken or strained. Many times, it was my direct actions that caused that break or strain. But every single time, we were vulnerable and honest, and we came out stronger.

You can be great without trust. Why would you want to?

Raise your hand if you have ever been through organizational change training. I have been through at least five during my career, and while they all have something to offer, I have yet to see any of them effect lasting organization-wide change. This process is deeply personal. It involves a level of introspection that can be uncomfortable. It's entirely reasonable to want to avoid discomfort. So, as soon as the focus is off, most of us return to what is comfortable. Organizational shift is possible, but not as an end goal by itself. You must continually enable a culture that embraces change and discomfort.

More on that at the end.

I decided to go to grad school in Communication after I discovered that music education wasn't for me. When I told a class of young elementary students that my name, Syme, rhymed with slime, it was a clear sign that I might have other strengths to focus on. Communication is an interdisciplinary field of study. It borrows heavily from other academic fields and often focuses on understanding how communication affects behavior. In academic article after academic article, I kept seeing a pattern like this used to describe the stages of behavior change:

​While different studies have more or fewer steps, I took this as the essence of how people progress through change. This view of behavior has framed a significant portion of my professional career.

Understanding almost always comes right after awareness. You can tell you have reached this stage because the person will look at you and ask, "Why?" After you tell them, you are done—mission accomplished. If only it were that easy. What they are asking for is the external why. They are asking, 'Why do you think this is important? They haven't begun to figure out if it is important to them.

Remembering that importance to you, the team, the company, or the planet may not translate to vital to them. This stage's point is to convey why you feel this is important, not necessarily to gain their agreement.

This is the point where they believe you. In a conversation, you may get some head nods or an “Okay, I get it.” Again, it is essential to recognize that understanding something doesn’t mean it holds any relevance. It might, but that’s not something you can assume at this point.
​
Avoid the temptation to think that because you made a PowerPoint or sent an email, the job is done. Each situation will require differing levels of evidence to convince people of acceptance, but until you do, all you are doing is lecturing. It may take several different ways of presenting the need to get acceptance. Resist the urge to say, “Because I said so.”

Finally, if the internal "why" makes sense to them, they will incorporate the new behavior into their lives. Congratulations—mostly. Unfortunately, adoption does not necessarily mean that they like or agree with the behavior. All you can assume is that they understand why they should do it. How many times have you made a change because failure to do so would jeopardize your job? Most behavior modification programs end here. The problem is that there is no reason to continue the behavior once the "internal why" isn't relevant. 
​
The bad news is that if you haven’t laid the proper groundwork, this may be as far as you can get, which is why many programs end here.

​This is the goal. At this point, they have fully internalized the value of the change and believe it holds value for others as well. A significant challenge often preventing advocacy achievement is asking for a change that doesn't benefit them. If you haven't figured it out, top-down directives can't get you here. So, what's a growth mindset advocate to do? It involves trust, accountability, autonomy, and experimentation. More articles are coming, so I won't leave you hanging for too long.

As evidenced by my feature flag stories, this is usually not a linear progression, and rarely are all members of an organization at the same stage simultaneously. Ideally, I would have worked on getting a sense of ownership from the team far earlier in the process. It would have saved me so much work. Remember, I said change is deeply personal. This makes the process complex. The support needed to move to each stage will be different. 

If your goal is advocacy, as I believe it should be, then you will need to find a way to support every individual you are asking to change at every stage you are asking. You need to be aware enough to know if someone skips a stage or backtracks and help guide them appropriately. Fortunately, you don't have to do this alone if you have created a culture that embraces change and discomfort through trust, accountability, autonomy, and experimentation. 

​This takes time.

​Value. We all want our time, ideas, and work valued. Organizations desire value from their staff. We measure value in many ways but do not speak about it holistically nearly often enough. Specifically, how valuing the individual can translate to the bottom line. Cultivating a self-managing team is a powerful way to create holistic value in your organization.

I’m using the term self-managing intentionally to reference a team primarily responsible for choosing what they work on and how they do it within larger organizational priorities.
​
Even if your goal isn’t to create a self-managing team, partial adoption of these ideas can significantly improve the quality of your team’s work life and ultimately lead to better results.

A word of note: everything I will be writing about is viewed through the lens of a creative team. By creative team, I mean any team responsible for creating something that hasn't previously existed. In my case, that is mostly software. But it would apply equally to arts, content creation, new product development, etc.

I look forward to sharing my thoughts on the following topics.

Facilitating real change (view post)
If you've spent time in the corporate world, you have probably been subject to organizational change training. My experience is that one-size-fits-all approaches never achieve the organizational-level impact they were supposed to. The fundamental flaw with those approaches is that they failed to recognize that change is very individual and personal. And to affect change, you must treat it as such. My graduate work in communication studies also supports this.

Foundation of trust (view post)
Trust is the cornerstone of everything. You can't accomplish any of this without a solid two-way trust dynamic. Without trust, the inevitable mistakes are rightly viewed with suspicion. And trust is something you must earn every day.

Collective accountability and quality (view post)
This is one of my favorite areas to address. If you've established enough trust, collective accountability removes an unbelievable amount of stress from the daily life of your team. Quality will shoot through the roof, and the value of what you're trying to accomplish will become apparent.

Teaching autonomy (view post)
This one is tough. It's hard because most people come with minimal autonomy experience in the workplace. And there's a good chance they would be shut down if they tried to exercise autonomy early in their academic or professional careers. So not only do they not have experience with it, but in many cases, they don't even know it's an option. You can get people there, but you must have trust and cooperation.

The power of experimentation (view post)
This is one area that can be heavily affected by the work environment. However, even within highly structured organizations, there is room for experimentation. For most people in a creative field, doing something new, especially something that's never been done before, is the peak experience they seek. Building the foundation to allow experimentation can alter the trajectory of an individual, team, or organization.
​
Making change permanent with advocacy (view post)
Even the most introverted person will want to talk about the work of a team that trusts each other, holds each other accountable, embraces change, and is not afraid to try new things. A team that advocates for themselves is the most powerful change agent one can imagine. That advocacy can spread throughout an organization and have impacts far beyond the team from which it originated.
 
Like many managers, I became one because it was the next logical step in my career. It took a while for me to see the importance of empowering individuals and even longer to figure out how to do it. That journey and my current waypoint (there is no destination) have been unbelievably fulfilling. The information I will share in the coming weeks comes from my actual implementation of these principles. I’ll share “names changed to protect the innocent” stories of success and failures. This writing reflects my current thinking, but I am continually evolving, so I welcome your thoughts and questions.