Skip to content
Home » Why democracy doesn’t work

Why democracy doesn’t work

ScalingTheScaleup - why democracy doesn't work

In the first couple of months of my journey as a head of technology in the scale-up company I joined, I faced a lot of loose ends. Starting with an excessive amount of documents to go through. Not documentation, but actual pieces of unstructured content all over the place. Lots of initiatives that started six or nine months ago, with already quite some time invested, but without any concrete actions. And on top of this, the usual issues with a lack of processes, no security measures in place, almost zero monitoring, and massive technical debt.

Well, this is what they hired me for, to sort out all this mess and get us ready for a nicer, leaner, and brighter future. And this is what I am supposed to be good at. And I am. I can analyse and assess the scale of the problem and put an actionable plan together, describing step-by-step how to improve our posture. But it is a change, and I didn’t want to just come and say “this is how we are going to do things from now on”. I wanted to make it a joint decision, involve senior members of the tech team and figure out the solution together (while I already had a solution in mind).

My idea was – let’s get all of us into the same room, get some food and beers provided, spend whatever time we need and leave the room with a plan in hand.

The challenge

Sounds pretty straightforward, right? But, challenge number one is getting everybody in the same room. With a geographically distributed team it is a even more challenging. But we managed to bring everybody for two days in the same office. Challenge number two – people already have very busy agendas and they cannot just sacrifice a day of their work for these kinds of events. Because their teams cannot run without them. And they don’t understand why would we need a whole day for this. Not to be too pushy, I agreed to a two-hour session instead.

And then the fun began. The first thing I wanted to tackle was team structure. With some changes in organisation, teams drifted apart and started working in silos, there were several teams doing similar things. Some teams were left without any kind of leadership.

I started the session by outlining the problem. Why I thought it was important to address it, and my initial thoughts on what we could do about it. Instantly my idea was met with hundreds of concerns. The majority of which would be very detailed and specific situations (like who is going to be in charge of this particular microservice, and why not the other team). “It’s too big of a change to make a decision right now. And we need to involve the team as well” – that was the joint summary.

If you cannot come up with a solution with the five of you and the discussion just goes into criticising the proposed approach, without any new ideas being thrown on the table, what would happen if you add another 35 people? It will take even more time, and no decisions will be made. The best decision that will be made, is that we need another meeting to continue this discussion. But nobody is too keen on joining, because it does feel like a waste of time.

Is there a solution?

How to move fast, while still keeping the team involved in the decision-making process

Step 1:

List all the problems to tackle. On your own or with your direct reports (I assume it will be tech directors and managers) decide what is the minimum required level of seniority necessary to be able to contribute to each of the problems.

Step 2:

Share the problems from the list with subsets of people meeting the seniority requirement. And the message should be something like this:

Hey guys, as many of you know this [problem] was bugging us for quite some time now. I know many of you had some ideas on how we can tackle it, but we never had the time to actually make it happen. So the time is now. If you want to join the task force group to find a solution and make sure it gets executed, please respond to this message. But there is a minimum set of requirements to join:

  • you are able to invest time into it (please check with your team schedule and align with your line manager)
  • you contribute with ideas and do not just join to listen or criticise others
  • you commit to not only figuring out the solution but also executing it

It’s your chance to make a difference and be part of the change, but it comes with a price.

Then you see that out of 15 people, only a few would actually have the time. To some, it became not that important and they would be, actually, okay with any decision made for them. And hopefully, you’ll end up with a few people who do want to push the envelope. If nobody responds – well, it means the decision is up to you and your leadership team.

Step 3:

Introduce time constraints. When the task force gathers together to start working on the problem, specify the time frame in which they need to find the solution. They need to have a clear picture of the time required for the implementation. If there are no time constraints it will drag on forever.

Step 4:

If you are not actively involved (being part of the task force), have frequent check-ins to make sure things go according to plan.

Step 5:

Once the team executed everything, with most likely more time required than initially planned (but you initially planned for it, of course), don’t forget to publicly praise the team. Acknowledge their efforts, all the extra time they had to put in and the impact they made.

Conclusions

This is my take on democracy in the scale-up. In a smaller company, when you deal just with a single team of 5-10 developers – decisions are fast and everybody contributes. The bigger you grow, the more adjustments you have to go through in order to make it work. Old methods become unproductive, so you have to be creative and adaptive to change.

What’s your take on that? Any tricks you used to keep the pace up and the team engaged? Leave a comment below or shoot me an email, would love to hear your story.