How to run a "self-organizing" company

This post is inspired by the article "Ex-Valve employee describes ruthless internal politics at 'self-organizing' companies" in PC-Gamer, which in turn was triggered by a stream of tweets by Rich Geldreich.

I am writing this to share my experience from working at it-agile GmbH. It is not my intention to prove Rich wrong (I am not questioning his experience), but to provide an alternative view on what working at a company with a non-tranditional structure can be like - and what might be necessary to make it work.

Disclaimer: this is purely my personal perspective and opinion. Nobody at it-agile (or elsewhere) approved of this text. I am writing this during my vacation, out of passion for this way of working.

A bit of background: it-agile was founded in 2005 by three colleagues who where unhappy about how they were treated by their boss. Today (July 2018) we are 42 permanent employees, currently growing quickly. About 65 percent of the company is collectively owned by all permanent employees.

I joined it-agile in 2009 and went through a couple of phases since then: excitement, puzzlement, frustration (for halve a year, I seriously considered quitting). Today, I would describe my relationship to my company of choice as mainly dominated by appreciation - for the joys and difficulties of working in such a structure, for being able to be part of such a "social experiment", and for my colleagues, who, despite all our differences, are willing to invest into our shared journey.

In all those years, we learned a lot about how to run a "boss-less" company - and we are still learning. And that's definitely not always fun.

For the rest of this article, I will pick a couple of Rich's tweets that I feel I can provide an interesting alternative or complementary perspective on. I will skip those that are specific to working in a software development team.

So-called “self organizing” companies are controlled by mass anxiety. Anxiety is contagious. I don’t think they are healthy places to work.

— Rich Geldreich (@richgel999) 15. Juli 2018

I can see at least two reasons why that would often be the case.

First, if you take away formal hierarchy, it will quickly be replaced by an informal hierarchy. There will always be people who have more influence than others. The company culture will quickly reflect the values in action of those top influencers. And even if they espouse values of cooperation etc., they will have learned tools of coercion that they fall back to when things get rough. They just don't know any alternatives.

A central hurdle is that the tools of coercion actually had an important function: creating "alignment". If you take that tool away without replacing it by alternative structures that fulfill that function, it's very easy to loose cohesion over time - at some point, it might easily feel like anarchy has broken out.

The only working alternative that I am aware of is social pressure, created by "brutal transparency" and shared responsibility. At it-agile, every co-worker can see how I spend company money, and every cent I spent affects the profit share of everyone else. If I do something that seems irresponsible, I will get strong feedback, sometimes in a way that is hard to digest.

If that doesn't sound nice - well, it isn't. It can be very productive, and actually fulfilling, though. For that, we had to invest a lot into acquiring new skills, though - especially skills that help us to deal with conflicts in an effective way. If you don't posses those skills, it's easy to imagine how it would result in a culture of anxiety. (Interestingly, at it-agile it resulted in a culture of false compromises and frustration. So, it doesn't have to be anxiety.)

So, in summary, if you think you get a "self organizing" company by just taking away or reducing the formal hierarchy, I am not at all surprised if you end up with increased anxiety.

If you’re dealing with a self-organizing company it’s more complex. You will be triangulated against multiple people and you’ll have to deal with group consensus.

— Rich Geldreich (@richgel999) 15. Juli 2018

True. Navigating (and shaping) the social network becomes a much more important skill when you take away the hierarchy. Personally, I would rather learn this one, than learning how to game the formal hierarchy.

Also, you can put structures and agreements in place to deal with the negative effects of triangulation (aka office politics). At it-agile, we have developed a shared understanding that if we talk about a coworker, we hold each other responsible for then also talking with said coworker about the topic that bothers us.

What you’ll find is that the corporate arm influences, controls, and “anxiety spikes” the self-organizing arm nearly constantly. It’s not self-organizing, it’s a company with opaque managers ruled through mass anxiety and fear.

— Rich Geldreich (@richgel999) 15. Juli 2018

Seems that part of the confusion here is that "self organizing" isn't really well defined. (As far as I know, Human Systems Dynamics even argues that every social system is self-organized - in a traditional company, people just self-organize around hierarchical constraints.)

As Niels Pfläging argues much better than I could, flatter hierarchies are not the answer, decentralization is. And it comes with the challenges mentioned above.

A lot of Rich's tweets reference the existence of such a "corporate arm". His advice seems to revolve around how to use that fact for your advantage, or at least survive it. If I'd ever decided to work for such a company, only if I'd see a chance that that "arm" actually would be interested in getting reflected their (negative) impact and change their behavior.

At self-organizing companies with bonuses, workers will watch for rivalries between other coworkers to exploit. They will team up with one dev to bring the other (disliked) dev down a notch in some way. (I’ve seen this several times.)

— Rich Geldreich (@richgel999) 15. Juli 2018

There are whole books written about why (individual) bonuses are a really bad idea in today's workplace. That is true doubly so for "self-organizing" companies.

Having said that, a fair compensation structure is a very complex problem to solve, that we haven't fully figured out yet ourselves. I am not even sure that it's possible. We are experimenting with variations of different approaches for years now, and are in constant dialog about it. That's the most important thing for me: I can talk about what bothers me, and I have an impact by doing so. I also understand that what would work best for me, wouldn't work well for everyone of my colleagues.

On a competitive team within a self-organizing company, avoid asking for help unless you absolutely, positively need it. Any information you receive may be purposely distorted in some way. If you do ask for help, gather consensus from multiple devs.

— Rich Geldreich (@richgel999) 15. Juli 2018

Putting teams inside the company in competition to each other - another stupid idea that becomes even worse in a self-organizing company.

What you do want, is teams holding each other accountable. A team at it-agile that seems to struggle will get asked "what are you doing to get out of the struggle", but also "what help do you need". A team that does exceptionally well will get asked how they do it - both to learn from it, but also to make sure they don't overwork themselves and steer into burn-out.

If you’re running a self-organizing company, you need to have a measure and understanding of the current average and peak Anxiety Level within the self-organizing arm. Or it blows up and talent walks.

— Rich Geldreich (@richgel999) 15. Juli 2018

This is an interesting tweet. I would rather say "if you're running a self-organizing company, what the heck do you mean by self-organizing?" A self-organizing company, by my definition, isn't run by a single person (or small group of people).

Having said that, it's true that it pays to have someone who has an eye on the company atmosphere (which is much more than just anxiety level). In 2016, we introduced the role of a company coach for that (though not just that) purpose. It's a rotating role, that one colleague fills full-time, assisted half-time by another colleague. Remember: these are colleagues who would otherwise be out there making money for our shared profit. And we all decided together that it's worth it.

These folks will be given a free pass. The corporate arm can hire and fire anyone they want at any time. If you went through the normal interview loop and weren’t filled in beforehand, the corporate arm could care less about you.

— Rich Geldreich (@richgel999) 15. Juli 2018

After skipping a couple of "corporate arm" tweets, this one stood out for me.

At it-agile, an interview is done by at least four self-selected colleagues. If I have a strong doubt about a hire, I can be part of the interview. And all those colleagues in the interview need to agree to make an offer.

So ironically, the better and more skilled the recruit the less probable it is that they’ll get the job. Current employees don’t want any more competition for their bonuses.

— Rich Geldreich (@richgel999) 15. Juli 2018

Interestingly, shared profit has the exact opposite effect: the better the recruit, the more profit he will produce, the bigger my profit share.

If you run a self-organized firm and you have turned up the anxiety levels too high, your company will become brittle and prone to mass talent flight. Wealthy competitors can come in and make offers and basically steal all your tech and devs right out from under you.

— Rich Geldreich (@richgel999) 15. Juli 2018

I would emphasize that that can happen to you simply because you don't know how to run a self-organized company. At it-agile, at one point the level of frustration became so high, that we feared if we'd just continue, we all would quit in a matter of two years. And nobody wanted that level of frustration or was willingly benefitting from it.

We took that as a trigger to explicitly invest lots of time and money into learning how to better deal with conflicts. We got professional external help, and created internal roles responsible for supporting the process. And that process still isn't finished, though we have a much better understanding of the necessary skills and processes today, and the working atmosphere and culture has improved considerably. (Interestingly, the year we started investing into this, profit also increased noticably.)


OK, I could write much more, but I am getting tired, and this is already quite longish for a blog post. If you are interested in something specific, I will happily answer your comment. Or, if you read German, you can look at the book that I am very slowly writing on LeanPub: "Wir arbeiten hier trotzdem".

"Unlimited" Vacation Misses the Point

Unlimited vacation policies are one of the less traditional management practices that seem to get a lot of talk recently. And I see a lot that seems to miss the point.

Disclaimer: I live in Germany, where laws are a bit different from the US. For example, sick days - even when you get sick during your vacation - don't count towards your regular paid time off bucket. I think the principles that I'll describe still should hold true, though.

What traditional vacation policies really do is define a paid time off budget. Someone, sometime figured out what he thought was a "fair" amount of time per year, and that's what you get. Maybe even a little more, depending on your employer and negotiation skills.

Makes sense? Well, let's do a thought experiment: imagine being self-employed. Imagine that someone - maybe the government - tells you that you should take exactly x days of vacation a year. Still makes sense?

If you are anything like me, you would resist that dictate. You would want to take responsibility for finding the right balance between financial, mental and physical health - of both yourself and your family. Instead of figuring out the right balance once and for all, you would continuously adjust your plans - to your own needs, those of your family and customers, and to the development of the market.

So why does that stop once we get employed by a company? 

I think it shouldn't.

Of course, once you have colleagues and stakeholders, the whole situation becomes even more complex. A fixed time vacation policy reduces that complexity. But it also takes away your responsibility to make decisions that make sense. And that's not a good thing, in my opinion.

What would be needed for a vacation policy to work that doesn't work with a budget? In short, every employee needed to be an entrepreneur who feels equally responsible for himself and his family, his colleagues and the organization. That includes, but is not limited to (pun not intended):

• every employee having a good understanding of his own needs, the needs of his colleagues and the organization (and being in a constant dialog about it),
• feeling responsible for creating a good balance between those needs, in cooperation with his coworkers; as a consequence
• a culture where coworkers hold each other accountable - not only for work results, but also for taking care of themselves, and
• a culture where the inevitable conflicts are dealt with productively.

So, it's not about removing the limit, letting every employee have "as much vacation is you want", inside a traditional culture of "getting away with as much as I can". It's about creating a culture of "we are in this together", where - as a consequence - such a limit wouldn't make sense.

PS: if your vacation needs to be approved by a manager, you probably don't have unlimited vacation - you have a variable limit that depends on the whim of your manager.

Modeling The Real World vs. Designing Software

I started writing a response to comments on a previous blog post, and it turned out long enough to become its own post. The question was on whether you should relationships in the "real world" to decide on relationships in your object-oriented designs.

"Is-a" and "part-of" are concepts from object oriented analysis, where you try to model "the real world" in terms of classes and objects. That is, by looking at the problem you are trying to solve, you could come to the conclusion that a customer "is-a" person, and that a street name is "part-of" an address.

In the early days of object orientation, it was assumed that you could simply transfer the relationships you found in that analysis directly into your design for good results.

There are (at least) three reasons why this doesn't generally work well, in my experience:

• when we analyze the "real world", we typically model the problem space. When we design software, we model the solution space. Although there are often similarities between the two, there is no direct mapping - in fact, finding a good model for the solution is the most creative (and important) act in developing software. Assuming that an "is-a" relationship in the problem space will directly translate into inheritance in our solution space needlessly restricts our creativity, and thereby leads to inferior solutions.

• for me, the primary goal of software design is to manage dependencies in the design, so that the resulting system is maintainable and extensible (because successful software is software that will need to be changed). As a consequence, there are forces working on our designs that don't exist in the "real world", and therefore considering just "real world" relationships won't help managing those forces. Just take the famous "a circle is an ellipse" example: while true in mathematics, depending on what you need a system to do, reflecting this relationship in your design can violate Liskov's Substitution Principle, and thereby lead to brittleness and unnecessary complexity. That is, a relationship that is absolutely natural in the problem space leads to problems when transferred as-is into the solution space. Another example: both a customer and an administrator are persons, but that commonality could be totally irrelevant to the solution of your problem, and then modeling it in your design would be a waste, at best.

• in the English language, there is no unambiguous rule about when to use which phrase, anyway. Yes, you could say a customer "is-a" person. You could as well say that personal information is "part-of" a customer. Or that a person "has-a" role of being a customer. It can even make sense to say that "a person is a customer". So you really can't use natural language semantics to decide which relationship to use in your code.

So, using those relationship names doesn't really take the burden off your shoulder to choose wisely which relationship makes the most sense in your specific case. And an experienced designer will - whether explicitly or by gut feel - choose the relationship that leads to the most SOLID design. and he knows how to refactor to a different relationship when his understanding of the forces in the code changes.