TL;DR;

In essence, leadership and management are two sides of the same coin, each playing a critical role in guiding teams and individuals towards achieving their potential and realizing organizational objectives. By building trust and taking control in measure, you empower your teams to innovate, perform, and thrive in an ever-evolving landscape.

Have you ever worked in an organization that either seems too lax on the process or too stiff? What is behind that lack of balance? Are Leaders & Managers roles completely contradictory?

In the realm of organizational success, the distinction between leadership and management is not just semantics. It's foundational to how teams and individuals achieve their goals. While management is essential for ensuring tasks are completed, budgets are adhered to, and deadlines are met, leadership goes a step beyond, it cultivates an environment of trust, vision, and empowerment.

The Essence of Leadership: Building Trust​

Leadership is inherently about building trust. It's a leader's responsibility to create a safe environment where team members feel valued, heard, and encouraged to contribute their best work. Trust is not built overnight but is developed through consistent actions, transparency, and an open dialogue. Here are a few ways leaders can build trust:

• Empathy and Understanding: Leaders who show empathy and genuinely understand their team's challenges and needs foster a deeper connection, demonstrating they value their team members not just as employees but as individuals.

• Consistency in Words and Actions: Trust is nurtured when leaders follow through on their promises and demonstrate integrity in all actions, proving they are reliable and trustworthy.

• Empowering Others: By delegating meaningful tasks and showing confidence in their team's abilities, leaders empower their colleagues, which builds trust and cultivates a sense of ownership.

• Leading by Example: Actions often speak louder than words. When leaders embody the values, work ethic, and attitude they wish to see in their teams, they set a powerful example that encourages others to follow suit. Leading by example bridges the gap between directives and action, showing that leaders are willing to do what they ask of others.

The Role of Management: Taking Control​

Management, while often seen in a less glamorous light, is crucial for organizational success. Managers take control by organizing, planning, and directing resources to meet objectives. Control, in this context, means ensuring that processes are efficient, objectives are clear, and outcomes are predictable. Here's how management takes control:

• Setting Clear Goals and Expectations: Managers excel at clarifying goals and setting expectations, ensuring everyone knows what needs to be done and by when.

• Monitoring Progress and Making Adjustments: Control involves keeping a close eye on progress, identifying issues early, and adjusting plans as necessary to stay on course.

• Efficiency and Optimization: Managers focus on optimizing resources, reducing waste, and improving efficiency, ensuring that the team can achieve its objectives with the resources available.

• Keeping Everyone in Sync: Effective managers facilitate communication across departments, share insights and updates, and ensure that their team’s objectives align with broader company goals.

The Imbalance of Leadership Without Management, and Vice Versa​

Seeing both roles as contradictory tends to push organizations towards failure. Organizational success requires a delicate balance between leadership and management. An imbalance, where one exists without the other, can lead to challenges that hinder a team’s or organization’s ability to reach its full potential.

• Leadership Without Management: Leadership focused on building trust and vision without the grounding force of management can lead to a lack of direction and inefficiencies. While teams may feel inspired and valued, the absence of structured planning, goal-setting, and resource management can result in missed deadlines, unmet objectives, and wasted potential. In essence, the drive and motivation fostered by leadership need the rudder of management to steer the organization towards its goals effectively.

• Management Without Leadership: Conversely, management without leadership often leads to a rigid, uninspired work environment where tasks are completed, and objectives are met, but there’s little room for innovation, engagement, or personal growth. This scenario can enforce a culture of merely 'going through the motions' rather than thriving. Teams may achieve short-term goals but at the cost of long-term engagement and loyalty. The vision, inspiration, and trust-building aspects of leadership are critical for cultivating an environment where employees feel connected to their work and motivated to contribute their best.

Finding the Right Balance By Bridging Leadership and Management​

The most effective leaders are those who can blend the visionary, trust-building aspects of leadership with the pragmatic, control-oriented nature of management. Here are a few ways to bridge the gap:

• Communicate Vision and Purpose: Share the bigger picture and why work matters, connecting daily tasks to overarching goals.

• Foster an Environment of Growth: While maintaining control over the essentials, encourage innovation and risk-taking within parameters that ensure alignment with goals and values.

• Practice Emotional Intelligence: Recognize your emotions and those of others to manage interactions and communications effectively, blending empathy with decisiveness.

The synergy of inspirational leadership and effective management ensures that teams are not only motivated to reach their goals but are also equipped with the strategy, resources, and direction to do so.

Welcome to our Continuous Delivery Bootcamp! We'll teach you the skills you need to get your projects out the door fast, without sacrificing quality. By the end of this program, you'll be a pro at transforming code into working software. Sign up today and start transforming your workflow!

This chapter we will do an example on how to build and validate our project in github actions.

Video

{% embed https://youtu.be/QMwXxezykHc %}

Watch the video on Youtube

Welcome to our Continuous Delivery Bootcamp! We'll teach you the skills you need to get your projects out the door fast, without sacrificing quality. By the end of this program, you'll be a pro at transforming code into working software. Sign up today and start transforming your workflow!

This chapter we will do an intro on the tools we will use and how to commit code with git and GitHub works

Video

{% embed https://youtu.be/nwpUtvHulWM %}

Watch the video on Youtube

Welcome to our Continuous Delivery Bootcamp! We'll teach you the skills you need to get your projects out the door fast, without sacrificing quality. By the end of this program, you'll be a pro at transforming code into working software. Sign up today and start transforming your workflow!

This chapter we will do an iteration writing test, doing test driven development not only as a testing tool but also as a design tool.

Video

{% embed https://youtu.be/MG-Uqve41BQ %}

Watch the video on Youtube

psychological safety is essential for the success of software development teams. By fostering open communication and encouraging a culture of learning and innovation, teams can work more efficiently, effectively, and creatively. By promoting psychological safety, managers and leaders can help their team members to reach their full potential and take the team to the next level.

Long Version​

What is psychological safety​

Psychological safety refers to the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. It is a shared belief held by members of a team that the team is safe for interpersonal risk-taking. This safety allows team members

Why is psychological safety important​

Psychological safety is an essential aspect of any successful organization. Software development organizations are no exception.

One of the main benefits of psychological safety is the ability to foster open and honest communication. When team members feel safe to speak up, they are more likely to share their thoughts and ideas, which can lead to more efficient problem-solving and decision-making. In a field that is constantly evolving and where new technologies and approaches are continually emerging, it is essential to stay up-to-date and adapt to change.

Furthermore, it allows for creativity and innovation to flourish. When team members feel secure in their ability to express themselves, they are more likely to think outside the box and come up with new and unique solutions. In software development, this can be the difference between the success and failure of a project.

However, creating a culture of psychological safety is not always easy. It requires active effort and commitment from everyone on the team, including managers and leaders. One important step is to actively listen to and encourage open dialogue among team members. Managers should also create an environment where mistakes are viewed as opportunities for learning, not as failures.

Another important step is to establish clear guidelines and expectations for communication and behavior within the team. This can include things like setting ground rules for respectful dialogue and providing training on active listening and conflict resolution.

Finally, it is essential to hold every one on the team accountable for maintaining a culture of psychological safety. This includes managers, who should lead by example and model the behavior they expect from their team.

As we develop a product over time, changes need to be made as we need to accommodate new functionality. As most of our systems don't run isolated, and we have clients that used them (ex. public API), We have to keep compatibility at least on a temporary basis. How do we achieve this?

Versions​

A common practice is to have different versions for the multiple clients. While simple, it also requires significant effort to maintain as whenever an issue or bug is spotted, multiple places are affected, meaning there are more possibility of side effects.
It also makes it more difficult to make a case for clients to migrate from one to the other due to the contract changes.

This affect mostly negatively the next DORA 4 metrics:

• ❌ Lead Time for change

Versionless: Expand & Contract​

As the name says, this strategy intents to have only one state of truth and not a multitude of them. Versionless has been heavily adopted as a principle by GraphQL, for example.
We can achieve this in any code base by implementing a strategy for parallel changes called Expand & Contract, it's call this way due to the phases code goes through. Let's see for example we want to migrate from using one field value to a similar field with a more complex representation.

• Expand: We add the new 'field' to the existing contract, and add the code to support this strategy on the existing code.
• Contract: We monitor the usage of the old 'field' to understand when it is possible to deprecate, at that point we remove the old code.

With this, we have a clean source code that we can evolve indefinitely as required by the business.

This affect the next DORA 4 metrics:

• ✔️ Lead Time for change

I have already written some other post on this topic. I will go straight to the point on comparing Git Flow (a legacy strategy that most companies use) and Trunk-Based Development.

Gitflow: The Bad & The Ugly​

Why do I call it the bad and the ugly? Because it does not allow you to achieve Continuous Deployment.
The idea is that every developer works isolated on their branch, validate on their branch and ask through a merge request to add their code to the X stage branch.

There are multiple issues with this:

• Code does not exist isolated, we don't deploy isolated code, so the isolated test is not valid as it will require retesting.
• The peer review process happens at the end, causing a very slow feedback loop. Having to rewrite code that could be avoided.
• The more time the branch lives, the more it diverges from the original behavior and the more complex it is to merge.
• Merging can cause complex conflicts that require revalidation, and it might have side effect in other features.
• As there needs to be validations of the merges, it's normal to have multiple environments that give a false sense of security, increases the $ cost and increases the lead time.
• Egos and preferences become part of the review process, as it has become an 'accepted' practice that the 'experts' or 'leads' do the reviews.

All of this is red tape to go through is a problem that makes delivery slower, and create a lack of ownership mentality farther away from what happen to the individual branch.

This affects mostly negatively, most of DORA 4 metrics:

• ❌ Deployment frequency
• ❌ Lead Time for change
• ❌ Mean Time To Recovery

Is there a simpler and better way to collaborate on code way?

Trunk-Based Development: The Good​

What happens if we all commit to the same branch.

Most of the expressed issues are solved, in this scenario by:

• Code is never isolated, as we all push code to the same place.
• Teams that do this practices also practice pair programming, making the peer review process is continuous and synchronous.
• As individuals push multiple times a day, merge conflicts are non-existent or small.
• Does not require revalidation, as validation is a continuous stream in the single environment.
• No ego environment tent to appear as there is no centralize approver of code, so it's not a matter of preference but a team effort and ownership.

As we have seen before, having unfinished code does not need to affect users, as it is common practice to use feature flags and/or branching by abstraction.

This affect the next DORA 4 metrics:

• ✔️ Deployment frequency
• ✔️ Lead Time for change
• ✔️ Mean Time To Recovery

Conclusion​

Simplicity is king. Having a simpler structure enables speed and quality of delivery, as it allow teams to work closely, take shared ownership and act faster related to a smaller change.

Before we enable code for our clients, we need to test and validate it does what is expected. This could be an entire series of its own (please let me know if you want one), so I will keep it on a high level.

Testing​

I could probably spend hours sharing different types of testing strategies and where and why to use them.
In reality, the most important thing, is to make sure we use the correct ratio of the different types of tests, as it will highly affect the time and location of your testing.

This ratio has always been shown as a pyramid with:

• Unit test: validate individual pieces of logic that are isolated.
• Integration test: validates interactions with multiple parts of your system or other systems.
• Integrated test: They test the system as a whole.

Tests are divided in these layers because there is a cost in time and complexity.

This affect the next DORA 4 metrics:

• ✔️ Change Failure Rate

Validation​

Validation differs from testing as it's the confirmation that the behavior is what the user expected, for now, humans are the only ones that can discern this.
As we have seen in the previous chapter, the recommendation is to do this in production, so you get:

• Get real behaviors of interactions with other systems
• Get real performance

This affect the next DORA 4 metrics:

• ✔️ Change Failure Rate

Now that we know where our code lives, we need to make sure our users get access to the features. For this, we need to get our code to the environment we want to deploy to, and control the rollout (if you are not a big bang release fan).

Blue/Green Deployment: Getting to prod with 0 downtime​

What is this?, The concept is simple, we have a set of machines (ex. blue) where we currently have our app running, and we want to deploy. The intent is to create a new set of machines (ex. green) where our new version of the code will run. We would like to validate as much as possible (ex. automated e2e tests) that this new version is up to par with the previous one before moving the traffic and destroy the previous version.

You can see the process in the next graph:

With this, we are trying to achieve a 0 downtime while deploying a new version of our code. This is critical for teams that practice continuous deployment, as you want to avoid having systems down as you deploy multiple times a day.

Enabling feature access to users​

there are multiple ways to enable access to users, in between them:

Big Bang Releases​

This is the plug and pray solution. Pushing the code and expecting it to work as it's enabled for all users. This is a very dangerous strategy as your blast radius is all your users.

Canary Releases​

This is a practice that comes from the mining industry, The idea was the next one:

If a canary is in the same place where humans are inside the mine, when there is a problem with the breathable air it will be the first one to perish.

If we translate this to software, the idea is to have deployed the changes only to one or a few servers. With this, we can monitor this canary instances and act if any issue happens, we reduce the blast radius of issues to only the users who go through that server.

This affect the next DORA 4 metrics:

• ✔️ Change Failure Rate

This approach provides us a way to reduce the blast radius from a big bang release. Nevertheless, it does not help us to prevent or act faster upon a bug in our code.

Feature Flag Releases​

To improve upon the canary release strategy, we can move towards feature flags.

Feature Flags are hiding our code behind a 'flag' this can help decide if the code is enabled or disabled, as in the next image.

There are a multitude of services, libraries & SDKs that allow you to create flags in your code. They help by:

• Decouple activation of features from the release pipeline.
• Solving incidents in a matter of seconds.
• Do a controlled rollout. For example:
  • Enable only for team.
  • Enable for X% of the traffic.
  • Enable for users in a specific country.

This affect the next DORA 4 metrics:

• ✔️ Deployment frequency
• ✔️ Mean Time To Recovery
• ✔️ Change Failure Rate

Our services need to run somewhere, so our users can access it. It's a very common practices to have multiple environments like dev, staging, and prod. Is this actually a good practices?

CI vs. CD vs. CD​

when people talk about continuous integration, delivery and deployment, they normally talk about it as a whole.

Nevertheless, let's reflect why these are 3 different practices. As they are steps in a journey, you can do one and not the next one.

• Continuous integration: allows making reproducible states of the code in multiple places.
• Continuous Delivery: Now that it's reproducible, it needs to be marked as potentially deployable and provide the ability to deploy it.
• Continuous Deployment: Delivers the code to your clients and not only to your team as you commit.

The trap of Multiple Environments​

As you can imagine, with the previous definition of CI/CD, having multiple environments will never allow you to achieve Continuous Deployment.

The intent of having multiple environments is to reduce change failure rate, are we actually achieving this with the practices? The answer is normally not due to:

• A non-production environment will never be the same as a production.
  • Different data
  • Different performance
  • Different security practices
  • Etc…
• Stress and ownership of moving things to production
• Accumulation of code in lower environments (meaning more bugs).
• Longer feedback loop.
• Continuous misalignment due to development cycles in between different teams.

As you can see, this makes a fake sense of safety, but it does not affect positively the change failure rate.

This affects mostly negatively, most of DORA 4 metrics:

• ❌ Deployment frequency
• ❌ Lead Time for change
• ❌ Mean Time To Recovery
• 〰️ Change Failure Rate

Achieving Continuous Deployment, Only prod, is it so crazy?​

How can a team Continuous deployment? The answer tends to be simple, making every commit go to production and testing in it.
Be aware this does not mean to have our users experience possible bugs or see test data, as we can hide functionalities behind toggles, headers, or parameters that allow access to only the development team. As we will see in future installments of this series.

An example strategy is the one in the next diagram.

This allows us to keep only one environment that discriminates in between test and non-test data that can be clean periodically, while it provides the real environment with the real behavior. With this, we solved:

• Real performance & behavior.
• Continuous alignment with other teams.
• Smaller feedback cycles.
• Control of rollout.
• Smaller $ cost.

This affect the next DORA 4 metrics:

• ✔️ Deployment frequency
• ✔️ Lead Time for change
• ✔️ Mean Time To Recovery
• 〰️ Change Failure Rate

Conclusion​

There is no one size fit all, but modern practices tend to go towards simplicity and fast feedback loops. There are many practices involved on this simplicity that enables us to feel comfortable with only production environments. We will talk about them on this series.

Related Videos​