I am sure you heard this in your chats, especially if you come from the Enterprise world:
I am fed up with the amount of bureaucracy in the Company! I need to jump through so many hoops — it is unbelievable. It is slow and inefficient, why can’t I just go and do what I need to do.
Then, I am sure there is something like (funnily, sometimes in the same chats):
Omg, they broke it again! That other team is so irresponsible and careless we can’t work in such conditions. Everything we do for them is getting destroyed!
People get upset by either being a part of a system with too many rules or when there are no rules whatsoever. Let’s discuss what is better. By the end of the article, I will give you the answer and not that neutral tasteless crap that both systems are good and must be used when appropriate.
But first, let’s establish the vocabulary.
Freedom & Responsibility
Widely known job culture promoted by Netflix. The “use good judgment” concept is very liberating. The people are expected to act themselves in the interest of the company. That’s something that has no strict definition — do what you must to make the company thrive. Clean up after others, don’t make a mess yourself. Oppositely to the process-centric systems, the people are the most important part.
It does not mean that you as a developer can do whatever you want. You are expected to contribute, you are expected to act as if the success of the product you work on matters for you personally. You must contribute to the final goal as much as the people around you. This can be a lot to take in, especially, if you find it hard to truly care about the product you develop.
Okay, that’s for hippies, got it. What about the people in suits?
Command & Control
Command-and-control is a style of leadership that uses standards, procedures, metrics, and KPIs. Interactions between different units of business are strictly regulated and formalized. There are playbooks, runbooks, acceptance criteria, quality bars that define the input and the output of each individual.
What does it mean for the developers? Well, it means that they can’t bring the wild chaos of FOSS if they are used to it. The developers will be expected to work within the well-defined rules. Yes, the rules themselves might be ill, but at least they are well-defined. Usually, to the point of “you may or you may not create a pull request”. You just get a ticket from the work queue, resolve it, get the next one — the perfect assembly line.
Sounds scary, boring, and you don’t want to be a robot? Hold on the judgment, CC also means that you know what others bring to the table. You know what to expect as an input, you know what to produce. This means work comfort, predictable workflow, and less guilt if something goes south. You can always say “I did my part” and that will be true, not just relieving yourself. Have you ever been in a situation when you got the blame for someone else’s mistakes? Well, that is not going to happen in an assembly line.
What we practice
I can openly say that my Company is heavily into Command & Control. The developers’ factory.
We have playbooks. For example, the playbook for my position is a 50-page document of rules, orders, and standards. By reading the playbook I know what to if I find myself in a situation X — I need to open that ticket, create this document, and send it to these people.
We have quality bars. Whenever I produce any unit of work (in my case it is an architecture design document) — I must go through several extensive checklists to verify that I haven’t forgotten anything and that I did all the work that is expected from me.
We have SLAs — I need to complete my work within a predictable amount of time, I need to produce a certain amount of architecture design documents.
We have metrics. Metrics for every single thing. For what you deliver as a team member, for how focused you are, how aligned, how intense you work. You are constantly compared with others. The pressure is real.
We have restricted communication. Whenever someone has a question for me — they need to open a ticket for me to answer. Ha, we even have quality bars for these tickets — if the question is not formulated properly, I can just ignore it. I am not a chosen One though, whenever I want to ask a question — I also need to open a ticket, and oh boy should I do it right without missing a field in the ticket.
We have documents. Well, to be honest, I don’t think we have too many of them, it is not that overflowing here. Yet, for one product there could be a fair hundred of documents, not to mention wiki pages.
We have horizontal teams. That one is kind of new, I haven’t seen anything like that in other companies. What is a horizontal team? Well, imagine having a team of developers whose sole responsibility is Code Review. The team browses the Company’s organization in GitHub and hunts the open pull requests. Then, they review the changes in the pull requests, leaving their agnostic comments. The PR creator then must adhere to the comments.
What is so interesting about this? After all, nowadays, everyone does code review. The catch here is — the Code Review team does not care what repository the PR is for! Our organization in GitHub is soon to hit 20,000 different repositories and the Code Review team handles pull requests to all of them. This sounds crazy but that’s the idea of the horizontal teams — build teams around one single function, let them master that single function, and then apply it widely. That’s the opposite of the vertical teams or product-centric teams. In the classic vertical teams, people gain expertise in the domain of a single product, whereas horizontal teams focus on functions.
We have separate teams for Unit Tests, Integration Tests, Performance, UX, Feature, Architecture, Cleanup, etc. You can make an analogy with American Football where each player has a specialty and probably sucks at everything else.
I love the idea of horizontal teams, it allows you to truly master one single thing, instead of being just good at many. It also allows the responsible team to gather extremely deep knowledge of that particular function.
There is a big problem though. You will get bored doing one thing only. Inevitably. You will grow an unbelievable disgust to writing unit tests if you were ever a part of the Unit Test team. This is why I believe it is healthy to rotate between teams once in a while.
My Company runs all of that, it truly believes in the assembly line, processes, and documenting everything along the way. I have been a part of it for almost 5 years now, so confidently let me share what I have on it.
Takeaway
Good things about CC:
- You know your place, your responsibilities and everyone else also know that. There won’t be any misguided blame. There won’t be any mistreatments.
- You are getting good at what you do and unbelievably so.
Not so good things:
- The work feels dull and uneventful. You know that today you are going to do the same literal thing you did yesterday.
- Creativity is what?
- No, you are not welcome with your ideas and opinions.
Horrible things:
- You are good at a single thing, but you don’t feel confident that you can do something else anymore.
- If you ever had loved your profession, this love will be killed by processes, standards, and forms.
Well, what can I say… For sure, 100% the next company I join must be running Freedom and Responsibility. I completely fed up with satisfying the process, not what makes sense. I want my work to make sense, not just being an input of someone’s else work. Again, probably you can find peace in highly organized companies if you want order and predictability. I believe though it is a path to nowhere.
Run the “what would I tell my kids about what I do at work and why it matters” test on yourself and see for yourself.
