One day, someone proposes a change that could significantly improve the system. It could also cause a serious production incident if the assumptions behind it are wrong.

The first option feels responsible. The second feels efficient. The third feels dangerous.

But there is another possibility: instead of choosing between control and recklessness, you can build a system in which people are free to make decisions and mistakes are difficult to turn into disasters.

That is one of the central responsibilities of leadership.

Does freedom increase risk?

The honest answer is yes. Freedom can increase the risk of a bad decision. A person with ownership can make a mistake, choose the wrong design, or underestimate a consequence.

But control also creates risk. When one person reviews or decides everything:

• the team becomes dependent on that person;
• decisions become slower;
• people stop developing their judgment;
• the leader becomes a bottleneck and a single point of failure;
• responsibility and authority become separated.

The goal is not to eliminate risk. That is impossible. The goal is to decide where risk should be handled.

Should it be handled by one person trying to supervise every decision, or by the design of the system in which decisions are made?

What should a leader do?

The next dilemma is more specific. What should a leader do when someone is not ready to own a highly ambiguous problem? And what should the leader do when that person is ready?

The answer is not to give everyone the same level of freedom. Leadership should calibrate the level of delegation to capability, while helping people expand their capability.

A person who is not ready should not be left alone in the name of empowerment. They should receive support and a deliberate path toward greater ownership. But a person who is ready should not remain under the same level of supervision forever.

The difference between a junior and a more capable person is not simply that the latter can be trusted with a more ambiguous problem. More capable people also understand that errors will happen even when people are competent. They think about how to make errors tolerable, how to detect them early, how to avoid error-prone designs, and how to make sure the same failure is less likely to happen again.

Less mature environments often reward the person who did not make a visible mistake. Better environments reward the person who makes the system safer for everyone, including when their own experiment fails.

Limiting someone’s freedom while they learn can be good leadership. Turning that temporary limitation into the permanent operating model for the whole team is not. The goal is not to let the team decide everything immediately. The goal is to use each decision as an opportunity to increase people’s ability to own the next one. A good leader calibrates delegation today while deliberately moving the team toward greater ownership over time.

If there is no resilience, should failure be surprising?

Suppose a team is changing a system without enough tests, observability, rollback mechanisms, or clear ownership. The team is told to be careful, but the system provides little protection when care is not enough.

Should we be surprised when something breaks in production?

The incident may have been triggered by a person’s decision, but the absence of resilience is also part of the explanation. The system was allowed to operate without enough ability to prevent, detect, contain, or recover from failure.

This does not mean that every mistake is automatically somebody else’s fault. People remain responsible for their decisions. It means that accountability should include the conditions in which those decisions were made.

This is broader than boundaries around individual decisions. It includes non-functional requirements such as failure tolerance and idempotency, as well as the practical systems around the software: alarms, playbooks, infrastructure as code, deployment automation, and clear ownership.

Mature people do not merely try harder to avoid mistakes. They design systems that make mistakes less damaging, easier to detect, and faster to recover from. They also look for error-prone designs and remove them when they find them.

Care matters, but care is not a mechanism. If the failure was predictable because there were no tests, rollback, alarms, or recovery procedures, asking for more attention does not address the cause.

What about legacy systems?

Most teams do not start with a clean system and unlimited time. They inherit software that is difficult to test, difficult to observe, and dangerous to change. Safety mechanisms and resilience cannot always be created overnight.

That creates another dilemma. Should the team remain under permanent centralized control until the legacy system is safe?

The answer should be no, but the alternative is not pretending that the system is safe. The alternative is to make the risk explicit, reduce the radius of possible damage, and improve the system’s resilience incrementally.

Not having every protection yet can be a legitimate constraint. Failing to recognize that absence as a risk is a leadership failure. Refusing to prioritize resilience is an organizational choice.

The most dangerous situation is when the lack of safety mechanisms becomes a permanent excuse for keeping all decisions centralized.

How control becomes permanent

Centralized control often creates the conditions that appear to justify more centralized control.

The team has less capacity to improve the system because so much of its energy is spent waiting for decisions or implementing decisions made elsewhere. New needs arrive faster than the team can improve its safety mechanisms. The system never reaches the promised future state in which control will no longer be necessary.

The leader is not simply responding to the problem anymore. The control model is helping to preserve it.

Is freedom the absence of authority?

There is a mistake on the opposite side. A leader may decide not to control every decision, but also avoid using authority to create a functional environment. That does not create freedom. It creates a vacuum.

Someone will fill that vacuum: the loudest person in the room, the most political person in the organization, or an informal group whose decisions are difficult to challenge. The result is often consensus by exhaustion, not ownership.

The leader must use authority to stop the cycle of permanent control. They must set boundaries, establish priorities, clarify ownership, protect the team from unreasonable demands, and require the work needed to make the system safer.

A good manager sometimes needs to impose things. Authority is not the opposite of freedom when it is used to protect the boundaries within which freedom can exist.

This is why strong institutions can sometimes create more freedom rather than less. Rules and enforcement can make fair competition possible. The same pattern can be seen in China’s model: strong central authority has created a framework in which companies and individuals can compete aggressively within boundaries set by the state. The political model is not the point here. The point is that freedom in an area often depends on authority defining and enforcing the boundaries around it.

Good leadership is not the absence of hierarchy. It is clarity about who can decide, who must be consulted, who will be informed, and who deals with the consequences. I explored this broader idea in The problem is not hierarchy, but lack of accountability, including the role that clear delegation and delegation levels can play in making hierarchy work.

The leader’s authority should be aimed at making the team less dependent on the leader over time.

What does good delegation look like?

Good delegation is not asking a group to reach consensus on every decision. Consensus sounds collaborative, but it often turns decisions into religious discussions: everyone defends a preferred belief, the discussion becomes a bottleneck, and nobody clearly owns the result.

In a team with ownership, people are responsible for projects. They lead them, make decisions within their delegation level, report progress, demonstrate results, and share knowledge periodically. They ask for opinions when they believe another perspective will improve the decision, not because every decision requires permission from the whole team.

Ownership does not mean working alone. It means combining autonomous leadership with collaboration, expertise, AI, and other tools. The person who owns the work remains responsible for moving it forward, while the team contributes the best knowledge available when it is useful.

This model depends on the same premise as autonomy itself: systems must be resilient enough that a decision does not become a catastrophe merely because one person was wrong.

Before work begins, the leader and the person doing the work should agree on what success means. The task can have more or less ambiguity depending on experience and trust, but the destination should not be invented after arrival.

Good delegation defines the outcome, the decision level, and the ownership without prescribing every step of the journey.

What do we learn when something fails?

Good teams will fail. The goal is not to create a team where failure is impossible. The goal is to create a team where failure is survivable and useful.

When something fails because a safety mechanism was missing, the first questions should be about the system:

• Which protection or mechanism was missing?
• Why was it missing?
• Was the risk understood?
• Was the work prioritized correctly?
• What can we change so the next person can make a similar decision more safely?

Care matters, but care is not a mechanism. If the failure was predictable because there were no tests, rollback, or observability, asking for more attention does not address the cause.

Accountability is also not the same as control. Accountability means dealing with the consequences of a decision or outcome. Control means having the authority to direct or approve decisions.

When a leader controls the decisions but gives ownership of the result to someone else, authority and accountability become disconnected. I have written more about this distinction in Culture of blame vs culture of accountability.

Why this matters even more with AI

The need for resilient systems and explicit boundaries becomes even more important as teams adopt AI.

AI increases the speed at which people can explore solutions, write code, and produce changes. That speed is valuable only if the team can distinguish useful experiments from dangerous changes.

If a team cannot distribute ownership among people, it will not be able to distribute the use of AI effectively. Leaders will respond to the new technology by trying to approve every prompt, every generated change, and every experiment. The technology will be available, but the organization will be unable to use it at the speed it promises.

The better response is to invest in the capabilities that allow responsible experimentation: automated verification, clear data and security boundaries, review practices appropriate to the risk, and a culture where people share what they learn.

AI will not make centralized control scalable. It will make the need for resilient systems and clear boundaries impossible to ignore.

Good leaders create more leaders

The measure of a leader is not how many decisions they personally make. It is how many people become capable of making good decisions because of the environment they created.

Good leaders do not disappear. They set direction, define success, build resilient systems, resolve conflicts, and use authority to protect the boundaries within which the team can own its work.

They create more leaders by allowing people to practice leadership before they have perfect certainty. They make failure survivable. They make accountability clear. They keep improving the system instead of demanding that individuals compensate for its weaknesses.

The best leaders are not the people who remain necessary for every decision.

They are the people who make more decisions possible without them.

Many of these same companies also claim they have a culture of accountability and meritocracy.

Is it contradictory to say you are accountable if you’re never to blame?

Read on to see a clarification on these concepts.

It’s very common to find companies who claim at the same time that they have both an accountability culture and a culture of no blame, I wonder whether it’s just because negating any of the affirmations would sound like bad advertisement, and no one would intentionally do that.

A very common mental model is also that “the team is responsible for the tasks, but the manager is ultimately accountable for anything the team does”.

I wonder people to hear or even say these things actually understand the concept very well. Let’s dive deeper on what these things really mean, and from that it should be easier to discuss the different.

What is really accountability?

Accountability is dealing with the consequences of. You’re accountable for a decision or for a task execution if you’re the one who deals with the consequences of such decision or task. Responsibility is actually executing the task or making the decision.

If someone else made a decision, but you are the one who has to deal with the consequences, you’re accountable and that someone is responsible.

The same way, if you executed a task, but someone else dealt with the consequences, you were responsible, but that someone else was accountable for the execution.

Sounds simple, uh? Let’s see.

What accountability is not?

The first myth we must clarify is “the manager is always ultimately accountable for anything the team does”. At a first moment, you can make such statement and think it’s the same thing - but that’s not always true!

You’re paid to do a job. You receive your salary and someone else needs the job done. For example, imagine you hire someone to change the floor of your house - you’re paying that person to execute a job, so that person will be responsible to do it, but you will be accountable for a job badly done.

But what if you come to the person you hired, after agreeing a price for the job done, and tell him or her how the floor should be put? “First, do the corners, then the middle”. You’re accountable for a floor not put correctly, but your decision caused the person you hired to have to work the double for the same price. At this point, that person is being accountable for your decision -> you’re responsible for making a decision and the person will suffer consequences of a bad decision.

A more real analogy is a software team where people might have to do extra hours to maintain things working. If you have to maintain a software running and you have to wake up during the night to fix it, you’re being accountable for the decisions made when that software was built.

What blame really means?

When you’re accountable for something and other person was responsible for it, it’s human to tend to blame the responsible person for something you’re having to deal the consequences of.

But what is to blame? To blame is to accuse, to apply a penalty, if people responsible for something don’t do it right. When you blame, you’re somehow forcing the responsible people to have consequences for their acts.

And why is it a bad idea? Why no body likes to work on a company that blames? Here are some reasons:

• It’s human to make mistakes, we can’t be expected to be right 100% of the time and never fail
• Many times the responsibility is shared. You got the task, but you couldn’t do it because of other dependencies that have nothing to do with the task. Very often there are legitimate reasons why the failure happened.
• The failure could be consequence of taking risks - any project has risks and blaming people every time a risk becomes concrete will only make things worse.
• Blame can be very toxic on a workplace and make people not enjoy their job

So that’s why we don’t want to blame people in the work place - it’s better to focus on fixing things and learning from our mistakes, than to focus on the negativity of blaming, which will only create disengagement from the team. Very often, the solution is a new mechanism or a new form of organization.

What blame is not?

Blame is not stating that people made mistakes, or that a decision was bad.

I often see people confusing lack of blame with lack of accountability - so let’s make something clear - you might not be blamed by a mistake of yours, but if you made the mistake and the decision was yours, you’re still responsible for it.

If you were trying to solve a support issue and you deleted the customer from the database, you would be blamed if you were fired because of it, or if you were suffering any kind of penalty because of your action. Not being blamed means it’s ok to make mistakes and you can do it without being afraid of these penalties, BUT… You’re still responsible for the mistake.

And why is it important to acknowledge a mistake or a failure some times? Because otherwise, it’s impossible to learn from it and very likely, “not being a culture of blame” can be used over and over as an excuse to make mistakes.

Characteristics of a toxic blame culture

Funny enough, I often see environments where people frequently claim “not being a culture of blame” to be the ones with the strongest culture of blame, because many times it’s used as an excuse to avoid accountability.

In a toxic environment, responsibilities are loosely defined and it’s unclear who is hold accountable for what. This is the perfect environment for making decisions or mistakes and hold other people as accountable for the mistakes you make! Even when people don’t blame each other directly, if there is no clear boundary line showing when the responsibility of one ends and the responsibility of the other begins, it’s very easy to hold people accountable for mistakes made by others.

It’s not a direct accusation as per say, but when people are not correctly hold accountable for what they do, things don’t work and at some point there are consequences. This consequences can come in the form of bad evaluations, not acknowledging good results - it’s the kind of environment where you’re there to be hold accountable in failure situations and in success situations it’s someone else’s success.

That’s what you should pay attention on when you analyse the company culture - everyone will say they are not a blame culture - but are responsibilities well defined in the place you are?

• Are you waking up in the middle of the night to fix problems you never generated and you have no control over?
• When you join a tiger team to solve a problem, do you usually feel you’re under performing when you’re actually going beyond your boundaries to help others to solve a problem?
• When someone makes a team decision that didn’t work, is it spoken as your failure?

Pragmatic summary

Although blame can make a culture toxic, unclear boundaries and lack of accountability can make it as toxic or even more.

A good work environment has clear responsibility boundaries

From my experience, environments where there is no clear division of responsibilities are closer to a culture of slavery, where some people can benefit over the property of others - the product of their life and their freedom. Free people should own the results they produce. It’s great not to blame people who try and make mistakes, but to be blind to who was accountable for which result is immoral to say the least, and I would say very toxic.

If you want to know what kind of culture a team has, one of the first things to ask is how the responsibilities are split - If boundaries are not clear, this is a really bad sign.

• Choose environments to work where the culture is not a culture of blame,

BUT

• Choose environments with a culture of accountability, where you will be hold accountable for what’s in your control.

Bear in mind that doesn’t mean you have to limit yourself on doing just on what you’re responsible for - very often you will go beyond your responsibility boundaries for the good of a delivery or the product - but this should be seen as what it is - you doing more than your responsibility, as opposed to feel you’re doing less if you don’t fix everything.

A good work environment has accountability close to responsibility

I think this is the right definition of a meritocratic environment - an environment where you’re seen according to what you have control over.

Spiderman rule: “with great power it comes great responsibility” - ideally, you should be hold accountable for things you’re responsible for.

If you are a manager and your team will have to get the burden of support operations when software is badly written, then don’t make such decisions, delegate them to the people who are being accountable - the more they are there when it’s needed, the more they should have the right to participate in design decisions.

Managers can actually use this to support their delegation decisions on anything - before you decide who to delegate or whether to delegate, ask yourself - who has the burden when things go wrong on this?

When you have part of the team designing and creating the software and the other part fixing their bugs - this is a really bad sign. You build it, you own it - be accountable for the decisions you make.

Conclusion

Hopefully this article made you think. I don’t expect people to always agree with me, but my intention with articles like this is going beyond the surface, diving deeper on company cultures and why things are the way they are.

Then the company board fire Sam Altman, who was in the lead.

Short time after, 505 of the 700 employees tell the board to resign.

What can we learn from this?

One of the worst mistakes I made in my career was to follow a path to work on a dream company. I really wanted to work in some companies, which would present a chance of causing an impact and create a great product.

During my journey, I kept improving myself and worked in many companies, knowing a lot of people of value along the way. But at the time of choosing the next opportunity to work with, I was always led by the product, by the vision of what could be built, like in this video from Steve Jobs in the early days of Apple. I could find myself saying the same things these engineers are saying in the video.

Years have passed and I was finally able to work on one of the dream companies I wanted, it’s the product I wanted to build and I started so excited. Result? Worst disappointment of my career.

The company wanted to build a killer product, but the wrong people were leading it. Nothing worked as expected and my only regret there was not leaving earlier…

Then you see the example of Open AI stated above, where most people seem to be keen to change the company at any time, but keep following the leadership they believe at. Now I watch again the Steve Jobs video above and I see something different - the engineers were not just following a product vision, they were following Jobs, who was leading the way to that vision and made them really excited in building it.

What these people probably know and I took so long to realize in my career is that

companies are just the recipient of a chemical reaction, it plays a very small role on which reaction will happen. What really matters to get an explosive reaction are the people - they are the ingredients that make that reaction to happen.

And how does that translate to practical actions?

Very recently a recruiter called me and asked whether there was any company I was interested in working at. I basically explained my mental model shifted to wanting to work in companies I like, to wanting to work with the people I like.

So here is my suggestion to you: next time you’re looking for a job, when you’re interviewing, ask the questions that will reveal to you who the people who will be working with you are, check whether they think like you, whether the mental model aligns, see how they think, what motivates them. If these things don’t match, it’s very unlikely all the rest will be of any help - you named it: language, technology, product, vision, tools, process… none of these will matter anything if you’re working with the wrong people. On the other hard, if all that is not ideal, but the people working with you are the right ones, then everything can be sorted, whatever is not good can be changed or evolved.

I learned the hard way that the people are the biggest asset a company can have, and I hope this article was useful to you to make you think about that next time you’re interviewing.

Best of luck in your jorney!

In the organization you work, have you ever thought about how much the decisions you make cost? Have you ever stopped to calculate the cost of over engineering? Or the cost of developing a solution that doesn’t actually solve the problem it was supposed to?

This article introduces the concept of requirement pyramid, showing how to incorporate it to your mental process, to avoid huge unnecessary costs when solving problems.

The article focus on software development scenarios, but the concept is not limited to that and can be applied to a variety of situations in life.

Intro

Once upon a time, there was a very high skilled developer, with knowledge in dozens of technologies and programming languages.

One day, a prospect customer appeared asking him to quote a software to book appointments and show reminders to her employees.

The developer quoted a full fledged solution, split into multiple microservices domains, running a very rich and responsive UI in browser and mobile, with alerts, logs, dashboards, admin interface, services running in the cloud and a very nice configuration screen.

Later on, the customer comes back saying another quote was accepted: someone else had quoted creating a script that would automatically send an email to every employee in the beginning of the day with the daily agenda, solving the problem costing 1% of the price to develop, and less than 1% of the maintenance price.

This scenario is very common and every day, similar scenarios happen across multiple development companies around the world.

Have you ever lived a similar situation?

The pyramid

To understand the concept of the requirement pyramid, we must understand what requirements are. First thing to notice is that requirements are very often not the problem you want to solve, but solutions to a higher level problem.

For instance, suppose you want to buy new clothes, and you’re short on money. Here are some possible solutions for this problem:

• You can find a way of getting more money
• You can stop using clothes and decide to walk naked
• You can use the internet to search for many places selling clothes for you so you can find one that suits your taste for a price you can pay.

So, in the beginning, you had no requirement, you had a pain, a job to be done - your clothes are bad. That’s the top of the pyramid - the original pain. When you decide to solve this pain, you very likely dive into a new set of problems or pains.

In the example above, suppose you decide you will search the internet to find new clothes to buy. Here are some things you could do:

• You could spend hours searching for new clothes in the most used online store website on internet, that has agreement with multiple clothing vendors
• You could spend hours searching for new clothes in the most used search engine website on internet, enter on each vendor website and search for clothes in there
• You could write a python script that scans a set of stores of your choice, finds the clothes that meet your search requirement and filter by those, generating a report with the best candidates for you to select.

So, here is the second level of the pyramid - you decide to solve your pain with one of the above solutions, so the chosen solution is your second level of requirements. Just to make things interesting, suppose you chose the python script solution.

Now in order to get your python script running, you need to install python, set up your environment, and you have many options in there:

• You could use pip and pipenv
• You could use pip and requirements.txt, without a virtual env, installing dependencies system wide
• You could use conda
• You could use docker and install everything on docker, then use docker run

We arrived to the 3rd level of requirements, which is already digging into details on how to implement your solution. You could have even more options, you could decide to filter manually the results in the report, or you could output a spreadsheet that would allow you to filter stuff, etc.

Finally, you implement your code and run your script. Based on the output, you find the clothes you want, then you buy them, solving your problem. You’re at the last level of the requirement pyramid now - the thing that actually solved the original problem.

Thinking about this example, we followed a branch in the tree of possibilities with the many choices of solutions on every level, and for this branch, the more we approach to the bottom, the more complex things become. It started very simple - you need new clothes.

The second level was more detailed and the requirements were already more complex - it ended very complex, with more things to consider to make a good decision.

The third level was almost the design of a software.

Finally, the forth level was the implementation of a running software, that took most effort of all.

That’s how the final pyramid would look like:

Pyramid Properties

• Simplicity vs. Complexity: The higher you solve a problem in the pyramid, the simpler the solution is likely to be. Conversely, the closer to the bottom, the more complex the solution becomes.

• Risk of Over-Engineering: The more levels your pyramid has, the greater the risk that your solution might not completely fulfil the original need. An extensive pyramid may suggest over-engineering, hinting that there might be a simpler solution closer to the top.

• Solution Efficacy: Pyramids with too many levels can overcomplicate the solution, while pyramids with too few levels might indicate that the problem isn’t fully addressed, unless a very simple solution is actually adequate.

• Cost and Effort Considerations: Complexity can be understood in terms of cost or effort. Aiming to solve problems with the shortest requirement pyramid possible is usually the most efficient approach.

Are you looking at the top?

In real life, we receive requirements all the time, from a variety of people. The bigger the organization is, the farther you probably are from the original need, and the less vision you might have of the original pain that causes your salary to be paid.

When a task is assigned to you, it’s always good to question yourself whether you’re looking at the top of the pyramid or what the top of the pyramid is. Some times, the top most requirement you are able to see is a pain being solved, but if you dive deeper, you figure out you’re looking at a sub-tree of the bigger decision tree above.

For example, suppose at the top of the pyramid you see, you see the need of a catalogue listing all the microservices that exist in the company you work, as you have the pain of needing a service and you can’t easily find the one you need, because you don’t have a list, and you’re often having to speak to every one in the company to find the service you can use.

This looks like a top level pain at the beginning, but when you ask yourself why you need to find that service, you see you’re not looking at the top.

It’s essential to consider this in practice, as if you don’t question why, you could be missing opportunities for simplifying solutions. Some times, and I can say this from experience, the whole project you’re working on might not be needed, and you could be spending your time to cause a bigger impact.

Are you looking at the bottom?

Imagine that, instead of creating a python script, you were using AI to find the clothes for you. Or you were using an existing tool for that.

The overall complexity of the whole solution would still be bigger (AI is such a complicated tool, for example), but the cost might not be, as as someone else could be taking responsibility for the complexity of the tool you’re using.

Using existing tools instead of reinventing the wheel can make your cost smaller and your effective requirement pyramid smaller

Be aware that using external tools will make your solution easier, but not necessarily simpler. For a more detailed deep dive on these terms, I recommend the great talk from Rich Hickey, the creator of Clojure language, Simple Made Easy.

Understanding Your Position in the Pyramid

The level of the pyramid you occupy is not just about your role; it’s also influenced by the type of company you work for. Startups may find that roles are less defined and more fluid, with individuals covering multiple layers of the pyramid. In contrast, larger companies tend to have more defined roles and clearer separations between layers.

• Startups: If you’re in a startup, you might be wearing multiple hats, covering tasks from strategic market alignment using the Jobs to be Done framework (there is also a book), down to the nitty-gritty of feature implementation. Agility and adaptability are your allies here.

• Larger Companies: In a more established company, your position in the pyramid likely aligns with a specific set of responsibilities. Leaders focus on market needs and strategy, while individual contributors tackle the execution details within a defined scope (specific levels in the pyramid).

• Accountability and Communication: Regardless of company size, know what you’re accountable for, and maintain clear communication channels. This is crucial to ensure that the company’s strategies are well-informed and its operations remain efficient.

Thinking about the pyramid is useful for the managers, because by having clarity on the pyramid they can see how their levels of responsibility are being solved, so they can easily spot when cost was assigned to solve a problem, but in practice it’s going to a direction it won’t solve it.

For the engineers and people responsible for the bottom layers, it can be useful to see layers above, so the solution is focused on the problems that exist, without trying to over engineer and solve problems you don’t have. It also can help you to know when to escalate when you’re solving a problem in the last layer, but you see a better way of solving it in a layer above.

By understanding your role within the requirement pyramid—factoring in the size and nature of your company—you can better align your work with the overarching goals of your organization.

Practical Applications and Steps

Implementing the Requirement Pyramid framework in your workflow can streamline decision-making and ensure resources are optimally allocated. Here are steps to incorporate it effectively:

1. Map Out the Pyramid:
   • Clearly delineate each layer of the pyramid specific to your project.
   • Place the core problem at the top and arrange secondary issues accordingly.
2. Align with the Core Issue:
   • Regularly refer back to the top of the pyramid when making decisions.
   • Use the pyramid as a visual aid in design and strategy meetings for alignment.
3. Leverage Existing Solutions:
   • Before building a custom solution, explore if existing tools can meet your needs.
   • Weigh the complexity that each tool brings against its benefits.
4. Maintain Big-Picture Awareness:
   • Ensure that every team member understands their role concerning the pyramid.
   • Promote a culture of checking if tasks are directed toward solving the core issue or merely a symptom.
5. Document and Communicate:
   • Keep a well-maintained documentation of the pyramid and the rationale behind chosen solutions.
   • Foster clear communication around how each part of the solution addresses a specific layer of the pyramid.

By regularly revisiting and refining the Requirement Pyramid, you can make more informed decisions, prioritize effectively, and ensure that your efforts are contributing to a meaningful resolution of the core problem.

If the amount of value we produce through products and services is bigger, we should have more value produced and money power would be bigger.

Note: This is actually production, not productivity, but without diving deeper in the details, a bigger production for a nation affects its productivity, as the amount of people in the nation is constant and a bigger production implies bigger productivity.

But when we look at the micro level, is this actually happening? Does it work as supposed?

Keep reading to find out my ideas about.

Once upon a time, there was a rich guy, who hired 100 people paying 100 pounds per day. He ordered everyone to dig a hole in the ground, for 1 month (30 days). 1 month later, he had a huge hole of the size of a football field, and he put that hole for sale for 300.000 pounds. When confronted about what would people do with the hole, he argued that he had paid 100 people paying 100 pounds per day for 30 days, totalling 100 * 100 * 30 = 300.000 pounds, so that’s what the hole was worth.

That may sound like a small or ridiculous thing to many people, but the idea described above is many times adopted by many unconsciously, as it might be part of a mental model transmitted through culture over time.

That apparently inoffensive idea can greatly affect everyone’s quality of life. I remember how it was working 13 hours a day when I had this routine in my life, it affected my health and stress a lot. Many people I know embrace that life style and religiously think that labour is good for the human being and the more people work, the merrier. But when after living other work experiences when I was seeing better results while working the half, I started questioning that more strongly.

Years ago, I was once working on a company, where everyone used to work 13 hours per day, some times also on weekends. All people working there were very smart and capable, and even so, we were struggling to deliver working software that would allow us to advance more quickly.

Years later, I was working on another company, where the team was never deploying software on Fridays, nobody was working more than 7 hours a day, and surprisingly, we were generating a huge amount of value every sprint, and the manager got promoted as consequence.

Have you lived something similar in your work experience?

What were the main differences between these 2 situations?

Let’s brainstorm on these scenarios, checking what was different between the 2 team set ups to compare how much each factor can affect the production output of a software development team.

In this article, I list 3 factors: tools, the way the team works and mastery. After discussing each of these points, I discuss what we can change our mental model to and what practical actions we can take to be closer to the second example.

Tools

I think this is specially relevant nowadays, given everyone is talking about AI and how it could replace human beings. I don’t think AI will replace human beings so soon (not in the next 50 years), but I definitely can see tools based on AI increasing our production output a lot.

Using the right set of tools can definitely affect the amount you produce, and the trade-offs become hard when the tools that could improve your work still don’t exist in the market.

As a very simple example, let’s imagine for a second the time were you had to code in assembly to write some software. From that time to now, the market has created different languages, paradigms of programming, frameworks, that affect the amount of code we have to write to get modern software working.

Now, can you imagine, for a second, what would happen if we instead had tried to write modern software we know today in assembly, just by putting more effort to it, instead of trying to find new tools to help us improve the productivity?

We can’t check for sure the numbers, unfortunately, because it’s impossible to measure this, but I imagine that for writing a software like Microsoft Word, for instance, fully in assembly, you would take… 100.000 hours of software engineers effort? Of course this would depend on the techniques employed, how much reuse they would get, how they would test each part of the software, etc. But looking at this extreme example, if you had 100.000 hours of software engineers available and you could decide between:

• Writing Word from scratch, entirely in assembly, without frameworks
• Writing tools like compilers for a new language, libraries and frameworks, then using those to write the same software

Which option would you choose?

Consider not only the amount of hours, but that software is something you actually change over time. How many lines of code would you have to change, in assembly, to change a button that appears in multiple places?

I hope by thinking in similar extreme examples like this, it becomes obvious to you, as much as it becomes to me, that tools are essential for our job. I have no doubt I would choose to develop the tools first, and then to write the software. Write it entirely in assembly could even be possible and have a similar amount of hours in the short term, but in the long run, you would spend much much more on every modification.

Using too many tools can be worse

Now let’s think on the opposite example - you want to write a kernel driver for a new device that you created and that will communicate with the operating system by USB. Can you imagine trying to create the kernel driver using C#?

Trying to use a high level language for something that needs such a low level hardware dependent access would require way more effort than using assembly directly, keeping it simple. Imagine the amount of software you would require to be able to glue the output of C# byte compiled code with the kernel code…

So, it’s not about saying that using tools improve productivity - using the wrong tools can decrease your productivity instead. The secret is choosing the right one.

Using the best tool for the job is an essential factor to increase productivity.

But what if the best tool doesn’t exist yet?

This is very common is some big companies I worked in the past, as well as some very innovative ones, where they had a need that nobody else had in the market before, and you then realize that a specific tool would boost productivity a lot, but it doesn’t exist yet.

In this situation, you start considering trade-offs, you could be in a scenario where going without a tool would make you reach your goals faster, but after you reach your goal you’re not productive to maintain or pivot what you built. That might still be worth though, depending on the business benefit you get from reaching your goes faster.

It could be the case it’s better to develop a tool in parallel while you progress. Or it could be the case it’s better to create the tool first and then do the business work that will contribute to value, or it could still be the case you have to iteratively create tools as you go.

The best tool for the job short term might not be the best tool for the job long term

In all cases, we’re talking about another productivity factor, orthogonal to tools now: the way you work and how you prioritise the backlog.

The way you work as a team

The worst enemy of productivity, IMHO, is over engineering. Over engineering can be so bad, that a bad decision can just cause your project to fail, as although it might still be possible to overcome it, it turned the cost of going ahead so big that it’s not worth it any more.

To have good productivity, it’s essential to work on a way where you do not over engineer, and the decisions you make on prioritization of tasks, as explained in the prior section, can also affect it by a large amount.

Let’s again consider 2 scenarios, one where you do everything wrong and other where you do everything right, and compare the effort estimates. Imagine you’re on a project to build a billing system.

The bad way

In scenario A the team over engineer a lot: they first split the billing system in 3 micro services, and as the project advances they realize that was not what they needed, the domains should have been split in a different way.

The team built a library upfront to automate configuration, as configuring it manually was painful, so a library would save work. In practice, it was a wrapper over configs and when things didn’t work, they had to dig into a badly written library, released before it was really ready, and after 1 year that library entered the deprecation path, and the team was discussing in every sprint when they would deprecate that and replace it by a new one.

Then they built a new one and, after another year, that one was also in the deprecation path, because they rewrote the software, but made the same mistake in the way of working again.

The team had also some understanding of requirements upfront, and they developed the software based on their understandings, but the requirements kept changing over time and this was not only affecting productivity, but also stressing software engineers, who were dedicating so much effort to fulfil the requirements perfectly, to get frustrated to see changing requirements over and over again, figuring out a good part of what they built was designed for something else and it was perfect for the requirements they imagined, but now it looked like many parts could be thrown away.

Does it sound familiar to you? It’s impressive how many times I have seen the same kind of scenarios in practice, along my career.

The good way

In scenario B, none of these mistakes happened. The team didn’t work for requirements, they worked from the pain of customers, and instead of figuring out complex solutions to advanced problems, they often implemented workarounds and very simple solutions that would solve the pain and, although might not be perfect or ideal from one point of view, they were low cost and easy to maintain.

This team evaluated correctly trade-offs between creating technical debt and delivering useful stuff, and they would often deliver business value on every sprint, learning new things during each sprint that would avoid errors in the next one.

Do you want to know more? Please keep following the blog and other articles, I will very soon post more articles about this subject in specific on this blog.

The comparison

I would LOVE to have data to show you when comparing A and B, but it’s not the kind of data easy to get. All I can tell you is that, in my personal experience, this is how the production output looks like, over time:

So, initially, the productivity difference is not so apparent, but when the way of work is different, it can exponentially affect productivity over time, and the reason is that there is much less waste. That’s why all agile methodologies are based on that - eliminating waste, like over engineering, guessing requirements instead of understanding the pain to be solved, and bad prioritization decisions in general.

Making good decisions and eliminating waste affects productivity exponentially in the long run

Mastery of team members

Another factor that can affect productivity a lot is how good and independent the member of your team are. This is far from obvious, as most of the times this isn’t easily measurable - don’t expect that a senior team member will produce 10 times what a junior team member, that costs way less. Very often, what you see is exactly the opposite, the more experience the software engineer is, the less you see lines of code from him/her.

That said, having more experienced people in a team affects, among other things:

• prioritization - which can affect productivity
• risks - that often you only see because of experience
• trade-offs in technical design and in what tools to use / develop - which we already saw below that affect productivity
• the productivity of less experienced team members, reducing their waste
• business throughput - this is the harder to achieve, I think, and the most valuable one, it’s when you don’t affect productivity by reducing the waste or cost, but by increasing the value generated by the software you created. One interesting idea easy to implement can some times pay off years of development, all of a sudden.

The exception to this rule, is when people are experienced in doing things wrong. I know many people in the market who have years of experience in a subject, and they start thinking that is the only possible and correct approach.

Maybe the correct term here is mastery - which involves experience, but also humility and being open to new ideas, scientific knowledge, among many other factors hard to define. The fact is - don’t under estimate the difference that hiring better people can make in your team - trying to hire the “less expensive” professional that suffices for a role is something that usually plays against productivity, and not in favour of it.

Good engineers increase team productivity indirectly in many ways that are hard to measure

Conclusion

I hope this article made you stop to think in things you never have time to.

The key lesson to take here is that working more is not the main factor that can affect productivity. Even if every team member works 6 days in the week instead of 5, the output value you’re supposed to generate will increase by less than 20% max. If you work much more, but make bad decisions in the middle, it’s more likely your productivity will even decrease instead of increasing.

I have lived that in practice across many different jobs I had in my career. Factors as way of working, focus of the team on the right things, good decisions in general, these things usually affect productivity much more than increased effort, and usually the effect over time is exponential instead of linear, while you can only increase effort linearly.

So, here is what we can do, in practice, to actually increase productivity:

• Work in a way that eliminates waste of effort
• Focus on business value, not implementing software that perfectly fulfil requirements
• Hire good engineers - consider mastery when evaluating different engineers in the market - do not focus on hiring only the cheapest that you can
• Make good trade-off prioritization decisions or make sure whoever is accountable for such decisions are doing a good job and has everything needed to make such decisions
• Use the best tools for the job, considering that some times the best tool short term might not be the best tool long term
• Make over engineering your worst enemy, as it’s one of the most expensive forms of waste

Stop with the effort mental model - working hard affects productivity linearly, while working smart affects productivity exponentially.

Hopefully, this article contributed to change or confirm your mental model towards this subject.

I also hope that, next time someone tells you that productivity is low and therefore people must work more, you remember the ideas in this article - are your leaders being smart and pursuing business value? Or are them blindly pursuing effort, thinking the 2 things are the same?

Keep following the blog for more related articles in the future.

Or imagine you’re on a team, you have been hired to work as a software engineer and the manager gives you full autonomy upfront. You ask yourself whether you’re ready for this level of autonomy and whether you could benefit from mentoring - could it be dangerous to receive the autonomy without being ready for it?

Have you been in situations like this?

I have received questions like this after the last article I wrote, The problem is not hierarchy, but lack of accountability, and I think they are legitimate questions, so I decided to write this new one trying to clarify these points.

I will try to answer with my point of view.

Freedom rule

In the last article, I tried to express characteristics that good leaders have and I had defined them as more free.

To make the idea less abstract, let’s imagine a rule with 2 extremes:

• 0% free -> this represents a society that lives in slavery.
• X% -> this represents a society in an evolution process, like ours. I don’t know how much X is, because I don’t know how far from 100% we are.
• 100% free -> this represents a totally free society.

Non free society

What does a 0% free society looks like? Probably something we already know, as this has been part of human history - people can buy others, they neither care for each other nor they are concerned with others, they are concerned primarily with themselves and it they are good while others suffer, they are ok with that.

Can you imagine characteristics of people in such society? What I call “non-free” people are not the slaves, “non-free” is anyone whose mind belongs to such society. A slave owner fits in this kind of society, as he might be the one oppressing, but his mental model belongs to a society where people enslave one another.

So, we all can imagine a list of characteristics that individuals on such society have:

• They don’t feel empathy for others
• They need a ruler to be able to organize themselves in groups, where some obey and some rule
• They like to be served, not to do themselves
• They blame others if they can
• They are arrogant and don’t assume their own mistakes
• They are corrupt
• … can you think of more?

Free society

Imagining what a completely free society looks like is much harder, do you agree? We never lived in one to know what it’s like. I can try to imagine, and that’s what I am trying to do in here, but we are limited by our own biases… Our minds never lived in a free society, so we know we want to get there, but we can only imagine, guess, try and try again, evolve, until one day human kind can reach such state.

But what is a free society then? By definition, it’s a society where there is no slavery, so a society where people don’t enslave each other, they can organize themselves in groups, they can generate resources to share, be productive enough to generate these resources, without having to enslave each other in any way.

Even limited by my biases, I can imagine individuals who would live in this society would be like that:

• They are independent
• They can organize themselves in groups, either with centralized decision making or distributed
• They have clear delegation of tasks
• They are accountable
• They lead by example and generate more free people like them
• They are humble and open to new ideas
• They are honest
• … can you think of more?

These characteristics are my opinion, feel free to leave a comment here if you think it can aggregate to the discussion of how free individuals look like.

So, do you need mentoring?

We are probably somewhere in the middle of what would be a perfect society (you could argue it’s an utopia - I can’t prove we can get there) and a totally non free society. So, what’s the role of managers in software companies in the process of making the society better? Is it better to receive mentoring instead of receiving full autonomy?

From the point of view I am defending here, whatever helps you an individuals in general to get to the free society better, is better. That’s the metric we want to use, and it’s something really hard to measure. I think the practical answer is - it depends on who your mentor is.

If you have a mentor whose mindset is closer to the non-free society, it won’t help you, it will hold you. If you have a mentor who is closer to the free society mental model, then he will probably lead you by example and give you increasing levels of autonomy as you get ready.

But how can we know whether the mentor is a good one? That’s the tricky part - we have never seen a free society, so we don’t know!.

The best thing we can do is probably choosing mentors who are as far as possible from the non-free mental model.

And what if you go without a mentor? Well, keep focus on the vision - as long as you have clarity that the goal is reach the free mental model, you can yourself imagine metrics and forms of detecting whether you’re getting there or not.

Pragmatic tip: ask yourself, from time to time, whether the decisions you’re making are leading you and others to a free society

But what about corruption? How will society change?

You might be asking - ok, this is all good, but nothing will work while we have corrupt leaders, we have to eliminate corruption from the system, otherwise it won’t work.

That intersects with the fact that bad mentors will hold you back instead of moving you forward, and the same mental model applies. It’s useful to have a mentor if it’s moving you in the right direction, but hierarchy to hold you back is just useless.

Should we make a revolution then? Is the only way forward removing people from power and putting better people in their place?

I will leave it up to you, reader, to decide whether or not a revolution would be beneficial and move us to a better society - if you understand well the mental model in this article, you can think about it yourself and this is not a question easy to answer. BUT!

But I am confident that a revolution won’t ensure on its own that we are closer to a free society - you could have an oppressing power, then you remove the ones in power in the hope it will solve the problem, and the replacements which enter are even worse. We have plenty of evidence of this happening in many countries recently, by the way.

Remember that changing who is in charge won’t necessarily move you from non-free to free, you might just be changing the oppressor.

If you stop being a slave to be the enslaver, that’s not victory, it’s a defeat! You still in a non-free mindset.

What will actually change the society is a shift in the mental model of the population, so even people who are in power won’t want to be corrupt, as they will understand this is ignorance. If we think about more in deep, people who can enslave aren’t privileged, they are ignorant, as they believe they will be better by being the ones in power. That’s not true - you’re not better when you’re the ruler, you’re better when you don’t have to rule.

Compare it with the past - if you had a time machine, would you prefer to go back in time as a king, and have a lot of serfs? If the answer is positive, I feel really sorry for you and I hope someday the words you’re reading in this article touch your heart, but I can tell you I definitely wouldn’t. Being a ruler is meaningless for happiness, we are a tiny piece of cosmic dust, power is just but an illusion and it’s more likely it will control you rather than put you in control.

There is nothing better than living on a free world, and I wouldn’t exchange this by any power in the world.

So even if we don’t create a revolution against the corrupt people in power, we must come to the realization that society will change with a shift in people’s mental model - when they shift to a mental model of being free and wanting others to be free, their actions will change as a result, their acknowledgement of power will change, and the change will come as a natural consequence.

Please keep making comments

I hope this article was useful and hopefully it made the last one less abstract. I am still improving my write skills and I am touching subjects which are really hard to touch right in the beginning, it’s hard to remove abstraction when we’re talking about things so generically. I would love to be more specific and provide more examples, but some ideas really require a level of abstraction to be discussed. I want to do more articles like this, though, reacting to comments and getting deeper in the specifics of such situations, so we can raise the level of the debate.

I hope this reading aggregate something for you and please keep raising comments and questions - hopefully we will move together in the direction we all want, helping each other.

I start by giving context on the changes that have been happening in the last decades, then discussing about what is the direction the software market is taking and whether it’s the right one, to finally give you my opinion on what we should change in our work environments.

A little bit of history

Back in the day, when I left college, working as a software engineer was much more problematic, in average, in any organization, than what I see in the market today (as of 2023). The big enemy at that time was bureaucracy - software and internet were new things yet and nobody knew exactly how to manage software engineers.

That’s probably because long before the internet boom and the explosion in the number of software companies in the market, the management theories that dominated universities and companies were all based in the reality of car manufacturing factories. No surprise, the concept of “Software Factory” was really popular at that time. That caused many management theories to be based on designing everything first (like designing a car), then implementing it (manufacturing).

The idea never worked for software development, as usually the problem is completely different, you won’t produce the same code 1000s of times, each software project is different and it’s meant to be done just once. Also, if you create a car which requires much maintenance, nobody will buy it any more and it will get a bad fame in the market. That wouldn’t happen with software, as every software is custom, and I saw many companies profiting from doing a bad job - the more maintenance software required, more your customer would depend on you.

Then it came Agile. A completely different mental model that was very welcome in the market where you give more value to the humans in your team than to the processes you follow, designing the whole software upfront (waterfall model) was replaced by interactive processes, and architects and managers which defined everything and that thought that the main job of a software engineer was to right code were slowly replaced in the market by managers which would abdicate control of the team in favour of delegating more to the team members.

The concept of architect was slowly replaced by the concept of team lead, with Y career progression paths to staff / principal software engineer, where the role wouldn’t be defining every piece of the software, but to motivate and lead the team by turning them into more independent team members, who could make decisions by themselves.

All those changes in software development world came together with a set of political and lifestyle changes world wide, where thanks to internet, people could collaborate more to each other online, more participative methods were created where people who could never participate on decisions now could have a voice, through social media, influencing skills and much easier access to information.

I remember being on a software team a little more than a decade ago where we were discussing About big data tools and comparing Cassandra and HBase, and the main arguments in the team defending the first was that it was fully distributed, while the second had leader election based in Zookeeper where there would still be a central point. Although we were talking about technical data tool, it was embedded in everyone’s mind at that time that “centralized is bad, distributed is good”. You didn’t have to argue much, just defending de-centralization was usually enough to convince people whatever was the subject, being software, politics, or whatever.

I must mention the crypto currency fever as well - the whole idea of crypto was based on the idea that centralization is bad and everything will be solved if we decentralize stuff. Bitcoin was based on the idea that all economic problems were due to governments and central banks controlling economy and the idea of smart contracts was to automatize the law so no central judge would be needed for agreements, that could be logically programmed.

This makes sense if you understand that moment - we were coming from a world with little or no decentralization, there was a cultural movement for decades saying “centralization is evil” and our minds became biased towards it.

Motto in the last decades:

All decentralization is good, all centralization is evil

That was the dominant mindset for the last decades all around the world.

But what happened later?

The bad side of decentralization

Right after the positive feeling towards anarchy dominated both the world and also work environments, decentralization started showing some of its flaws.

Relying completely on the “majority” to decide what was right or wrong seemed like a good idea in the beginning, it seems the world is more free is people on the bottom have more power to make decisions.

Reality, though, is showing us a different story, unfortunately. The majority can go wrong and the fact something is incredibly popular not necessarily is an indication of being right.

We all want to live in a better world for everyone, but the assumption that a world where people in the bottom make all the decisions seems to have been a false one. Here is a small summary I can give of the general consequences of this in the last decades:

• UK decided for BREXIT by a referendum and now everyone regrets it
• Millions of people died during COVID pandemic due to misinformation
• Epidemic of fake news on internet
• Far right governments taking power all over the world, in many different countries with no recent history of that
• Historically reliable source of news losing popularity, slowly being replaced by social media and “conspiracy theory” influencers which were often put in the same level of reliability than specialists in many areas.

And these consequences are just the easier ones to see, but many smaller consequences have been happening in all levels of our society, including the workplace.

In Software Engineering world, I could testify countless teams where everyone would have the right of making a decision, regardless of experience, knowledge and specially results. Daring to make a decision on your own in the workplace became often interpreted as oppression, as trying to rule over others, as going back to the “architect model”, where some decide and think and some do.

Scrum teams and Agile in many companies became a synonym of “everything is decided democratically”. If you want a team to follow a single direction, you have to lead them into this direction, by convincing people your idea is good, otherwise they might just not follow.

There is a bright side on that - we definitely see less of that arrogant behaviour we use to see before agile, where people up in the hierarchy decide crap stuff and everyone else has to swallow, killing innovation and not allowing people to shine, to contribute with their own ideas. A DIVERSE environment is something great and I would argue it’s the only way to go, some problems are just to complex to be solved by a single mindset… If you hired a team to do some task and you want it done the best way, you have to give people the chance to make their own mistakes and also the chance of showing how good they are.

But unfortunately, in many workplace environments the full decentralization bring as consequences:

• Lack of direction - a member of the team is trying to create an elephant while the other is trying to create a duck. Both a duck and an elephant solve the problem, so the members fail to convince each other of following a single direction and you end up with an animal which is part duck, part elephant, part any other animals other members imagined
• Higher cost - even if you have a team member which knows which mistakes not to make, you have to let everyone learn that by failing themselves. While being allowed to try and to fail is important for your development, doing that for everything can be a problem.
• Demotivation - surprisingly, an unexpected outcome of everyone deciding everything is that very often nothing is decided and team moves very slowly, without the feeling of progress. Also, some ideas have to be implemented by multiple people, so if you’re unable to convince people to follow your idea, that idea might end up being dead, even if it was a good idea in the end. Lack of results is often demotivating specially to people who actually love what they do. Also, if you’re not working to drive results, why are you working? It would probably be better to do something you like instead and work less time, but more effectively.
• Non meritocratic environments - in the spirit of having a diverse environment where everyone has the same voice on decisions, you might not be acknowledging how better a specific team member is. And how do you define merit when you part from the assumption anyone has the same voice becomes non-obvious.

Again, I want to freeze how much freedom is something important to me and I recommend again taking a look at my previous article if you’re starting to think I am here to defend dictatorships. Really, it’s not. Please read this text with an open mind, as if you want people to be more free, it’s even more important to acknowledge the problems that come with decentralization - the first step to solve these problems is to accept the facts and resist the temptation to deny them.

Decentralization also brought us bad consequences. Fact.

Please take a moment to think on whether you agree or not with that - is it clear that this is a fact? A fact that many people I know will hate and to be honest one I am not super happy to state either, but it’s important to see it - reality is knocking at our door showing that some things went wrong, and trying to ignore this and just insisting in the mistake seems like a really bad idea.

But once you accept the fact, you might start asking: what was our mistake? And how to fix this?

What was our mistake

IMHO, the main mistake was to think that anarchy has only good sides and ignoring the trade offs that exist when you compare anarchy vs hierarchy. We can’t say we want to go back to what we had before, that is also bad or maybe even worse, but solving that problem might just be a little harder than we, as a society, initially thought.

Decentralization is not always the answer, at least not initially. Let’s take a moment to analyse these 2 forms of society organization, advantages and disadvantages of each one.

Also, we must have clarity on what is the problem we want to solve here. IMO, decentralization, ultimately, was trying to solve the problem of modern slavery. The reason why we didn’t like hierarchy in the first place was not how bad it was as a society organization method, the real reason is probably a mix of the following:

• We don’t want to live in a world where some rule and some obey
• We don’t want to live in a world where people in the top of the hierarchy can make crap decisions, damaging the lives of everyone, without having a mechanism to fix that effectively when it happens
• We don’t want poor decision making by the boss, where the top of hierarchy makes decisions based on things he or she has absolutely no visibility about. If you’re more than 40 years old and lived that age, you probably lived the situation at work where you knew what to do but you had to convince your boss that you had to do that. Why??

Looking at the disadvantages of hierarchy, anarchy seemed like a good solution. But when we experimented it, we learned even more about the problem:

• We don’t want poor decision making by the bottom. A news channel could be bad as information is in the control of few that can manipulate it, but sharing peer 2 peer news on whatsapp doesn’t make it any more reliable
• We don’t want to live in a world where a group of people can’t follow the same direction because no decision is made
• We want high productivity, driving results with minimum costs and motivating people to do their jobs
• We want at the same time give people the chance of giving their opinions, but at the same time acknowledge individual talents, as meritocracy contributes to improve the results of the whole group of people and that matters!

So, now we see it, it’s possible to see clearly that anarchy was just the obvious attempt to move forward regarding the evolution we want - a more free society. It might not have been the solution, but it was a step forward.

Decentralization is not the goal, it’s a mean. The goal is a more free society.

Hierarchy vs Anarchy comparison table

I tried to create a table below with a minimum set of differences between these 2 organization forms. The table is definitely incomplete, but hopefully it transmits the mental model I want to show here - we should constantly be thinking on both as 2 solutions with trade-offs between them, instead of religiously defending one of them for any situation.

What’s better for your use case? Would a decentralized organization bring better results? Or would a centralized one? Can you imagine forms of combining both, applying each one in the proper situation?

How to get to a more free society

Given anarchy is not the solution we thought it was, what is then?

To answer that question, let’s refine a little our concept of freedom. What is a more free society? One could argue that being free is being able to make decisions independently. However, we are free to decide, but we are prisoners of the consequences - if you have the freedom to decide which design to use for a software you’re creating, and that design decision results in bugs, you might lose your freedom to work on any task you want, as you will probably have to fix the bugs you generated with your decision.

In that example - if you were on a team, what would you decide to be free on, if you had the choice between:

1. To be free to not spend any time studying how to cook
2. To be free to get a tasty meal in less than 30 min whenever you want

Of course it’s an hypothetical example, but hopefully it’s enough to show that some times there are conflicts on what to be free on. Freedom is rarely absolute - nature limits the amount of freedom we can have, even if nobody is imprisoning us. One could argue that a more free society is a society where people can make all the choices, in a decentralized way - but looking at the options above, even if you have the freedom to decide, you will lose freedom for either 1 or 2 regardless of what you choose, as nature imposes to us we can’t have both.

So, in a group, how to define freedom and how to define slavery?

I have a special view on what being free means and I hereby propose the following rough definitions for this:

• Autonomous - You’re free when you don’t need orders to perform actions. Like in the case of cooking, mastery and skills make you more autonomous - the more knowledge you acquire and the more you can move alone without depending on others, the more free you are.

Mastery, skills, knowledge and discipline - lead to freedom.

• Accountable - If you’re not ready to take the consequences of your own acts, you’re not free. If you rely on others for everything, that makes you dependable on them, even though it might look like the opposite some times. Never taking accountability on anything moves you towards parasite relationships, where you cannot leave without others doing things for you.

The best leaders are not afraid of assuming their own mistakes, they do mistakes and learn lessons from them

• Have common goals - humans do not survive alone - we only reached the stage we are as humanity by helping each other. This is different from being dependent on each other, this regards being part of a group, that moves in the same direction, because the individuals want to get to a common place.

The more social and soft skills you have, the more free you are.

• Organized - some people think anarchy is the same as chaos, which is the absence of organization - but it’s not, the name of this is anomie. Hierarchy is just another valid form of organization, so people are not necessarily non-free for organizing themselves using a hierarchy. Organization is essential to freedom, as without it you are slave of the waste of time and productivity disorganization implies.

Societies are only free when they can organize themselves to split and sync the work across individuals

This last point is very tricky, as hierarchy can be there to organize, but it can be misused to the opposite - and here we arrive at the main point of this article: what is the best way of achieving organization?

Anarchy can apply in some situations - whenever you have established mechanisms inside a team, or centralized decision making based on votes, if this leads to organized groups, then good. As we saw above, it’s not always the case, as anarchy requires a high level of autonomy and mastery from the individuals - the more free the individuals are, the more you can use anarchy as a form of organization.

But hierarchy is also valid to organize, as long as you ensure it won’t drift to just oppression. And how can you do that? How can you make sure hierarchy on a groups is kept under control and only serves to bring organization, not random oppression?

The answer is not immediately obvious, but IMO the solution is clarity of delegation.

How to use hierarchy the right way

The secret for hierarchy to work fine and understanding that management is just another job, like any other. The hierarchy is just there to bring organization to the group, not to make sure that every decision in a company with 1000s of employees have to be decided by the CEO.

Companies hire employees so they can make decisions better than the bosses. The boss job is just to bring organization to the chaos, as well as forming more leaders - good leaders will form more leaders and they will want to drive the team members to improve in the qualities that will make them more free - more accountable, more autonomous, working more towards common goals and in the most organized way possible.

And what about bad leaders? Bad leaders will fail to do that and what happens in most companies is they blame others for their failures, because they are in a position of privilege due to the hierarchy. That is the thing we must fight against - leaders must be accountable for what they do and if they are being bad leaders, there must be some mechanism (anarchy again, how odd!) to drive them out.

Good leaders create more leaders and turn people into more free.

Bad leaders blame others for their mistakes and get credit for things they didn’t do.

I believe the best mechanism I have found to the date for that is Management 3.0 delegation levels:

In this mechanism, managers are in control of delegation and they can decide whether they will do something themselves, or whether they will delegate something. As things are not always black and white, they can some times delegate most of the decision but still be involved to veto if needed, or delegate but be involved to just keep informed about it, for instance.

The fact is - when these managers use delegation boards and publish them to their teams and to other parts of the organization, it’s much much harder to run away from accountability. Given a situation where something went wrong, you can just look at the delegation board and see whether the team member was to blame, or whether the manager failed on his/her role.

Good managers are accountable and even if you have hierarchical environments, if you have crystal clear delegation and accountable leaders, who admit their mistakes and who step down as leaders if they are failing, the system works fine.

Clear delegation and accountability makes hierarchy work well enough for a free society, decentralization is an option, but not a must have

Bringing this to practical terms - that’s what we should be moving towards to. Sure, some things can be decentralized, but instead of assuming everything will be fine with flat hierarchies and anarchy like environments, we should be demanding clear delegation in the work environment. That’s what you should be asking questions about in your next interview.

TLDR Summary

Pragmatically, here are the takeaways I hope you got with this reading:

• Focus on results - making decisions as a team can be nice some times, but it’s not what you were hired for - do not let yourself to deviate from the team goals thinking the manager is forbidden to make any decisions - hierarchy is not the real evil.
• Earn your freedom - become more autonomous and independent, be accountable for the responsibilities you pull or are assigned, and pay attention to where the whole group is moving to - you’re not an island. Do that for yourself, not because your manager told you to do it.
• Be accountable - assume mistakes if you make them, be humble, the best leaders are not the most arrogant, the best leaders make mistakes and learn a lesson from them.
• Lack of accountability is the real evil - demand clear delegation from your managers and when you’re the manager, provide clear delegation. Create delegation boards, use delegation levels mechanism. When you interview for joining a company, do not ask them whether they make decisions as a team - try to find out how accountable they are.

What do you? Was the result acceptable? You can find the source code of this website in my github project page.

I wish I could customise this more, and still keeping the updates from new versions easy, but for now this is enough and I want to focus on content, not on appearance, so hopefully the visual looks good enough. If you’re seeing this on a later time hopefully the visual will be a little bit improved?

What I loved about this is how easy it is to write a new post: I still can use my prefered markdown editor, version everything in a git repo, and all I have to do to create a new post, which can include images, is creating the images in assets/img folder and then a post in _posts folder. Once I push the commit to master, github automatically deploys and hosts it for me. Nice, uh?

And just to prove that this works, here it comes an image - a photo I took on Lego Land recently.

Do you have suggestions for improvements on how to host a blog or publishing posts? Any trade-offs? Please leave a comment below, it will be appreciated!

When you read the causalities section, the numbers are scary: “The war resulted in at least 1,030,000 casualties (3 percent of the population), including about 620,000 soldier deaths—two-thirds by disease—and 50,000 civilians” - and that’s a minimum number, the real percentage of the population that died in this war is huge.

Without digging too much in the non-official causes of the war or into the historic details, I think I can say it was a milestone to human kind in terms of changing from a world where slavery was the norm, to a world where everyone is free. But has the change caused by the war or by the victory of the north?

Real changes take time

It’s probably possible to trace the origin of this change back from the end of feudalism, passing through the french revolution, with society economic habits changing slowly, with changes in the predominant mental model in most people’s heads, until we see the practical effect in how our society is organized nowadays.

Understanding this point is key for what I want to express here - both slavery and freedom don’t come from night to day, they come from the predominant mindset that lives in society. Freedom is just a word and unfortunately, it’s not achieved with a war victory - real abolition of slavery comes with a slow process of mind change in the whole society.

The change has started way before the war then, so here is my question for you: has it been completed? Have we really won this war already? We can look at how many dictatorships we have in the world and we will easily see that this has not been the case. Let’s look at some examples:

• Foxconn suicides - in a Chinese firm that has Apple and HP as customers, there have been many cases of suicides due to poor work conditions. People have to ask permissions for their bosses to go to the toilet.
• Wineries in Brazil involved in slave labour scandal - A case that happened in 2022, where brazilian farmers in the south of the country would hire workers paying low salaries and sell them goods at high prices. The workers got in debt and then could not leave anymore without paying the bills.
• Slave markets found on Instagram and other apps - in Saudi Arabia there is an app called Haraj, where woman can be bought - this news is from 2019 and it’s very likely still the case today. According to walkfree.org, 740000 people are currently living in modern slavery conditions in Saudi Arabia
• According to antislavery.org, 49.6 million people around the world live today in some kind of modern slavery condition.
• Still according to The Guardian and walkfree.org, more than 400,000 people could be living in “modern slavery” in the US, a condition of servitude broadly defined in a new study as forced and state-imposed labour, sexual servitude and forced marriage.

Well, if you deep analyse the facts above, you will ask: why? Why do such things still happen today? Can the world go back to the slavery model the south of US defended during their civil war? Are we certainly evolving, or are we still at risk of going back to that? When will we win this war for good?

Freedom is inside your head

One of the hardest things for me to understand in life was that slavery is much more than a physically forced condition. These cases of slavery happen with something in common, they might even had physical aggressions, but in many cases it’s the culture, the way the person see himself or herself, that makes them to accept that poor condition and understand that’s “their normal”.

Slavery doesn’t occur just on the enslaved mind, it also occurs on the enslaver mind. As a brazilian, I am lucky enough to have had contact with many books from a famous brazilian author called Machado de Assis, who wrote in deep about this subject - his writings go deep in the analysis of what’s happening inside the enslaved and the enslaved minds. I really recommend his work, unfortunately I am not sure how much of it is available in english.

Have you ever thought about that Foxconn case where people have to ask to go to the toilet? Can you imagine that happening to you? Now take a moment and think about the boss, controlling how much people go to the toilet. Do you see him as a slave?

I must tell you - I do. Slavery is a condition, it’s a way of understanding the world, it doesn’t matter who rules - no slavery means no ruler, being put in the place of the ruler doesn’t make you less of a slave. Controlling how often people can go to the toilet might seem normal for some people - that is the slavery mindset being alive. Fighting slavery means fighting this kind of mental model, above all. While we still think some people are born to rule and some to obey, slavery is alive.

When you go to a restaurant, do you like to be served? Do you think the world can only be good when you have a maid to clean your house? This kind of mindset is extremely common where I was born in Brazil and in many places around the world, and although the war has ended for long, don’t be tricked - slavery is still there.

Bare this in mind: slavery is the mindset towards power and dominance, it’s not the physical coercion itself.

But is it the same thing?

Just to be crystal clear about this, as I know I am touching a very delicate point, by no means I am trying to minimize here in this text the formal slavery as it happened, specially by afro americans in the case of US and other american countries.

I think there is no doubt that was unacceptable and that it should end, what I am trying to explain here is that eliminating formal slavery is just not enough - because while the mindset is still there, it can still come back or it still exist in some lighter form.

Acknowledging that the real change requires a change in mindset is not the same as saying that the kind of slavery that existed before the way is the same kind we have today - modern slavery is different, but it still something very undesirable.

What does it have to do with my team at work

At this point, whoever is reading this text might be asking - ok, but what does all of that have to do with my job? There is no slavery where I work…

Well, once you understand the point I made above, you can start asking yourself whether that’s really the case. You might not see formal slavery, but are you sure that slavery mental model is not there where you work?

It’s useful to think about that, and think about the kind of society you want to live at. The real war is not fought in trenches any more, the real war is fought in every office space, or every remote workplace, where “soldiers” fight the old days mental model every day.

Have you ever had the desired of being “served” by others and to rule? Do you question, when this desire comes, whether everyone doing the same will lead the society for the model you think it’s the correct one?

When we see initiatives in the workplace to minimize discrimination, moral and other forms of harassment, unconscious bias awareness trainings, all that goes in the spirit of changing what matters the most - our mental model as a society.

But can you think of other examples at work where your attitudes, the attitudes of your manager/hierarchy or the attitude of the people who report to you are related to slavery and to this change we want (hopefully you too) see in society?

Workplace examples

I want to list some practical situations and ask you to question with me: what of those things are fine and not related to freedom at all and what of those things we should try to change as a society. Are these examples normal? Or are we biased for the world we see today? Would these things be considered as normal 50 years ago?

Please, I am not saying I consider all of those scenarios of modern slavery! It’s really an exercise to think about it.

Scenarios:

• Manager A controls the amount of times people go to the toilet

• Manager A controls whether or not people can yell at each other inside the team.

• Manager A controls the start and end times people in the team start / finish to work

• Manager A controls the amount of times people go to the office per week

• Manager A yells at someone in the team because the person arrive late at work.

• Manager A yells at someone in the team because the person tried to go against his/her orders and performs an action that could cause death of people.

• Manager A is responsible for everything a team does, but his manager, manager B, tells him he cannot tell engineers what to do. When engineers do something wrong, manager A is blamed.

• People sign a work contract saying they have to stay longer at work if needed, but it’s not in their control how much will be needed.

• People in the team sign a contract with poor working conditions they don’t want to accept, but they have to because there is no other job offer for them in the market.

• Engineer A can do his/her job pretty well and submit the required output, but his/her manager wants to control HOW she will do the job and impose a set of processes to force a way of doing things. The processes have flaws, engineer A struggles to get the job done and is blamed for that.

• Manager M gives orders to subordinates S1 and S2. The orders given to S1 have a bad outcome and S1 is blamed for the outcome. The orders given to S2 have a good outcome and M showcases how good was the outcome due to management decisions.

• There are 3 engineers in a team, they are told they all make decisions as a team, and the whole team takes responsibility for the decisions. Engineer A wanted to cause an impact and make a big contribution to the team, but because decisions have to be made by all, A can never implement those ideas, because the rest of the team won’t be willing to try.

• A manager motivates a team by making everyone feel super special and work harder, making promises like “better work environment” when some milestones are reached, without any intention of (or power to) fulfilling the promise, just lying as a mean to achieving the ends.

What do you think about the scenarios above? Have you ever seen them in practice? Are those all fair scenarios? Do you think it’s easy to define the boundary between what’s acceptable/normal at a workplace, and what’s a “slavery mindset”?

Conclusion

I see the american civil war as one big event that signalled a change going on with society, but the change is still happening and it’s really hard to know where it will evolve to. What we know, for sure, is that we all take part in that, and IMO, we should all keep this in our minds and start paying attention to the minor things that happen at our workplace. Have you ever stopped to think about these things and their relation to slavery and society organization?

I don’t think, at all, that all scenarios I listed above are forms of slavery. But I am very confident in saying some cases are far from being obvious and if I show the same scenarios in front of different people, I am certain I would get many conflicting results.

If you understood the main message of this article, here are some suggestion of practical actions you and I can do in our workplace to make sure we build better work environments for everyone:

• Start paying attention to your habits and to your team’s habits. You might be doing things since you’re born that you never questioned before.
• Remember that many things that were considered normal 50 years ago, for instance, are condemned today, because we evolved as a society in being concious that those habits were wrong. You could be doing things today that will be considered wrong in 50 years.
• Before you advocate strongly for something at your workplace, look at the examples above and remember that these things are far from obvious. Try to be concious of that and understand others’ point of views.
• Keep the discussion about the morality of each situation on. These things are to be discussed, we must exchange ideas about them, if we want to evolve as a society
• Do position yourself and admit when/if you find out you were wrong - trying to take always the right side of the story might mean nothing. It’s not enough to defend the north, you have to understand why they were right and why freedom is something to die for
• When you’re in the strong position and you can take advantage of someone else, question yourself whether this is the society you want to live at. Don’t forget your actions are examples to others and even if you take advantage today, tomorrow it might be you or someone you love who is the fragile part
• Never forget the person in a position of power is also a slave. Slavery is a mindset, so do not think you’re “protected” or that you won’t suffer the bad consequences of slavery if you embrace it being in a position of power. It’s about who rules, it’s about not needing or wanting a ruler, even if it’s you.
• Follow my blog :D - I am planning to write more articles about those subjects, so maybe we can improve together? Subscribe to my RSS or follow me on social media!

Leave your feedback

Please do comment, give feedback, I would love to read what you think about the subject.

I will probably write more articles in the future related to this subject, but I had to write this one first to part from the base. I hope you enjoyed it and I hope it made you think about the problem - hopefully in the next ones I will write more about specific problems related to this subject and possible solutions.