Anarchy in the UC

Anarchy in the UC

A couple of years ago, I was working as an IT consultant at a large, public service provider in Norway. We were just starting a new project that would include replacing a piece of Norway’s central infrastructure. It was an important project, with many eyes on it and it was going to be done right.

To ensure the success of the project, the customer had defined their own software development process that was to be followed based on prior projects. This process set rules for everything related to how to run a software development project, from high level stuff like:

  • length of “sprints” (3 weeks)
  • the team structure and flow (specification team delivers specs to developer teams, who delivers testable systems to test teams, who delivers tested systems to ops for production)

to lower level stuff like:

  • All tasks must be taken through a specific, 9-step workflow in JIRA.
  • All tasks must be estimated doing planning poker
  • Java must be used for all backend programming
  • Oracle is the database

They also had a separate department working on a national metadata taxonomy and vocabulary, to ensure all systems were using the same naming and categorization for the same entities.

Luckily, we had several experienced developers and project managers on the team, and after talking this through internally, we spent the first week or so deciding the following:

  • We would develop and deliver continuously - no sprints
  • We would center our organization around the development teams - test, specification, etc were to be seen as supporting functions, supporting the team in creating the system
  • No handovers - the team owns the functionality from conception until it is no longer running in production
  • The team would push to production at their discretion
  • We were not going to use that JIRA workflow
  • We wanted to take a look at Cassandra for some of our database needs
  • Our vocabulary would be created to suite the use cases for the APIs we supply

The following two years were spent fighting for our right to keep these decisions. We would do something our way, and the customer’s IT organization would stop us, saying we were doing things wrong. Then we would argue why our way was better. Sometimes successfully, other times not.

This experience was not a new one to me - having strict rules defined in advance, with little leeway for customization according to the project’s needs is something you see a lot of in these kinds of organizations. For us, it meant a lot of frustration and wasted time spent arguing about how things should be done instead of doing them, with the other side usually having only one argument: “this is the way we do it.” In this specific case, it also lead to me blowing off some steam in this rant (Norwegian only).

Desire Lines

Have you ever walked through a park, and seen the muddy track across the lawn that doesn’t follow the paved path, but ends up taking you where you want to go faster than the paved path does?

Of course you have. This kind of path is so common that in transportation and landscape planning, it has its own name - desire lines (or paths). Desire lines tend to appear wherever the planned path wasn’t the best choice, and they appear because people choose a better path. This insight has caused some architects and planners to wait with placing paths until they can see the desire lines, eg. by waiting for the first snow and seeing where the tracks in the snow goes and then pave those paths the following year. Other, less user experience focused designers, choose to put up signs like this:

Organizational Desire Lines

What we saw at the large, public organization was a perfect example of “please use sidewalk” signs. Instead of realizing that every new project is different, with its own needs and optimal paths, the organization had decided all projects looked the same and made a single plan for what a project would look like - complete with lots of “signs” to guide the projects down the paved paths.

The fact is, of course, that no two projects or organizations are the same, just like no two parks are the same. You cannot design a process for one organization and assume that the same process will work for another. What you can do, however, is look for the organizational desire paths and pave them.

Organizational Anarchy

So who paves the paths? Should you create your own “organizational planning” team, that looks for and paves the paths as they show up? No, of course not - you already have the people you need and, this is important: Let the people who walk the paths pave them.

You have an organization filled (hopefully) with motivated, talented people who want to make the best product possible, with as little hassle as possible. They are the ones who know where the paths go and they are the ones best suited to paving these paths through automation, tooling and formal processes. Let them control the process of improvement, don’t put this responsibility in the hands of leadership.

Social anarchy [...] sees individual freedom as being interrelated with mutual aid.
File:Kant gemaelde 3.jpg
Immanuel Kant

This is not a new idea, in fact, the term was coined in 1798, by Immanuel Kant, and the term is “Anarchy.” Anarchy is defined by Kant to be “Law and freedom without force.”

As a way of governing a civil state, it was discarded by Kant as just “empty recommendations.” If you have a smaller group of people, eg. a company or a project, where everyone is aligned towards the same goals and want what is best for each other and for the group, the matter is different. What you have then is a social anarchy which works beautifully on an organizational level! By letting the individuals decide the best solution between themselves, and by letting them follow their decided paths, you end up with processes that are effective, low maintenance and usually completely void of red tape.

We believe in this at Unacast. In fact, we believe in it so much, that it has become our number one company value: “Be your own CEO” - we even made an icon and emoji for it:

How to Identify Desire Paths - Pain & Pleasure as Drivers

So once you’ve decided to let the anarchy loose in your organization, and give the power to the people - what do you do? How do you find the desire paths? Here’s my take on it.

I’m a big fan of pain & pleasure driven development, whether I am developing software or organizational processes - my focus is on doing less of what is painful and more of what is pleasurable. It’s a straightforward approach, and it has the advantage of continuously creating a better environment for the team by either increasing pleasure or reducing pain.

Some examples:

Is the act of rolling out your application in production a laborious, error-prone task?

Improve it by automating (parts of) it!

Do people like using Slack for operational tasks?

Add support for more of these tasks in Slack!

Are people not estimating their tasks, like agreed upon?

Make the estimates have (more visible) value or remove the requirement to create estimates.

My 4-step guide to paving your desire paths from here is simple:

  1. Create a very simple process based on previous experience (Wait for snow)
  2. Identify what we are doing today (Identify desire paths)
  3. Reduce pain, increase pleasure (Pave the paths)
  4. Repeat 2 & 3

To enable identifying the pains and pleasure, we have had great success on my team with asking two simple questions once a week, while we create our weekly plan: “What is working well?” and “What is a pain right now?”. It takes about 2 minutes, and if something interesting crops up, we address it in this week's tasks.

Anarchy in the UC

“Be your own CEO”, while sounding a bit cheesy and looking like a typical lip service motto, actually means a lot to us, and it is visible in everything we do. It really is the one, guiding principle that lets us be “anarchists” for the good of the company. I will end this blog post by giving some examples of the desire paths at Unacast and how we have identified and paved them.

The pain of manual orders

We send data to our customers in batches. That is what we do. One year ago, every time we got a new prospect or client, sending data would mean a manual change to the delivery system. All in all, a new order or data sample would take about 1-4 hours, depending on the complexity of the order. In addition, since it was all manual work, it tended to break for various reasons, like miswritten credentials or bugs in SQL code. As our client volumes started increasing, this was becoming more and more of a pain for us. Until one Monday, while planning the week - someone mentioned it.

By the end of the day, we had decided on, and drawn up the overall architecture of a self-service system, that would automate and simplify the process of creating new orders and data samples. Over the next couple of months we created this self-service platform (read more here), and creating these orders are now done in a couple of minutes, with automatic validation and monitoring to ensure nothing goes wrong.

Keeping track of ideas

We are a very vocal bunch at Unacast - everyone has a say, and everyone has something to say. Being a multinational company, our main communication channel is Slack. In Slack we discuss everything from hardcore technical issues to who is refilling the fridge. We also come up with a lot of ideas - for products, process improvements and other stuff. As we grew, we realized we were having problems keeping track of all these ideas, and a lot of them were lost to us - the pain was in keeping track of our ideas.

Our solution was to introduce a tool for idea tracking. We now use for keeping track of our ideas, as well as top-level planning of our features and roadmaps. This way - nothing is lost in the sands of time.

Music quiz score tracking

While “Be your own CEO” is our number one company value, we have other core values as well, one of which is “Have fun. Seriously!” These two values have combined beautifully into a self organizing music quiz every Friday, held in our #social-musicquiz Slack channel. But even fun activities are prone to pains and keeping track of the score for up to 50 people while executing a quiz can get quite cumbersome, or a pain if you will.

The solution? Add score keeping functionality to our house slackbot - Unabot:

In the end, my rant from a few years ago about how I wish things were different, has turned into this blog post sharing my experience on how things can be when done right.

Taking the “Be your own CEO” approach and paving the desire lines creates a great working environment - enabling creation of some truly great tech while pruning inefficiencies as we go, and keeping the red tape out of it all.

I recommend everyone introduce the concept of “Be your own CEO” and let some anarchy into their organization.

Related Articles