An introduction to programmer’s anarchy

An introduction to programmer’s anarchy

An opiniated vision of how we should stop spending time on useless coordination strategies.

Project management sucks. Period.

We spend so much time trying to fix broken things that we often even forget what we’re trying to achieve.

Let me tell you some personal stories. I’m an entrepreneur. I have been working on large scale IT projects for the biggest companies you probably can think of, for typical deal sizes of a few million euros. Oh boy, we spent so much time trying to figure out what to do using a mix of traditional V cycle (the big companies stuff, whatever they say about agility) and more agile methodologies (our stuff as a startup, right?).

More often than not, the large corporate customer always includes many people in the loop: IT, security, business, legal, procurement, etc. Each of them has a specific mission and goal. They genuinely think their job is to de-risk the project. But in doing so, each layer adds more complexity and breaks your agile manifesto.

In the end that makes IT projects go south much more often than they should. It means we all go by the lengthy and old-school deliverable process and the customer always add more exotic requirements and lowers the price. People work hard, spend time in meetings, write documents, review documents, review tasks and backlogs, test and complain, escalate issues in more meetings, ask for new project plans to adjust for delays, the customer does not provide the information needed, people complain about the last contingency plan, your sponsor gets bored, you get bored, your investors get bored. You just realized lost several months of your life trying to reconcile demands that are mostly incompatible, when they even make sense. Most often, it also delays your sales. You make the most of your brilliant team to fix all of those issues, one after the other. But, day after day, it has become the opposite of agile, and that’s what I call delivering in pain.

Some of you might think that’s just because we did not use agile methods correctly. After all, project management done right should avoid all that. I don’t think so, I think it’s a more fundamental issue. This is happening pretty much everywhere where B2B is involved. Unfortunatly, this happens even when the C-suite is well aware of the problem. The corporate superstructure wins on any goodwill, because organisations are not used or able to understand/trust each other.

But does it have to be that way?

Meaninful work is key to meaningful results.

Stop fixing problems that shouldn’t exist. One solution is programmer’s anarchy. The concept has been popularized by Fred George.

To bring a more critical view, I would personally prefer to use another term. “Anarchy” is often connoted negatively in our everyday’s language. How would you call it? (please leave a comment).

Basically, the main concept is about removing unecessary layers and tasks. Even remove managers. Yes, you heard me right.

Decentralize and autonomize. A startup company should therefore be able to operate without the founders. We don’t need managerial superheroes, we need efficient teams. But how can that even work?

As Steve Jobs used to say:

It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.

And I would add another famous sentence to the equation.

Trust, but verify.

Don’t worry, I’m not talking about blockchaining your company. We can achieve that through many tools that already exist. But the important think to that people do meaningful work for themselves and in relation to their internal and external peers. You might for instance think of open sourcing as one great enabler.

From the startup perspective, this makes good sense:

  • At the operational level, let people decide and deliver on their own terms. People usually know what they should and shouldn’t do, better than you do. With great power comes great responsability; they need to commit themselves on it. If and when they don’t have the knowledge/skills/discipline, it’s your job as an entrepreneur to help them and act as an enabler.

  • To align with the customer, we should be story and even UX centric (instead of task centric). Ever heard about Amazon banning bullet points and replacing by memos? So, likewise, why do we spend so much time monitoring task by task?

  • As a leader, define/elevate the vision and find the ways to make that happen. Do what you say, say what you do. Say what you don’t/won’t do. Transparency is essential. It’s much easier for other people to trust you if you’re genuine about what you do. And it’s also the best way to keep your margins high. Don’t over sell. And after you’ve delivered what you promised, always provide some unexpected extra.

  • We don’t have so many resources that we can spend our life on inefficient coordination. Make time for what’s important and don’t get bothered solely by the priorities of others. Everything you do should be modular. So that you can maintain, improve it or even throw it away. Avoid technical debt.

  • Banish micro management. The good news is that your current managers will do meaningful work as well. Again. If you need information/reporting, that’s fine as long as it’s automated. Your programmers will be happier, not having project managers telling them what to do.

  • It helps you recruit and keep the best people. Not just programmers and UX, but also marketing and sales. Incentives are much more aligned.

But what’s in it for your customers? I’ll get back to that in future posts, but they basically get and perceive more value when your focus on delivering what you’re good at, and that only. It’s fundamental to (really) listen to your customers and understand their constraints, but not to abide by their agenda or respect their corporate condendrum. We need to reinvent how we, as startups, work B2B.

So let’s scale, focus on the big picture and deliver real and meaningful results.

How’d you like this article? If you liked it or learned something, please leave a clap!

Additional resources

Implementing programmer’s anarchy : a video.

How is programmer’s anarchy different from agile? A post.

An example of recruitement strategy: parity.

Make time : I suggest 2 interesting reads.

  • If you’ve won a war and become a president, it’s probably because you deliver. So read about Eisenhower’s matrix.

  • The make time book is also a good complementary resource.

In case you want a more academic litterature on the subject, drop me a comment.