I've been wanting to write about my experience starting and running
Metabahn 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.
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.
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 real
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.
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
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
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
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.