Someone ask the other day: how should a organization be designed?
There are two potential answers, which actually aren’t as contradictory as they look at first site.
The first is very simple: Don’t.
That is, don’t design your organization, don’t set out an organizational chart, don’t set out a plan and aim to restructure your organization to that plan.
Rather create the conditions to let a structure emerge.
I suppose its the difference between “design” meaning “create a plan for the way you want things to be” and “design” meaning “the way things are arranged.” To differentiate them the first might be called “intentional design” and the latter “emergent design.”
That does not necessarily imply all emergent structures are good. As we see in code sometimes emergent designs are not always the best and over time they need refactoring. Which implies at some point there needs to be intentional design.
Put it like this: I’d rather your organization pulls the design rather than you push a design on the organization.
Organizational structure is itself a function of business strategy. And both need to be part emergent and part intentional. Although you might have noticed I tend towards emergent while most of the world tends towards intentional!
Thus it helps to have a reference model of how you think the organization should be, maybe something to steer the organization towards.
So the second answer to the question would be longer:
- Create standing delivery teams which are embedded in the business line itself. This is sometimes call stream teams, or stream based development, or “teams aligned to the value stream”, or several other names I can’t think of just now.
- Each business line is itself a stream of work and digital delivery teams support that work.
- Teams contain all the skills and authority to do the work that is required for that business stream.
- The team is part of the stream so the business/technical divide should dissolve. Something I call BusTech.
- Teams are value seeking and value creating: the team seeks opportunities to create value for the business and delivers on the most valuable ones.
- Devolve authority to the teams whenever you can. Teams are mini-businesses. (Notice I deliberately don’t use the word empowerment.)
- Teams grow when the business is successful and more digital capability is needed. And teams shrink when money is tight or less capability is needed.
- Teams may split (Amoeba style) from time to time. New teams may be in the same business line (addressing another question) or part of another, possibly new, business line.
- Active – or Agile – Portfolio Management sits on top to monitor progress, provide extra resources, remove resources, etc. There may even be multiple portfolio processes, one at the business line level and perhaps one above multiple business lines.
- Minimally Viable Teams are started to explore new initiatives, sometimes these go on to be full standing teams but they may also be dissolved if the idea doesn’t validate.
- Seek to minimize common services between teams because these create bottlenecks, conflicts and delays. Each team should stand alone. This may mean some duplication, and therefore some extra costs, but accept that. Once you have your model working you can fine tune such things later.
- Don’t worry about planning and synchronization between teams to much, worry more about getting the teams to release more often and deal with synchronization issues when they become a problem.
They are the main points at any rate.
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Organizational structure in the Digital and Agile age Opinions expressed by Java Code Geeks contributors are their own. |
