I built my first organisation when I was in high school. It was a debate club, and it died the instant I graduated and left for university. I remember looking back on the experience and thinking to myself: “Hmm, this is interesting. How do you build an org that outlasts you?”

About two years later I built a hacker club in uni. This one went better. I stuck around long enough to set up succession, and then retired from the presidentship to see if things held up. They did. These processes weren’t just mine, of course — I went to a lot of people for advice, and my team had plenty of ideas of their own. We tested those ideas as a collective. Then we recruited two generations of new people, handed the systems over to them, and left.

A number of years after we graduated, I came back to talk to some of the current members. “How’s the club?” I asked.

“It’s good,” they answered. I could tell; in the years since we’d graduated, the NUS Hackers had only grown in reputation and status. If you ran a software company in Singapore, for instance, and you wanted to hire the best software engineers from its top university, it was likely that you would recruit from the club’s membership. Or so it seemed from the outside. After a bit of back and forth, I asked them about the other student orgs in the university — the ‘competition’, if you will. “Oh, there are a few new ones since your generation left. But they might not last after the current batch graduates. They’re not as strong as we are. We have the better culture.”

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.

I remember thinking that this was a neat outcome — that I had done better with the NUS Hackers as compared to my debate club. Then I went to Vietnam to run a software engineering office for a Singaporean company, and did it all over again. By the time I was done, I trained three managers to replace me, and handed them a set of interlocking systems that took care of hiring, training, perf evaluations and promotions. It’s worked well — today, around 70% of the people I hired remain at the company; revenues have more than doubled since I left. Right before I went off to start my own thing, my boss told me that the biggest lift I’d done for him was to set up the structure on the Vietnam side of things.

“I think you have something rather rare”, he said.

“I know,” I replied. “I like org design. And I think I’m pretty good at it.”

But I didn’t know how to explain what I did.

I don’t want to mislead you: I’m not world class at org design. I grade myself as a B- to a B+, depending on the context. If you want an example of what an A+ org designer looks like, read Working Backwards.

What I do have, however, is a journeyman’s understanding of the skill. I know when someone is better at it than I am, I know how to recognise the contours of their skill, and I know what bits of my own skill to improve. What I hope to do with this piece is give you a sense of what org design looks like in practice. I believe that if you know the shape of the skill, you should be able to:

I should note that this is a first attempt at articulating a tacit skill. I’m likely to get this initial formulation partially wrong. A couple of years ago, one of the more recent presidents of the NUS Hackers reached out to me. We had dinner together, and he asked: “How did you do it? Or more importantly, how do you get good at org design?” And I said: “I don’t know. I just did what felt right.”

Doing what ‘feels right’ is a marker of expertise. And I realised a few weeks ago that — given my recent history of digging into tacit knowledge — I now have a loose toolbox for getting at what’s inside my head. So here goes.

Organisational design is a design problem. Like all design problems, the nature of the problem is a search for form-context fit.

In other words, you are attempting to find some ‘form’ (an org ‘shape’, or a combination of systems, processes, and culture) that allows you to achieve some set of goals, given the specific constraints in which the org operates (the ‘context’).

The key difficulty with this task is that organisations are complex adaptive systems — meaning that they consist of individual humans responding to a messy combination of social, cultural, and economic system incentives. Their individual responses to those incentives will themselves create new org dynamics that you have to deal with. 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.

The other difficulty is that you must prevent the org from getting into a dysfunctional state. It is very difficult to undo bad culture — far more than it is to shape good culture. So it's best to avoid it altogether. This in turn means that you have to constantly be on the lookout for nascent bad behaviour, in order to nip it in the bud before it becomes too bad.

What I’m trying to say here is that org design is a skill of effective iteration. We’ll talk more about this in a bit.

Before we do so, we need to talk about ‘context’. It’s easy to say “oh, org design is a problem of finding form-context fit.” But what does context mean in this sentence?

I suppose one way of describing context is ‘whatever organisational constraints you have to solve for’, but this isn’t particularly helpful. The truth is that I’ve left the word deliberately vague, because what it means depends on the (ahem) context you’re in. Obviously context includes the organisational behaviours and goals you want to induce. But it also includes non-obvious things like the business model you run (if you are a company), or the systems your organisation has to interface with (if you are a university club). To some degree, the context you’re in will limit the set of organisational forms you may design.

I’ll give you two examples to illustrate.

Let’s say that you’re running an outsourcing company. You build apps for clients, so you find clients, hire developers, get those developers to build apps for the clients, and then the clients pay you for the time you spend building those apps. If you tell me you want to build an org that prioritises developer skill progression, and you show me a promotion ladder that is 12 levels deep, I would tell you that your org design would be greatly constrained by the business model you’re in, and that you would fail.

This is not obvious to a novice operator. It is especially not obvious to someone who has never run an outsourcing company before.

Why is this the case? Well, David Maister lays out some of the background constraints in Managing the Professional Service Firm, which I covered in The Consulting Business Model. To summarise broadly, there are three types of services work:

The nature of this context is that, if you are running a firm with mostly procedure projects (as is the case with an outsourcing company) you would need to keep your labour mix heavily tilted towards lower skilled, junior employees. Your business model simply cannot support having a large chunk of mid-career or senior people. So trying to pretend that the business model doesn’t affect your org design — that you can somehow get a 12-level promotion plan (the ‘form’) to work with the reality of the consulting business model (the ‘context’) — is wilful ignorance of the nature of the business.

(It’s a bit difficult to articulate why it wouldn’t work in so few words; I recommend reading the full post on consulting business models if you still do not understand the dynamics of a consulting company. Suffice to say, staff development is not compatible with Procedure-only consulting firms; you’ll need to move up to Grey-Hair-type work for a shot at it working).

Here’s a second example. When attempting to build a university club that outlasts one generation of students, you would need to deal with:

Anyone who is familiar with the NUS Hackers would know that we solved for each of these constraints over the course of my time with the club. But the generalisable idea is simple: as you iterate to find form-context fit, you uncover new features of the context that are not immediately obvious to a novice in the domain. (For instance, it was not obvious that we could solve the funding issue when I first started building the club — but once we figured out how to get the government to fund it, it unlocked a larger range of organisational forms that could succeed).

My overarching point: in practice, form-context fit is a dynamic thing; you are varying the form of the org to fit the context, but your understanding of the context usually improves over time. This is the nature of designing in the real world.

Let’s get to the heart of this skill, then. If the art of org design is essentially effective iteration towards form-context fit, what does that iteration consist of?

To my knowledge, you need four sub-skills to do effective iteration:

Getting better at org design is in many ways getting better at each of these sub-skills. We’ll examine each of these skills in turn.

I have never met an org designer who is bad with people.

People skills are necessary for two reasons: first, you need to have a working model of the people who make up your org, in order to predict how they might react to org changes (which is skill number 2, above). Second, being good with people means that you are able to get your org changes to take (this is skill number 4, above). In practice, this looks like an ability to predict which people might resist the org change, and how, and therefore allows you to do targeted interventions to prevent such resistance from occurring.

Systems thinking means a particular thing here: you are able to predict how people are going to respond to incentives.

I mean incentives broadly: there are psychological and status incentives, created by the structure of your org and the people in it, and there are also economic incentives, that fall out of your promotion and compensation policies. Good org designers are able to model how changes to these structures and policies might play out. This doesn’t mean that they have perfect prediction — we're dealing with a complex adaptive system, after all — but it does mean that when a new org behaviour emerges, perhaps as a result of some policy change made months in the past, they are able to notice the behaviour and know how to act on it (either by reinforcing it or changing it).

This is, incidentally, a key behaviour that good org designers focus on. Organisations have memory — if an org gets into a dysfunctional state, the dynamics can be ridiculously difficult to reverse. So one aspect of org design is to notice when such regressions are happening, and to fix it — or, if not immediately possible — to keep track of the regression before it becomes too painful to undo.

In High Output Management, Andy Grove argues that there are really only three forms of organisational control:

These three forms of organisational control make up the org design toolbox. Grove presents the following illustration in HOM, and then writes:

The corollary to Grove’s observation is that org designers must choose between economic incentives, structural and policy changes, or culture when they want to shape organisational behaviour. Picking the right tool for the job is a bit of an art.

I’ll give you an example. At one point when I was running the Vietnam office, I realised that I had inherited a distinctively bro culture — a culture of lewd jokes and sexist remarks. I realised that if we wanted to hire women, we would have to change the culture. (To be fair, this was in Vietnam, with very different cultural mores, but it made no difference to my goals).

How should I change this behaviour? I could have introduced an economic incentive (implement a fine for every lewd joke, or make it part of the conditions for promotion). I could have introduced a new policy (no more lewd jokes, or else!) Or I could use the subtle influence of culture. I decided on the latter.

During a morning standup, I explained that many of us wanted more women in the company (which was true) and that one thing that made this difficult to do was that we had a culture that made women uncomfortable (probably true, though it was more complex than that). I told my team that going forward, we were not allowed to make lewd jokes, or even share sexist memes. Then I watched the company chat for the inevitable slip-up. My response to the few slip-ups over the next month were simple: I would reply to the message with a ‘not cool’. And I may have engineered a situation where I made a sexist joke in front of the entire office, stopped, called myself out very seriously, apologised, and then moved on. My goal was to make a very public example of myself. This is not a general recommendation, by the way — more something I thought would work in the context.

I was right — it took only a month for the new behaviour to take.

This leads us to the final sub-skill: you need to know how to get org changes to take for your particular org.

Getting new org changes to take can be rather tricky. I can spend a whole blog post writing about this single skill — and I acknowledge that I’m not even very good at it. But to sort of give you a taste for what this looks like, I’ll walk you through a number of challenges that good org designers know to navigate.

For starters, if you introduce a big org change and screw up the initial implementation, the org may collectively reject the change … forever. (“Yeah, we tried that. It didn’t work. We’re never doing that again.”)

Figuring out a way to avoid this dynamic is a huge chunk of the skill.

When I was running the hacker club, my nickname amongst coreteam members was ‘cat herder’. This was actually quite accurate — if I wanted to introduce an org change, I knew exactly who in the team would protest the change, how they might register their protest, and therefore how I might nullify their opposition. (I should note that I used this power judiciously — obviously this was a two-way street; coreteam members could just as often change my opinion. I’m just stating it like this because I knew I had an ability to push changes through — and any org designer would say the same; I could do this either by changing their opinion, or moulding the majority opinion to go over them — basically, I was herding cats).

Often, I would only institute some change after laying the seeds for consensus weeks or months in advance.

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:

I would also take extra time doing 1-on-1s right after we introduced a change. I learnt this the hard way: after introducing a new task estimation process, I did no check-ins for a couple of weeks. Then I learnt, in the following month's 1-on-1s, that multiple employees were unhappy with the way the implementation was playing out, and I was at risk of having total process rejection. I spent the good part of the next three weeks tweaking the process to save it.

All of this, I might add, was mostly intuitive; I had, by then, a good grasp of the org dynamics of my company.

I don’t think I’m particularly skilled at this. I believe that I was just good enough for the context that I found myself in. To a certain extent, this skill overlaps with org politics, and I’m sure others are better at playing organisational politics than I ever was — just as I'm aware that navigating org politics is a bigger thing in larger companies.

And of course I’ve gotten a huge amount of value from other org design experts. Here’s John Cutler, for instance, who has a useful framework for experimentation (read: introducing new org changes) here:

Cutler’s activity forces teams to pick experiments that are safer first, before gradually iterating towards changes that are more disruptive to the company (that is, ticks more boxes to the right side of the diagram above as opposed to the left side).

Cutler is an expert at org setups; I’d defer to him whenever possible.

Now that I’ve laid out the shape of the skill, we may ask a more interesting question: what do great org-designers look like? Or, stated differently: what does the skill look like at the very edges of competency?

Here are a couple of factors I’ve been watching over the past decade:

Scale. In general, the larger the organisation, the more difficult the org design. This is for a few reasons:

Because the difficulty of org design increases with scale, org designers who are able to create reasonably effective organisations at scale are more skillful than org designers who have not yet done so.

On this note, I have only designed orgs in the 30-50 person range. I am not yet believable when it comes to larger orgs, and this is an indication of the limits of my skill.

More difficult contexts. Some org-design contexts are more difficult than others. Arguably, designing a university club is easier than designing a company — for with a company you are interacting with a capital environment and a marketplace.

One of the reasons I find Amazon’s Working Backwards so wonderful is that it is an example of org design for a particularly difficult context: that of a decentralised organisation designed to create business value through new business origination, not acquisition. This is a notoriously difficult game, and Working Backwards is the story of the iteration that Bezos and company underwent to arrive at their current org setup.

There are other difficult contexts. For instance:

As you might imagine, the more challenging the context, the more difficult the org design.

Managing larger, more challenging tensions. One of the most difficult things about building successful organisations is that all sufficiently large orgs are broken in some terrible way, and that brokenness can come back to haunt you. The way that orgs get broken is that every design choice you make exploits some inescapable organisational tension. Pushing the tension in one direction tends to result in a dysfunction in the other direction … and pushing is usually required to achieve form-context fit. The key challenge is to live with some set of acceptable dysfunctions — which in large companies, can be quite difficult to swallow.

This is pretty much what every org designer feels. At smaller scales it’s usually manageable — I know that my previous orgs continue to reflect my values, and therefore my failures. And I’ve mostly made peace with that.

Good org designers, however, are more likely to deal with larger organisations, which in turn means that the dysfunctions and brokenness of their designs scales up to ridiculous proportions. Nobody is really harmed if my tiny company fails to recruit women effectively. Lots of people are harmed if Amazon hires them to work in under-ventilated warehouses.

At the higher levels of the skill, good org design demands the ability to live with such dysfunctions. You can fix some of your org’s problems, but there will always be more.

Now that we’ve talked about the shape of the skill, we may discuss a number of second order implications.

Here’s one: it is not awfully important to study abstract incentive design, or to study theoretical treatments of Goodhart’s Law, because in truth, these are avoidable in an iterative process. No, if you want to get good at org design, your time is better spent building more accurate models of the people in your org, in learning how they respond to incentives, and in building enough power and credibility to get your org changes to take.

A second implication is this: anyone who gloms onto some organisational framework without consideration for the context they operate in should be regarded as bad at org design. I was completely unsurprised when Medium and Zappos announced that their implementations of Holacracy had failed. Because of course it would fail — Holacracy is an organisational form with no consideration for context.

A third, related implication is that adoption of org processes should always take the step-by-step iteration process into account. Or to put that another way — when you are reading about Agile, or Scrum, or Shape Up, or some other business process, you should never think of it as a system to be adopted wholesale; you should always think “hmm, this is a set of tools that seem to work for some context; how do I know this works for mine?” And then you should break those processes down to atomised pieces, and apply them by running smaller, more iterative tests.

Consequently, anyone who tries to shove some org process down your throat with no thought for your business’s context is probably a novice at org design. You can sort of see a pattern here: those with some experience of org design know that they cannot perfectly predict organisational behaviour in response to their changes, so they iterate. Those who aren’t good at the skill think that they can get there through mechanistic adoption alone. Distrust the latter whenever possible.

The final implication of this essay is that stories of organisational processes are more important than descriptive how-tos of the process. A novice would read Working Backwards or Netflix’s No Rules Rules as “Ahh, here are a handful of mechanisms these successful organisations used to become successful! If I adopt them in my org, I, too, will be successful.”

But this is naive.

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.

If there’s one thing that you take away from this piece, let it be that.

Source: Commoncog.com

Powered by NewsAPI.org