Happy Friday!

I mentioned in my previous email that I've been reworking my site in preparing for some larger changes. I posted my first new article that is based on my new direction of writing for technical leaders and product managers. My first article is Quick and Easy Delegation Even If You're a Busy Leader. I'd love to know what you think!

A topic that started popping up several years ago was around the idea of self-managing teams. As with most things, it is vaguely defined and keeps bouncing around in various articles and sources. I thought I'd give my own perspective on the topic and some guidance.

What Are Self-Managing Teams?

I'm going to define self-managing teams as teams that are able make nearly all relevant decisions within a given bounded context. Those are some fancy words, and I'll break them down in a moment. More to the point, though, what isn't in the definition is what role a leader plays in a self-managing team.

A leader's role in dealing with self-managing teams is to build and maintain the environment in which a self-managing team can successfully operate within. More fancy words! Alright, breaking this one down, leaders of self-managing teams are paying attention to how information is flowing in and out of the team, communication gaps, missing context, and bridging legacy expectations of who has authority to do things. These leaders, for example, may still attend leadership meetings but only to satisfy the expectations of their peers and turn around and completely delegate all decisions to the team.

The self-managing team uses the information, goals, guidance, etc., to make all the decisions they need. Because they have spent time with their leadership understanding the boundaries they operate within, they can safely make and execute decisions.

Do This: Set Boundaries

While a leader's role is to create and maintain an environment for self-managing teams, we can start by doing something more specific—setting real boundaries. Setting clear boundaries lets the team know what they can and cannot change.

I'm constantly surprised how often teams have to feel out the boundaries that exist, and quietly retreat to a position of "I'll just wait until someone tells me what to do," after getting disciplined for crossing an unknown boundary.

Let me provide a short and incomplete list of areas in which you can set boundaries that come up frequently:

• Project scope
• Important dates and deadlines
• Budget
• Staff
• Tools/technology
• Working with other teams and groups
• Development processes
• Release processes
• Customer/User engagement
• Stakeholders

I'm going to bet that if you read this list and ask yourself, "Am I comfortable with my team having authority over this?" You'll get a quick and sharp confirmation that you really aren't comfortable with the boundaries as they are.

In order to start turning that discomfort into something usable you need to pinpoint why you're uncomfortable. Most of the time it is because you know something they do not. In order to set a boundary you need to tell them what you know, tell them what good is, and tell them what bad is.

So few leaders take the time to do these things. The punishment is constant intervention and crises to manage.

Follow-Up

After you set some boundaries, find time with the team to check in on how they're doing with their new authority and how well they can operate within them.

Be patient. Many teams are conditioned to believe that they will be reprimanded if they try to make a decision.

You can even walk through hypotheticals with them so their understanding of the boundaries matches yours.

Encourage them to stretch into their new authority, and as your trust grows together, you'll be able to expand the areas in which your team self-manages.

Sincerely,

Ryan