Organizing a company

A few days ago I wrote a post about organizing a dev team.

It was not properly written, for it does not properly reflect my views, in part by being too brief and in part because I was in effect writing about a compromse (a dysfunctional compromise) which was in my head at the time due to the situation at work.

I need then to write properly that which I think, otherwise I look like I’m talking what I think is partially rubbish.

1. Software engineers must be physically removed from the office. They must work at home, or in an office which has *just them* in. No other developers, no one else from the company, no other people at all. Distraction is death to software engineering productivity, and an office is no different to being in a disco. This is an order of magnitude effect. Developers come into the office for one day each week, to maintain relationships. One day per week is the minimum contact rate for humans to maintain close relationships.

2. Contact with developers is either through email, real-time typing, voice, or group voice. Some conversations are best in email, others best in voice; meetings often need group voice. I have yet to see any need for people to be physically together, other than for maintain relationship (and this will be with people who are not otherwise contacted during the week).

3. The company cannot organize itself into large teams (sales, IT, etc) – but rather forms teams, with members from each discipline. Motivation is key to productivity. When software engineers are separated from the users of their work, put into an IT team, they are removed from motivation. This is death to software engineering productivity. Moreover, in a larger sense, any work which is done without input from major components of the company (sales, for example) is fundamentally brain damaged. It’s like trying to be sentient without your right hemisphere.

4. A second profound negative consequence of putting IT into a group and then having it control its own work is that other teams no longer care about the work being done in IT. If a non-IT team controls their own developers (which is not the situation I’m talking about here, but to explain the problem) then if those developers are doing the wrong work, that non-IT team *cares*, because *they* are wasting *their* resource. They incur the opportunity cost. However, people or teams or whatever can only bear an opportunity cost *if they could have directed the effort involved toward something else*. When all the non-IT team can do is submit tickets and someone else decided if they are done, that non-IT team no longer bears any opportunity costs, *because they have no capability to redirect the effort expended to other things*. If something is done for them, well, that’s nice! and because they cannot bear an opportunity cost, they are fundamentally and profoundly less interested in the work being done and ensuring it goes correctly. Bearing opporunity costs is VITAL to productivity, because it is this and this alone which makes people direct effort towards the tasks which actually matter.

5. The closer someone is to something, the better they know it. The higher up the (management) hierarchy you go, the less they know what’s actually needed and the more oblivious they are to the unintended consequences (let alone the intended consequences!) of their actions. Small cross-discipline teams are close to the task and motivated; they are the smallest team necessary which possesses all the skills necessary to move from nothing to completion. Management as such no longer exists; rather, staff members with knowledge of the larger business environment are members on these teams. The IT work done also includes maintaining systems after they are created.

6. All members of a given discipline should be in event-driven communication with each other. Not regular meetings – i.e. polling – it’s inefficient and needless. People know when they need something from someone else, and people know when something has happened they need to tell other people about. *Regular* meetings are senseless – they have a profound impact on productivity (scratch that half of the day) and they are not needed.