Programmers anarchy with a direction
I started to work with the go-ethereum team, one of the core teams of Ethereum Foundation. Or did I? We have an agreement that I start to work 5 hours a week, so we can know each other better. No big commitment yet, no contract signed. This is how dating works. We had a coffee (check), we walked an hour around the same couple of buildings (check). We haven’t watched any movie together, but I got a recommendation to watch a talk by Aya Miyaguchi. It’s been a completely different experience from the job interview I’ve been through in the last two years. The foundation has no HR department, no hiring guidelines, no recruiter or hiring manager or any manager at all.
How much can I share of what I learned from the conversations over the last week? I asked Alex if there’s any secret in what he had said. “I know of no secret”, he said, “maybe I’m not in the secret club.” This is such a wonderful aspect of open source. People speak their minds, I don’t have to second-guess. I share my little awesome idea with Bob and he doesn’t hesitate for a moment before he says, “I don’t think it would work here.” I love that straight communication.
I love straight communication in retrospect. I felt a little offended on the spot. I attached to my idea too much. The irony is it was not an idea I had invested a lot into. It came to me during the night when I made a state transition from half-awake to half-asleep. Attachment creates pain, the Buddhists say, and they are absolutely right in this case. All I could see on the spot was a large, capital NO approaching my fragile little idea and stomping it to the ground. (To be fair, it all took place in my imagination. The real-life No was a matter-of-fact statement.)
I had a different idea the day before. I was talking to Carl and asked him what he sees as the biggest problem. “It’s a mess”, he said. I took a note. We left the room where the rest of the team was working together, we didn’t want to disturb them. We were walking on the street. “the team needs direction”, he added. “To get out of the mess?” Carl stopped and looked at me, “What mess?”
I was confused. “You said it five minutes ago. That you’re in a mess.”
“Not a mess. It’s a chaos.”
I smiled as if knowing chaos from childhood, as if being the best friends with it, as if I knew how to tame it. “So you need direction to put order into the chaos?”
“Hell, no, I don’t want any order here. Chaos is good. Chaos is how nature works. Chaos is the fertile soil for creativity. Have you heard about Programmers Anarchy?”
I did my homework and read about it. It was a big thing in 2012, but it doesn’t seem an active movement now. I found out how Github used to work without managers, or more precisely, how everybody is their own manager at Github. These articles led me to think about the minimal intervention. What’s the least I can do to give them direction, help them find a direction? I tried to match these thoughts with my long-time hero, Gerry Weinberg.
When I got up in the morning, I had two simple rules.
- Everybody spends at least 80% of their time on a single project.
- Every project has at least 3 members.
Of course, you can switch to another project, but you need to wrap up the first one. Deliver something. But I was not worried about how they would receive this rule. Right now, everybody is working on his (yes, his, no woman in the core group) own project in his own corner of the codebase. If it takes 3 people to work on a project, someone has to pitch the idea to the others. They have to have a conversation and decide on their priorities. If more people are working on the same feature, they get to know one another better. They also gain a better understanding of the code, so any one of them can review pull request. I stole the gist of the idea from the Github articles I read.
I could hardly wait to share my brilliant idea with the team. The first person I shared it was Bob. You already know his answer, “I don’t think it would work here.”
Alex, Bob, and Carl are protecting something from me. What are the toes I’m stepping on? They say they are creating a completely new product, so it needs a new way of doing their work. They want to keep their freedom. They want to keep their lovely culture I found so precious after the dozens of job interviews I had had. They want to keep their way of working, their everything. And they see a need for change, too.
This is how far I got at my first attempt at drafting this post. I had no idea how to finish it. I escaped into reading further blog posts on how amazing it had been to work at Github. Then I remembered.
I was an anarchist myself. I was a proponent of the idea that people do what they want and nobody tells them what to do. Hierarchy is something I’m against at a gut level, I’ve always had an issue following orders just because they came from someone considered an authority. If they had a proper reasoning behind, I’d be happy to follow. Once, I was invited to a poche event where I was supposed to shmooze with a C-level guy who hit the boring record of the decade. So I had a great time talking to the security guard instead.
Anarchism is the ideology on which we based our startup with my friends. Do you want to hack together a framework that persists our business objects to the database? Go for it. Do you prefer figuring out the finer details of what the customer actually needs (as opposed to what they say they need)? Go ahead. Our little enterprise grew to five, then to nine people.
We loved working there. I’m not saying we loved every minute; there were minutes we hated, even hours and days. When our application turned out to be pretty slow in production, it got us excited to find the bottleneck. We applied an approach from theoretical physics to identify the culprit. Two weeks of stubborn research gave us zero insight. The project looked a lot less sexy now, the database guy felt how strong his beloved objects were pulling him back, the customer guy had some urgent calls to make. The poor project was left alone, nobody loved it any more. We, the anarchists were standing there, but none of us had the authority to say, “go and fix the damn thing.”
Did we fail, because we didn’t have the right methodology? Or was it due to our fallibility? I couldn’t tell. I joined Prezi to learn their secret how to run a self-organizing company of more than a hundred people.
Prezi is a presentation software that was built on Flash, a stone-age technology whose days were counted. We could see the black clouds approaching from the distance and the smartest engineers on the team could estimate how long it takes for the thunder to arrive and to wash away our daring enterprise. We had to say goodbye to Flash and embrace JavaScript. Easier said than implemented. It’s not one of your hackathon projects to rewrite a complete codebase.
Our CTO drummed together all engineers and introduced his plan. It was only a couple of skewed rectangles on the whiteboard, but he’s an inspirational guy who can fill in the gaps. When he asked for volunteers at the end, a dozen hands popped in the air. Then a few more. He smiled and said, “Thank you, that’s enough for now. We’ll show you in two weeks what we’ve got.”
The swat team sat in a separate corner of the room and they showed in two weeks what they’ve done. It was wow. Wow squared. Now I saw I had joined the right company. Self-organization works magic.
The next demo was less impressive, they didn’t make much progress. They ran into some technical difficulty with the canvas or the rendering algorithm. Yeah, we all know programming is a minefield, unconfirmed sources mention even dragons here.
Two months in the project, the CTO gave a presentation to the whole company. The presentation still used good old Flash. The takeaway was, “zooming is hard.” I remember this phrase because I heard it at a few other presentations that followed.
It was a two-year heroic struggle that happened to result in a failure. It would be unfair to summarize it in a few slightly sarcastic paragraphs. But self-organizing teams of brilliant engineers couldn’t solve the problem, that’s for sure.
I could switch to wise-old-man mode and say, “Anarchy? Been there, done that. It ain’t working.” But you can give many explanations for the failure at Prezi. Maybe it was really due to technical difficulties or to a lack of clear product vision or to the Moon entering the sixth house on the night the project was launched. As many participants you ask about the reasons as many different opinions you’ll hear. I assume it’s normal behaviour on failed software projects or on any failed projects for that matter. Some even argue it was not a failure. It didn’t bring the company to its knees, after all. You’re safe to call it pure learning and get away with the logic of “what doesn’t kill me, makes me stronger”.
Why am I putting so much energy into how the organization works? I’m going to be a product manager (pardon the M-word). I should be focusing on the product. Monday: talk to customers. Tuesday: update the backlog. Wednesday: Triage the issues on github. Thursday: scan the wider blockchain landscape. Friday: attend the demo and give impartial feedback. But I have a number of reasons why I’m focusing on people first.
- “People” comes before “product” in the dictionary.
- These people already know a lot about the product. They know how it works now, how it’s used. They have a vision. The individual visions may be different, but there must be an overlapping area that’s worth exploring.
- It’s motivated people who implement the product. I can’t tell them, “hey, our customers want to build a Blockchain-based Burger App on Ethereum, go and implement a burger-protocol.”
My ultimate reason deserves its own number one.
- Ethereum is the best known technology to create a world of decentralized information. A world where a politician can’t say, “oops, I lost the pendrive with the list of secret agents and I have no copy of the data.” We don’t know yet how that world will work. I have my interpretation of Conway’s law. The organization that creates this technology and the Ethereum platform itself shape each other. The dynamics of the team will show in the product. Product decisions will be reflected in how the team works. We have to find out our special way of working together that suits only this team and this product. In blockchain lingo, our team structure is a nonce.
