​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, Mr. 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
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
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.