Skip to content

The company as a social engine

So why is everything so complicated? At work, I mean.

Think of a small company. A single person, a founder, is building her business. She knows her way around, it’s all in her head: The plan, the things that are important and why, and how they are to be executed. Also, tradeoffs to be corrected later, potential opportunities for later and a lot of other meta: Stuff that does not get executed right now, but that informs decisions, priorities and preferences. Things work with some precision, though, like a well programmed wetware CPU.

The moment that stuff becomes too large for a single person to handle, more people are involved and things need to be verbalized, written down, given form.

At that point, things change quite a bit:

The task at hand is to program a second CPU, wetware, with a part of the program that the first person has been executing. That’s necessary so she can delegate, and the entire operation can scale.

Unfortunately, as with all remote procedure call mechanisms, complicated unfolded in-memory structures have to serialized before the can be marshalled off to a second node and are being re-instantiated over there. In this particular case, the language to describe the code to be executed is informally specified, too, and the remote CPU also does not match the specs of the first CPU, that is, English is really bad for programming computers or people, and also each person is different.

To make matters worse there is no proper debugger, the same broken language has to be used to printf-debug the remote (“Do you understand what I mean?” “Do you understand why it is important that we do things this way?”) and there may be other, older code in the remote that interferes with the execution of our code. People have history and they have ideas.

If you think of a company as a large distributed engine to execute code that has been extracted painfully and incompletely from the wetware engine of a founder, and which has been mangled due to improper serialization in a language with limited expressiveness, you have a good idea of the corporate environment.

You can’t see what happens in the individual nodes, you can only observe the communication between them, and the parts of the program that made it into writing, or at least the Wiki.

You can think of processes as written down instructions for the engine: Any process (“buy more paperclips”) describes who needs to talk to whom, about what and why, in order to make things happen (“You need to create a purchase order, which needs to be signed by X for values over n EUR in order to limit our liability. The signed order is then sent to Z, who will actually spend money to buy stuff. You get stuff, and sign here to document that.”)

Writing instructions and process down is important, and a great improvement actually, because writing these instructions down forces all involves parties (including the founders) to come clear about all the details and the meta about the details – things that might have been existing only vaguely in some mind, previously, now have to get a precise shape.

Also, they become tangible, and by the way of tangibility, they are open to challenge, discussion and modification – which is why some founders are actually resisting to give tangible form to certain things.

Giving tangible shape to instructions and the meta – why instructions, why these instructions, why these instructions in this order with these emphasis – is a complicated, painful and slow process, precisely because the originator of an idea – the founder or some other person with an idea – has to give up the idea and let it out into the world, where it will be subjected to change by others. Loss of control is always violent and painful, and as with any new thing given a permanent form, there is always negotiation about the details. Giving birth to anything: It’s exhausting.

It’s not a one step process. A founder has an idea and a plan, but in many parts it is still early, untested and vague. They put things into words, and the words are being tried out – can we work by these instructions, or are there things unclear? Can the instructions work, or does the plan need change? Can it be improved? Can it be applied to other, similar things?

Iterations happen. Do we go deep or wide – do we specialize and improve this application of a plan, or do we try to apply the plan as is to as many things as possible first? Again, negotiation, and consequently, exhaustion.

So why is everything so complicated? Because companies are broken. All of them.

Their engine, their program, their processes, are magnifications of the mind of the founder or other influential people at the top. The entire corporate mechanism is built to do exactly this. And with this mechanism not only the original idea is being magnified and copied to many minds, but other aspects of the original mind are, too. And because the source was a person, with flaws, they too, are being magnified and multiplied.

Do you like it around here? Well, that’s because like all corporate environments, this one is broken, too. It just so happens that the breakage around here is more compatible with your own flaws than elsewhere.

Yes, your work environment sucks. They all do. Find the one that sucks in a way that suits your needs.

Published inWork

3 Comments

  1. This is why it is important to have your business processes defined in a suitable manner. In the same way that UML can help with programming, BPNM or similar modeling languages can help with understanding and optimizing business processes.

  2. Martin

    In order to work in a company, you need to learn two things:

    1) Accept, that you always have to follow the process
    2) Know, when not to follow the process

    You need to have learnt 1) by heart in order to learn 2).

Leave a Reply

Your email address will not be published. Required fields are marked *