Holacracy in a software house
Part 2 of the interview with Tomek Dziurko, SoftwareMill's VP of Engineering
read part 1
Kamila Stępniowska talks to Tomek Dziurko about how decisions are made at SoftwareMill, how guilds work, and why the company opted for their own version of holacracy.
Kamila Stępniowska (KS): The closer I got to know SoftwareMill, the more it began to remind me of Spotify in terms of its culture of organization. From what I know, that’s not where your inspiration came from, but Netflix is a kind of newly-discovered source of inspiration. You discussed Reed Hastings’ “No Rules Rules: Netflix and the Culture of Reinvention” at your reading club's meetings. Are you thinking of implementing any of the organizational solutions presented in the book?
Tomasz Dziurko (TD): We’re planning to. What we really liked was the emphasis on feedback culture – very honest, regular feedback, focused on what can be done better. The book broadly describes a fairly developed system for giving feedback so that it’s constructive and not taken as a personal attack. At SoftwareMill, we work in a similar manner, however, we feel we can still improve in this area. We are aware that giving and receiving feedback is generally a tough nut to crack. I assume that little by little, we will get to where Netflix is: providing feedback as often as possible. Feedback that's timely, delivered following a given situation is a lot more effective because both sides still remember all of it and it’s easier to communicate.
KS: It seems that SoftwareMill is open to internal discussion. You don’t have departments but so-called guilds. I take there's more to that than just a different name?
TD: SoftwareMill used to be a flat company, so everyone could express themselves in any area. Whenever a decision had to be made, we asked for everyone’s opinion, and we made decisions together by a company-wide vote. And it was great, it worked well until we grew to about 40 people. It then turned out that not all decisions can be made together. Some people simply don’t have the knowledge or context to consciously vote for or against something. That’s when we decided that we need to narrow the groups down a little in terms of competences – to people who really want to contribute in a certain area, are interested in what’s going on, and are somewhat familiar with a given part of the company’s activity. We introduced a holacracy, or at least that was our starting point.
At SoftwareMill, as you mentioned, we have guilds – every area of the company’s activity has its own guild. It also has a guild master who coordinates activities and makes sure that the things that need to happen actually happen. At the moment, many smaller decisions concerning a specific area of activity of the company are made within the guilds. The decisions are made by people who really have the knowledge and context, and who know what the risks, consequences, business goals, and reasons for the course of action are. It’s important to note that anyone can belong to a guild – you simply need to express interest and consciously decide that “OK, I’m interested in this area of the company’s activity, so I want to do this, I want to and have the time to keep track of this.” We haven’t completely got rid of our flat structure. Decisions that impact the entire company are still made via voting by every member of the company. Here, we stick to the values SoftwareMill grew out of – everyone can add do their own bit and shape the company.
photo: the SoftwareMill team at a team-building getaway
KS: It sounds like as a company you put a lot of emphasis on autonomy and independence.
TD: I think the founders’ goal was always for the company to be self-organizing. SoftwareMill was founded by programmers who wanted both to programme and run a company. So they needed the help of people who would be actively engaged not only in work on projects but who would also contribute the company's growth. In order to function on such terms, we need to trust each other. Without trust, it’s hard to be transparent, and without transparency, we don’t have access to knowledge necessary for making good decisions.
If a small group, for example a project team, has all the information required to make a decision, they can make it on their own. Of course this does not apply to a situation which involves e.g. financial risk or a strategic area of activity of the whole company. However, in most cases, autonomy and independence make sense for us. The main upside here is that decisions are made faster and by people with the best knowledge in a given area.
In extreme cases, a team can even make a decision to stop working with a client, despite the fact that they are paying regularly and everything’s all right from the financial point of view. If the team decides that the way of collaborating on a project is unacceptable and attempts to improve the situation don't bring the desired results, they can simply say: “We’re finding this client very difficult to work with and attempts to heal the situation haven’t helped, so we would like to end this project.” Then, as as company, we finish such a project. And it’s the team's decision. Such decisions are not made prematurely. The team first signals the problem on the company forum and asks for advice. Then other people at SoftwareMill who have experience working with difficult clients try to help and suggest some ideas for solving the impasse.
KS: Wow! That’s really big autonomy and trust in the team. It’s a bit like running your own startup within a company, something like that.
TD: The decision to end a project is never easy, but such autonomy is possible thanks to the fact that we work transparently. Everyone knows the financial situation of the company, which projects are ending soon, whether and how many clients are waiting for an available team of ours. This enables people to make better decisions because they know both the client’s and the company’s context.
KS: That’s a bit like at Spotify. If anyone needed any hardware there, the offices (when offices still functioned normally) had shelves with equipment available to everyone. You could take for example a mouse, a monitor, or even a laptop. These items had prices written on them, but not so that the employee would pay, but simply for them to know what the laptop they’re taking off the shelf cost the company. But no-one needed to approve them taking any given laptop or mouse. That’s also a great deal of transparency and trust.
TD: In our team, people just buy those small things worth 500-1000 PLN themselves, and then the company returns the cost. Let’s say you need a mouse, headphones – no problem, buy them. If you’re having doubts about whether it’s a good idea, ask your teammate. During recruitment, I often say that if you want to buy yourself a gold-plated mouse and you’re not sure, just ask your colleague: “Listen, there's this gold-plated mouse, it’ll be really great to work with, is that a good idea?”. And if the colleague thinks it’s a good idea, then you buy the mouse :)
Escalating minor decisions makes purchases more expensive. Same goes for a 20-person discussion on whether to spend 200 or 500 PLN — it makes the decision itself cost 10 times as much. Even if we’ve saved those 300 PLN by buying something cheaper, we’re still losing overall, so it’s pointless.
When it comes to bigger purchases of equipment, we notify the administration and they organize the purchase. We don’t cut back on equipment, we try to buy powerful models of computers. The weaker ones end up being problematic because after a year or two no-one wants to use them as they aren’t enough even for those who don’t do any programming.
KS: In this case, the unwritten rule that it’s a bit harder to get into your organization makes even more sense. Once you’re in, you get to use all this freedom and all these benefits. It probably has an effect on the fact that so many people stay with you for a long time.
TD: At the moment, there are 25 people who have been in the company for at least 4 years. It’s great to see that many people find themselves a place here for more than just a year or two. Maybe simply because it’s great here. We also have a lot of people who used to be part of large companies. They witnessed the amount of organizational overhead, procedures someone once invented that later no-one really has the power to change. At SoftwareMill, people appreciate the lack of what we call “corporate goodies”. When we see something getting in the way of effective work, then we first decide if it's even necessary, and if it is, whether it can be automated. It usually turns out that it can be simplified, or sometimes eliminated. In my opinion, one of the most frustrating elements at work is when you know you've got a creative task waiting for you but you have to break away from it to take care of some paperwork or other formalities. Luckily, we don't have that at SoftwareMill.
KS: To conclude and approach the subject of employment from a different angle, what are the traits of a good senior engineer in your eyes?
TD: From my perspective, when I browse the CVs of more experienced people, then other than technical abilities, I pay attention to what this person has helped their client with. What their business value was in a given project. For instance, it could be a description of how a system was able to service many more client requests thanks to a change to its architecture that they made together with their team. Or how they changed their methods of deployment, thanks to which downtime fell by X percent. The changes don’t have to be technical – a client can also be helped by reducing the number of errors by implementing some change in the process of software production. If the senior engineer notices such issues, they are not only a coder but a partner for the client or business.
The business doesn’t just need code in small, well-divided classes and 90% tests covered – it needs a given system to work fast, to be reliable and fulfil its functions. For the client, coverage by tests or great division into classes is a means, not an end. If the programmer understands this, that’s a slightly higher level than a coder who receives a sprint task, completes it, and reaches for the next one without too much thought.
At SoftwareMill, we're looking for business-conscious programmers. Teams work much better and clients much prefer to work with people who understand both the code and the business that pays for the code. Such a programmer will sometimes ask a few difficult questions or try to understand a given domain better, thanks to which it may turn out that the client's idea isn't the best or the task needs to be approached from an entirely different angle than originally planned. Functionalities that pay a minor role in the client’s business need to be approached differently to elements of the process that’s responsible for 90% of the company’s income. In my opinion, a good senior will be aware of this.
KS: Makes sense. Both for the employee and the client. Thank you for the conversation, Tomek, and best of luck with SoftwareMill’s further development!
Kamila Stępniowska works together with SoftwareMill as part of Ginger Tech.
Want to get to know our team? Watch the video and see what it's like to be a part of #SoftwareMillVibes ;) Or... How about you join us?