For a long time, Jason Fried’s article Why I Run a Flat Company has seemed like an unrealistic dream that only works in rarified pockets of hacker utopia.

You have to understand, I work for an institution which, between the university, hospital(s), and various other divisions, employs over 40k people, enrolls over 20k students, treats countless patients, and who knows how many vendors and contractors add complexity to the mix.

But I still think there’s something to this “flat company” idea. My team is a bit of an oddity, and I think that’s what allows us to be agile and innovative in a way that’s impossible for most of the other software teams. The team is, on an org chart, pretty much flat. We have a team lead, to whom we don’t report (on paper).

Let me backtrack a bit. In interest of full disclosure, I do have a bit of a cognitive bias in favor of flat organizations. My lefty politics tend toward anarchist-communism, so I have a certain degree of distrust for any hierarchy. I think this goes back to the important distinction between having authority and being an authority. The difference between a bestowed, arbitrary power, and the innate power of being intelligent, capable, and well-informed.

From this perspective, the (practical) ideal would be a democratically-managed, worker-owned organization where salaries/wages were ditched in favor of profit sharing.

I think software is one business where this ideal is eminently practicable; but let me get back to “the real world.”

Specifically, my job.

On an org chart, it goes CIO -> Sr. Director -> Director -> me. Let me note this is weird for my organization. Normally, it would be something like CIO -> Sr. Director -> Director -> IT Manager -> IT Architect -> Señor Software Engineer -> Software Engineer -> Señor Programmer Analyst (me) and there would likely be some kind of “Peasant Programmer Analyst” for whom I was responsible. I won’t go into the fact that if I wrote out what I actually do, it would be 2-3 levels above my pay grade (well, at least not yet).

My team creates enhancements for legacy systems that makes jaws drop among senior VPs from the company that sold us these systems. It’s super cool, and after our public release this summer, I’ll be able to talk about them. And beleive me, I will. I’m super-proud of this stuff.

But the question remains, how is it we pull this stuff off with 1.4 developers, one sysadmin/network engineer/informal team lead, and one hardware/support guy?

I think the lack of formal management is key. Our director is fairly hands-off, as long as we’re meeting goals and keeping the customers satisfied (which we nearly always are). Our team lead recognizes where the real expertise is among the team, and defers to the judgment of the de facto “experts” where appropriate. We are a flat team in an eminently hierarchical organization. And we kick ass.

Recently, our audacious innovation has come onto the radar of the CIO and senior IT management team (among others). That’s pretty damn cool, on the one hand. On the other, by being off the radar, we’ve managed to create this cohesive little unit that actually works. We’ve also been able to choose a stack based on what will pull off the impossible in a timely fashion, rather than what our approved vendors provide.

We run Debian on most of our production servers. Our web apps are built with Ruby on Rails, and there’s some JRuby and Clojure stuff in the works.

This is unheard of. This in a place where Windows Server is the default, where ASP.NET is the preferred web technology…

I think the problem with having layers and layers of management is that managers need to look like they’re doing something. Usually, this invovles purchasing decisions, standards impostion, and adding more layers of inefficient management.

When you have a relatively flat organization, it’s more important to hire smart people who can generally handle themselves, set the mat a task, and be ready to support them as necessary. That’s how we work, and the result speaks for itself.

We’ve experimented with promoting a few people to manager-level roles. In some cases, this has worked out; in others, it hasn’t. But one thing we’ve found is that groups that manage themselves are often better off than groups that are managed by a single person. So when groups do require structure, we get them to manage themselves.

Jason Fried,

Of course, innovation isn’t always the top priority. But I think whenever possible, it should be towards the very top of the list. Innovation is the key to competitiveness, and whether you’re a university, a hospital, or a software company, ultimately it comes down to the bottom line: how do we increase revenues and decrease expenditures?

Creating innovative features that can attract new customers, and save work for staff, at the same time, ultimately mean that deep down, you’re a profit center, even if you’re still classified by the dreaded beancounters as a cost center. And in this crazy, mixed-up world, that’s what it’s all about.