DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • Essential Steps to Building a Robust Cybersecurity Team
  • Revolutionizing Financial Monitoring: Building a Team Dashboard With OpenObserve
  • The Modern Data Stack Is Overrated — Here’s What Works
  • Platform Engineering for Cloud Teams

Trending

  • Scrum Smarter, Not Louder: AI Prompts Every Developer Should Steal
  • Continuous Quality Engineering: The Convergence of CI/CD, Chaos Testing, and AI-Powered Test Orchestration
  • 10 Predictions Shaping the Future of Web Data Extraction Services
  • Microservices for Machine Learning

Self-organizing, Self-directing, Self-managing, and Authority

The differences between self-organizing, self-directed, and self-managed team in an agile environment.

By 
Allan Kelly user avatar
Allan Kelly
DZone Core CORE ·
Sep. 24, 15 · Opinion
Likes (1)
Comment
Save
Tweet
Share
8.0K Views

Join the DZone community and get the full member experience.

Join For Free

Quick as a flash Eben Halford on Twitter pointed out the mistake with my last blog (Question for self-organizing teams). I was mixing up self-organizing teams with self-directing teams. Well maybe I was… much of my post still stands either way, and as Eben himself pointed out, we might be trying to split a hair here.

Frankly, I suspect many people think the whole “self-organizing team” thing is one-size. The idea that there are actually “self-organizing” and “self-directed” and possibly “self-managing” hasn’t occurred to most people and, if they have noticed, they don’t know the difference. In fact, I’m not sure I know the difference!

If you take time to look at some of the literature on self-organizing/directing teams you find that very little of the pre-agile stuff talks about self-organizing teams, rather the common term in management literature is self-managing teams, most of the serious research relates to this rather than the (to my mind) weaker idea of self-organization.

To untangle this mess lets define a hierarchy here:

  • A self-organizing team is a team where team members get to decide among themselves who does what, the team gets to work on problems and have some power to remove their own blockages. Clearly there are teams who are more self-organizing than others and teams which have more authority than others.
  • In a self-managing team there is no active day-to-day management of the team. The team are effectively left to manage their own work. To my mind this is a stronger form of self-organizing.
  • A self-directed team is a team which sets its own goals, decides its own objectives and determines its own priorities.

Does anyone know of any serious literature (i.e. research led) which defines these terms better? I’d love to have some better, clear, more well defined, separation.

Clearly some, but not all, of the questions I posed in my last blog relate to self-directed teams rather than mere self-organizing teams.

But while I have, belatedly, made this distinction it seems to me that not everyone does. It seems to me that making this distinction would help by removing a lot of the confusion that sounds self-organizing teams. And making this distinction would actually help with the questions I posed in the last blog post because teams and their managers would be able to draw lines and discuss where authority and responsibilities lie.

You see, one of the problems with labels, especially labels like self-organanizing teams, is that they mean different things to different people. Indeed different authors define them differently.

It is because of this confusion that I prefer to avoid using these labels and prefer to leave the idea of self-organizing teams alone.

Instead I prefer to talk about authority, I want team members and teams, however they are organized and managed, to be given authority. Sometimes authority is vested in the team members equally, so for example each member has the authority to make a decision. In other case authority is vested in the collective team, in that case as long as the team can agree a decision they can make it,

In other cases authority is vested in specific individual team members. This usually occurs where specialist skills or knowledge are needed. The Product Owner role is a great example here: product owners need to have the authority to make decisions on prioritisation, they need authority to make trade-offs and make compromises. The more authority you give the product owner the better they can do their job.

I want teams and individuals to have authority for two reasons. I believe the soft, fuzzy, reason that is usually sighted: people get more satisfaction from work when they have autonomy (i.e. they can make their own decisions) and thus are more motivated and more engaged as workers.

The second reason is very hard, not fuzzy: when developing software there are thousands of decisions that need to be made. Many of the decisions require specialist knowledge and the people with the greatest knowledge, both of the technology and the situation in hand right now, are the people doing the work. The testers and programmers at the code face have more information about what needs to be decided than anyone else.

Pushing decisions down to the lowest level means decision making can be made more efficiently, i.e. in a more timely fashion. But in order to do that the workers need authority.

Now notice I’m saying authority, I’m deliberately avoiding the word “empowerment.” Empowerment is a horrid word and it describes a horrid concept. Don’t talk to me about empowerment, its nasty.

On that cliff hanger, if you want to know why I don’t like empowerment, well tune in next time, the post is already drafted.

teams

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Essential Steps to Building a Robust Cybersecurity Team
  • Revolutionizing Financial Monitoring: Building a Team Dashboard With OpenObserve
  • The Modern Data Stack Is Overrated — Here’s What Works
  • Platform Engineering for Cloud Teams

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: