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:
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?
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.
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.
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 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
Post a Comment