The Difference between Self-Management and Self-Organization

This is the second slice of the four-part series on Self-Management. The first article describes what is self-management. The third article focuses on how to apply self-management. The fourth article shares the challenges in moving toward self-management.  This second article discusses the difference between self-organization and self-management. 

Why write an article on the difference between self-organization and self-management?  The main reason is that many people conflate the two words and concepts when, in fact, they mean two very different things.

Within a self-organizing structure, teams own the 'how' to do the work, along with deciding 'who' does the work within the team.  You will often find the self-organizing concept applied to an Agile environment, where the Product owner owns the priority of the work (aka, the ‘what’) and the team owns the 'how' and 'who’. 

In a self-managed structure, employees own the ‘how’ and who, along with the 'what' to work on.  The ‘what’ means that employees prioritize the work activities.  In each cases, there is the mission level 'what' and 'why' for the organization defined by the leaders of the company that both must align with.  

In self-management, employees own much more than the work activities at hand.  They own the priority of the work, the overall planning, management of their own budget, and HR aspects like compensation and staffing.  This also includes the team deciding who is on the team or how the team is structured.  None of this occurs in self-organization teams.  It is just limited to the ‘how’ and ‘who’ owned by the team while the Product Owner (or Manager) defines the overall planning and priority of the work and the manager handles the HR aspects of the work.   

It is easier to apply self-organization to teams (compared to self-management) as the ‘who’ and ‘how’ are typically activities within the team boundary (working with just other team members).  Self-management activities extend beyond the team to areas like working with HR, finance, and more.    

For those interested in self-management, it is recommended to understand and attempt self-organization first.  If your business is ready for you to both own the ‘how’ to do the work and ‘who’ should do the work, then self-management may be considered.  If there is still resistance to these aspects of self-organization such as project management or managers continuing to decide who does what, then this hurdle must be resolved before attempting self-management.

--> To read the first article in this Self-Management series, see: What is Self-Management and is it good for Agile? 

Bounded Authority in an Agile World

Much is written about self-organization in an Agile world.  For some, the notion of self-organizing teams scares folks.  Does this mean that a team can decide everything?  Of course, the short answer is no.  I suggest the concern is due to not having boundaries for self-organization.  I call the framework for this context, bounded authority.  Bounded authority is defined by the information, experience, and decisions a group has control over within their context. Within a hierarchical structure of a company, bounded authority can work at multiple levels.  For simplicity, let us focus on the team level, middle management level, and senior management level. 

First, let’s spend a few minutes to explore what self organization means.  A self organizing team is a group of motivated individuals who have a common purpose, owns their work, and has the authority to make decisions on the work they are doing.  This means they can decide how to do the work (e.g., how to build the widget) and who will do the work (e.g., not assigned by a manager).  

Within an Agile context, the goal is to push decision making to the level in which the most information and experience dwells.  For a Scrum team, they self organize around the work in the product backlog that has been prioritized by the Product Owner.  Once that work is available at the team level, the team has the authority to make architecture, design, programming, and coding decisions and can self-organize around the work.

So if the team’s work is defined within the product backlog, what does middle management do?  Can they assign work to the team?  The short answer is that this is not within the bounded authority for the middle management since the team gets their work from the product backlog.  While the team self-organizes around the work, middle management helps optimize flow for their teams and enables the team to be its most effective. By optimizing flow for their organization and teams, this includes removing impediments for their teams to enable them to work faster.   Middle Management may also focus on helping their teams with their career management goals. 

Above the middle management are the senior management (or executives).  Should they be reaching down and telling the teams how to build the product?  To answer this question, another question should be answered.  Does senior management have more knowledge and experience in how something should be built or is this knowledge most known at the team level?  While the answer is the latter (team level), senior management has a bounded authority and duty to provide a strategy for the organization. This means they must help the teams understand the strategy and help them align strategy with their work.

Another example of bounded authority is relating it to your requirements hierarchy.  Consider who has the authority over the strategy, who has the authority over the ideas, who has the authority over the user stories.  This could be senior management who makes the decision to decide the top strategies, the chief product owners who makes the decision on prioritizing the ideas, the product owner who owns the decision to prioritize the backlog, and the and team who makes the decision on how to self-organize around the user stories.   

The key to bounded authority is that each level knows what they can self-organize around, what they have the authority to change, and areas in which they can make decisions.  Within an Agile context, that level of ownership and decision-making should be pushed down to the lowest possible level.  This can be an exercise that occurs at both the senior management and middle management levels, and in all levels within an organization.