Jason Fried: Why I Run a Flat Company

if your environment has a significant amount of elements that engineers (or generally - employees) wouldn't want to be in charge for, then you are already deep into the problem and the shortest solution here is to assign managers to be in charge of those things.

The key is to not allow the situation to degrade into creating "demand" for managers. For example, once you create one manager for a group, s/he would want to talk to somebody, preferably managers, from other groups. That burden on the other groups would naturally trigger response - creating managers in the other groups. That starts to structure the information and decision flow the way that rank-and-file employees lose much of the visibility into the product and business and thus lose the ability (and motivation) to take even small decisions, thus requiring even more management ...

That is a priceless comment. It exposes Jason's huge blind spot. Worse, it is on this undefended flank that great future pain may be inflicted. I look forward to the post-learning article.

The underlying premise/assumption is that a 'manager' is not only not doing 'the' work, but they aren't really doing 'any' work. Its a very common meme in engineers, "The company makes money on the code I write, it makes no money at all on this guy telling me what do, it just costs them money."

Let's reason about this using a fairly simple analogy. We will start by positing that we are all rats in a maze. Our maze is, unfortunately, filled with rat dung. We further stipulate that walking on dung would kill us so the only way we can move through the maze is by shoveling the dung in front of us, to the pile behind us and then moving into the space we opened up. All the shoveling burns up calories, if we don't eat we will eventually starve to death. Finally, we add that there is a cheese somewhere in the maze, and once any rat makes its way to the cheese, everyone gets to eat of the cheese. That resets the rat’s hunger level, after the the cheese is located the maze resets around all the rats and process begins again.

Now in our analogy our engineers are the rats. And writing code is shoveling rat dung. And the cheese is a monetizable opportunity. Eating the cheese is collecting money from the opportunity.

In a small company, having everyone shovel as fast as they can, is a great strategy for finding the cheese(s). Some mazes have more than one cheese in them, sadly some mazes have no cheese in them. A manager, whether its the founder/CEO, or someone in that role, is given the opportunity to stand above the maze and see if there is a cheese nearby or in the distance, by seeing both the maze and where the cheese is relative to where in the maze rats are, they can direct rats that have the best chance of getting to the cheese quickly in the direction they should turn, otherwise each rat would be following his/her internal idea of the best way to find a cheese in a maze like ‘always follow the left wall’ or ‘alternate left and right turns’ or ‘leave marks in the dung piles of parts of the maze you have already passed through so that you can pick new passages the next time.’

So the leadership role of management in any technology company, is measured by their ability to get teams to the cheese while shoveling the least amount of rat dung. Good leadership will understand that there are many cheeses (and flavors of cheese, some more nourishing than others) and be able to evaluate the choice of going further for a very nourishing cheese vs going out of the way to munch a nearby, but less satisfying, cheese.

So back to the comment tail … “who don't do the actual work.” briefly.

It is pretty easy for an engineer to recognize a problem in one of their colleagues, even though their colleague is ‘doing’ a “lot” of work, that work is inefficient and thus ‘poor’. Someone checking in version after version of a subroutine, trying to get it correct, when that subroutine is doing something that is provided by the underlying operating system. Lots of ‘work’, lots of ‘check ins’, but someone who had a bit more breadth might have done in a couple of hours what this loser is taking a week to do. As an engineer, one can easily appreciate that this person is taking up an employee spot that could be put to more efficient use by a better quality engineer.

And yet it may be hard for that same engineer to understand that a manager is helping him, and his colleagues, be more efficient by working excellently on a component that will get them to a good cheese, versus working excellently on a component or a technology that does not proportionally have the business value they need to pay their own salaries.

A real world example was a shopping cart company that had, at one time, all of its engineers working on a universal language independent component for presenting product descriptions in over 100 languages and nobody on the team was working on making the shopping cart code play nice with various payment services. Which is the more nourishing cheese? English only and you accept any kind of payment, or any language but you have to have one type to payment card from one vendor ? The engineers were all writing excellent code, using all the latest best practices and the language support module they came up with was best in class, but product was a shopping cart and the “high order bit” for a shopping cart implementation is “can it take money from customers and put it in the bank?”

So when an engineer makes a comment like Jason’s about valuing ‘doing’ over ‘directing’, it can sound like the oarsmen in a galley complaining that he should be accorded higher status than the navigator since without him the boat wouldn’t go anywhere. But the reality is that without the navigator the boat wouldn’t arrive anywhere. Considered in the larger context, the navigator’s role is both more stressful and more important to the overall success of the trip than the oarsmen.

What Jason’s comment misses, and it sounds like a blind spot, is the understanding that you cannot successfully navigate and row at the same time.