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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…