The last 20 years have been for me colorful and amazing. Moving from one project to another, different complexities, different challenges. I’ve got the pleasure to model and grow some startups since day 0, one of them became unicorn, some resulted in pieces of software used by millions of consumers, others where just a failure. Every time I could grow professionally and as a human.
Starting in the pre-agile era, I understood soon that it was impossible to design completely a solution first and build a successful product later. I became a believer of continuous improvements, evolution instead of revolutions, iteratively defining on each step the next small increment.
Every time I joined a project, small or big, I observed and focused on coaching the team members to define by themselves since day 1, the next step to take. Well, let me tell you a secret, every time, I knew exactly in which direction they were going. That’s my north start.
In this article I will share with you the 3 keys points I consider in every decision I take, that define which kind of manager I am, which kind of companies I want to model.
- Reactive systems
I invite you to visit the https://www.reactivemanifesto.org to understand the meaning of each key factors…“Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.”
Understanding those principles I think I became a better Engineer. In the last years I kept on reading and reading the reactive manifesto, then one day I noticed that it actually doesn’t only apply to a product that engineers build, the text I quote before actually speaks more generically about Systems. Systems are everything, it could be your team, your company, your family, the society you live.
Applying those principles to teams and companies, I became a better manager.
2. Atomic persons.
The second principle will be a bit more complicated to explain. Differently from the first one, for which there was already a manifesto, for this second one for this one I will have to create one.
2.1 Lets start by talking about how Spotify could revolutionize traditional teams applying matrix management concepts to Engineering.
Every person in a team will have two managers. The product owner, and depending on his role, an expert in his domain.
This vision could look like innovative, but it is only a new model applied to very traditional roles. Developers, QA, UX, Devops. Lets go beyond. In order to do that, please read about the principle behind the success of projects like Kafa:
2.2 Mechanical Sympathy.
Many years ago, there were very well defined roles. You could be a developer or a DBMS expert, a Devops or a QA. Empirically, but also inspired by mechanical sympathy we understood that a good software engineer needed to go beyond their IDE. In the end their code must be executed right?
The same applies to the Devops. We introduced platform as code, and learned to commit the yaml the platform together with our services(see gitlab-ci.yaml for example or the kubernetes yaml). Again, a good software engineer couldn’t continue ignoring the platform that was executing his code.
The same applies to Quality Assistance. A few years after, Atlassian suggested in this historical blog that the role of the Software Engineer needed to acquire a new responsibility, not only software and data, but also QA. The traditional role of Quality Assurance needed to evolve to a more managerial process of Quality Assistance that involve himself since the definition of the features. Indeed a QA expert can have a different vision of how systems affect each other, and could give hints through Testing notes on how the feature should be developed. In the end the developer is involved in the testing process, and for big features, the whole team operate Blitz tests to try to break the feature.
As you may see the role of Software engineer become more central and multihedral. In my teams members I tend to coach the curiosity and need to go beyond their role. Of course there will be tendencies, some developers feel more backend, frontend, qa or devops. But each of them need and will know also about the other aspects of being a software engineer.
Apologies for the very bad quality of the next diagram. I just wanted to express one concept of quantum development as I like to call it.
As you may see, from a traditional team, or from the matrix management the traditional roles disappear for a more generic role. The software engineer.
3. In order to achieve reactive systems through atomic development we need to ensure balance. Balance is achievable ensuring decentralization.
According to AWS, “…decentralization refers to the transfer of control and decision-making from a centralized entity (individual, organization, or group thereof) to a distributed network. Decentralized networks strive to reduce the level of trust that participants must place in one another, and deter their ability to exert authority or control over one another in ways that degrade the functionality of the network.”
This text talk about networks, I guess if you arrived here, you understood, we bring the topic beyond and apply it to every system, teams and companies.
A monolithic center of operation or command will only micromanage and slow down the possibilities to scale. Let people take a central role in the company(atoms), allow them grow, share responsibilities, tasks, share the possibility to take decisions.
If you want your company to scale, let it be reactive, operated by atomic persons that take action in a decentralized manner. That’s what I call nuclear management.
A final note. I’m a CTO and apply this theory to what is the technical side of a company.
I see potential for companies where every C level coaches it members that take atomic responsibility on their area in a full-stack way.
