Skip to main content

The Good Silo -- Servant Leadership, Self-Organization and Yes, Old Fashioned Middle Management

Please be honest.  Does the concept of "self organizing teams" frighten you at all?  Do you picture everyone in your organization trooping into some large room with no chairs and being asked to arrange themselves into color-coded "pods" and then come up with plans for total quality management, preferably presented as a skit with lame props to upper management, who, naturally, will not be participating in the pods in any in-person sort of way?

If you're in charge of an IT organization of, say, 250 people, and you want to really shake things up the way British Telecom did, you would be fully within your rights to ask:  so how do we structure this?  And you should demand an answer from your transformation coach more specific than "well, we'll set up a bunch of collocated self-organizing teams" which is implicitly followed by the silent phrase ("and your middle management will hate it, hate us, and hate you, but mostly hate us, and won't THAT be dramatic??").

I'm going to break a pretty strong agile taboo here and suggest that you just go ahead and set up a new hierarchy.  Yes, that's right.  If you don't already have them, you should hurry to set up old-fashioned line of business silos.  Certainly I'll allow for piloting first and the like, although strictly speaking, I don't think it's necessary.  And certainly, I'll quickly explain why these will be "good" silos, not "bad" silos, if you'll bear with me for a moment.  For now, let's just say that the best way to structure your teams is going to be to start by having everyone focus on the customer.

This structure will naturally create the need for multiple levels of leadership, and give each of your middle managers something quite meaningful to do:
  • Somebody should be on point for each line of business.
  • Everyone else should be organized into a tree structure attached to this person where managers are held responsible for their area of authority, and wherein no manager is responsible for more than 10 people.  Really, six would be optimal.
  • The nodes of the hierarchy should be project teams working off of a shared program backlog for the whole line of business.
That's it, you're done with the hierarchy.  But now comes the hard part:  servant leadership and, yes, self-organization.

When you publish your org chart, borrowing from the Swedish as is so often the case, you are going publish it upside-down, at least philosophically, or even literally as this Houston, TX, construction firm does:


As symbolized by the chart, you will start your agile improvements by recognizing that the most important people in your organization are the project team members who are delivering the software to your customers.  This transaction is the reason your company is in business.  These teams are cross-functional and self-organizing, once they are set up, and through their interactions directly with customers, they will tell you what you need to do.

Meanwhile, each manager is in place to carry water and remove obstacles for the team above them.  Sure, then as now, as you move further away from the project team level, you will encounter higher salaries and fancier titles, but to some degree, these will now be justified, because you need skills that are harder to find in the marketplace as you move down this chain.  And what are these skills?
  • Monitoring the team for problems and protecting it from bullies, removing them where necessary.  The more points in the hierarchy, the more challenging it is to figure out who the bullies are to remove them.
  • Coaching, including providing salary and bonus related financial incentives to individual team members, based on how well they are working within the structure.
  • Representing the team's actual needs on occasions when attendance by everyone would be a pointless free-for-all.
  • Encouraging and organizing cross-team and cross-boundary meetings at all levels, so that within and across lines of business, the whole corporate structure can take advantage of mutually known best practices to continue to do the best thing for the customer.
The stress in this new structure is on non-cynically using one's authority to consistently tune the individuals and interactions which are the most important part of the agile endeavor, and keeping everyone focused on the customer.

The result of the new structure is that although each line of business has a boundary, the members of these hierarchies are given incentives to work together, within and through their boundaries, to do the best they can for the customer.

Your job, as the owner of the new structure, is to monitor it to ensure that it behaves as though it is upside down, primarily by observing the human interactions which are occurring within it on a day to day basis.

When you hear "servant leadership," you may be even more frightened than you were about self-organization.  Perhaps you think of socialism, or maybe a "rap session" someone made you attend in your youth.  Maybe you flash back to when they tore the desks out of the library at your university and filled it with orange bean bag chairs, and you all started calling it "the Romper Room."  And even though you're super liberal on the political spectrum, or maybe you're not, maybe that scares you.  If so, okay, fine, we're all scared.  But let's get over it and start building some silos.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica