The flat company myth.

I've been wanting to write about my experience starting and runningMetabahn for some time now. Unfortunately, running a software company is very much at odds with absolutely everything else I could do with my time. So, let me catch you up.

Backstory

September of 2007 was a busy month. I left the startup I was working at, started Metabahn, and got engaged; in that order. At this point the company was more a cover for my own consulting work; I wasn't all that interested in growing it.

In March of 2008 I found a project to build a web-based tool that would be resold to major financial institutions. I put a lot of work into landing the project, as I knew it would pay the bills for the next few months and give me at least the illusion of stability. When it came through I knew it was too big to do by myself.

I hired my first contractor and we delivered the project on time. This happened to be the first of many sizable projects that dwarfed the amount of effort I could expend. So I kept hiring contractors to help. Overall I have positive memories of this time. It was the single biggest learning experience I've ever had, filled with success and failure alike.

Version 2.0

2012 rolled around and I was beginning to sense change in the air. If you know me reasonably well you know I don't like to stagnate. The company as it was just didn't seem to be challenging enough. Couple that with the momentum we had built and it felt like the right time to try and build a real company, with realemployees.

GASP.

I reached out to a long-time friend about joining as the first employee. He had contracted with us a couple years prior, and I knew he'd be a good fit for the direction I wanted to take the company. We'd talked about working together again, and it seemed like the right time.

Metabahn 2.0 started in May of 2012 when I made the first hire. Today we're at 2.3 with six employees and roughly the same number of contractors who help us out on a consistent basis. We've been bootstrapped from day one and have taken no outside money. 100% of the company is owned either by myself or other employees.

Flatland

As we hired more folks, I did a lot of thinking about process. My view is if you can't define the problem to solve with a process, don't implement the process. Conversely, if the problem goes away, throw away the process that was being used to solve it. Without these rules you risk becoming bloated, even at a small size.

This led to a really flexible work environment, including flexible hours and unlimited vacation time. To this day, we really only have a single rule:

Don't make decisions that have a negative impact on the team.

Along with this flexibility came the lack of formal organizational structure. It is a fad in the tech industry to have a so-called "flat" company. However, all companies have an implied hierarchy. This is evident when there's a decision to be made.

Let's say some member of the team makes a product decision that causes a negative experience for a large percentage of customers. Someone has to deal with the problem, right? As it turns out, someone always does deal with it.

The biggest problem with flat companies is that when structure is left undefined, a structure will still form, but it won't be the structure you want. Folks will elect themselves to particular positions and start making decisions on behalf of others. So, you still don't avoid the hierarchy and you've also created an unhealthy organization.

When we started growing, I decided to implement structure amounting to a flat hierarchy.

WAT.

Here's how it works. Write down all the roles that exist in your company. Assign each role to a member of the company and inform them of their responsibility. Then tell them not to play that role unless they need to.

This levels the playing field for day to day operations, effectively creating a flat company. But when a situation arises and a decision needs to be made, it's clear who decision maker is. Just like process, the structure isn't used unless there's a defined problem to solve.

I tend to think of it a bit like sudo in a Unix system.

You can find this pattern in everything we do as a company. Typical project teams consist of three developers; one is chosen to play the role of project owner. Our teams don't require full-time management, so the owner is a developer 80% of the time. When the client calls about a problem, the owner deals with it rather than letting it impact the entire team.

I even think of my job as Sudo CEO. By default, I consider myself to be a developer. I just also have the power to make higher-level decisions when necessary. At our size this works really well. I hope it scales.