The Skill of Org Design
TL;DR:
- Орг дизайн - это итерационное действие направленное на выживание организации после ухода создателя.
- Для мастерства в орг дизайне необходима - хорошая [[коммуникация]], системное мышление, выбор правильного инструмента и создание минимального инкремента для заселения новых процессов.
- При создание орг дизайна всегда стоит учитывать контекст, потому что нет решений one-size-fits-all.
An experienced org designer would read them for the stories of how those companies got to those mechanisms in the first place. The story of the iterative process is more revealing than a simple description of the mechanisms, because it tells us the context. Understanding the context is usually key to understanding if the processes have a shot at working when applied to your company.
More difficult contexts. Some org-design contexts are more difficult than others. Arguably, designing a university club is easier than designing a company — with a company, you are interacting with a capital environment and a marketplace.
Scale. In general, the larger the organisation, the more difficult the org design. This is for a few reasons:
- It becomes harder to model the median member of the org, thanks to increased size.
- It becomes harder to observe changes in organisational behaviour in response to policy changes.
- Things take slower to spread, which means that bad org dynamics can fester for longer.
- There are more moving parts, making the act of introducing a new org change more difficult to do (and depending on the org, more politically fraught).
This approach isn’t generalisable, of course. When running the Vietnam office, we had many other business-related problems to deal with; building consensus wasn’t something that I always had the time to do. So the way I ran certain org changes was to:
- Get a sense for team receptivity for that org change, balanced against the necessity of the org change. If I sensed that the team would be resistant to the change, I would:
- Figure out how much I had left in the ‘credibility/trust’ bank, and if I wanted to burn that capital.
- If possible, find a smaller, more reversible version of the org change to introduce first.
- Use disasters to my full advantage (people are usually more receptive to trying new ways of doing things in the wake of something painful).
- Strategically allow certain things to blow up so that I could exploit the pain to introduce org change, as per 4) above.
- Or build consensus; consensus was always the best, if most time consuming, option.
To my knowledge, you need four sub-skills to do effective iteration:
- You have to be good with people. More precisely: you must have a good model of the people inside the org.
- You have the ability to think in systems. In the context of org design, what this means is that you have some ability to predict how changes in your org affects the behaviour of its members. (This ability doesn’t have to be perfectly accurate, of course. That’s what the iteration is for.)
- You have a decent understanding of the three modes of organisational control and how they interact with each other. When I say ‘modes of control’ I am using terminology from the late Intel CEO Andy Grove; these are a) economic incentives, b) ‘contractual’ obligations, and c) culture. These three tools make up your org design toolbox.
- Finally, you should have the ability to introduce changes in the org, and you should know how to get them to take.
To summarise broadly, there are three types of services work:
- Brain projects — projects that are novel, at the forefront of professional or technical knowledge. Think: legal cases like the Microsoft antitrust suit, or custom, high-value architecture projects like the Sydney Opera House.
- Grey Hair projects — projects that may require a bit of customisation, but have been done repeatedly by the consulting company. Examples include cost cutting engagements by McKinsey or market analysis projects by Bain.
- Procedure projects — these are the lowest value form of consulting work, and are usually executed not because the client company can’t hire to do it in-house, but that it doesn’t want to (perhaps for efficiency or political reasons). Think: a company outsourcing development of an app, or outsourcing ad buys to an agency.
As a result, you cannot predict how the humans in your organisation will react to your changes — not with perfect accuracy, at least. So the nature of org design demands that you iterate — that you introduce some set of changes, watch how those changes ripple out in organisational behaviour, and then either roll-back the change, or tweak in response to those observations.
I grinned at that. I grinned because it meant that the systems we designed worked. Better still, the alumni network we’d set up was still somewhat intact, which allowed me to do the checkup in the first place. A member from my generation, Rahul, created what we termed ‘Rahul’s Rule’ — that alumni should not interfere with current club affairs, unless the club was existentially threatened. The rule created a clear demarcation between current members and past members, which helped with org autonomy. And so today, while we still take coreteam referrals seriously (if, for instance, someone was moving to Silicon Valley or to London or back to Singapore and wanted a warm intro to a company), the club continues to function, and alumni have mostly moved on with our lives.
Link:: https://commoncog.com/org-design-skill/