This sentence carriers at a lot of assumptions, beliefs, and responsibilities:

• You can plan in advance

• Product/project can define better specs

• Tech can estimate the time to deliver

The space I found this sentence the most is during retrospectives, when we expect something to take less than it is taking/took. Usually, we ask during the retro:

• What happened?

• What could have done differently?

And most of the time we tried to plan better, we made things worse. Because the more dangerous belief is that you can know in advance.

After walking the walk, we know a lot more. What helped us to gain the knowledge was the movement, the execution based on imperfect information.

Walking the walk, we reduce risk, we iterate fast, and we often communicate our learnings with the rest of the team, and organization.

Yes, that will imply rework, frustration, and feeling of waste.

Yet, that was what was needed to gain knowledge and move forward. That had value on itself.

What to do instead?

Identify if we are moving the responsibility to product

We all want to make our job better, and asking for better requirements is an easy ask.

“If I knew this in advance, this wouldn’t take this long.” - Every dev at some point in their career.

Instead, aim how you can collaborate with product to reduce the unknowns and gain rapid knowledge. Instead of full functional implementations, aim for short experiments.

Move from Factory Dev into Product Dev.

Identify if we could fall into the analysis-paralysis trap

We love certainty. We all do. Yet, that’s not reasonable. And with AI, this illusion is even harder to spot.

We cannot know everything in advance, nor it is useful. Some sort of upfront is reasonable, aiming to have a full plan from backlog to prod not useful.

Instead of assuming that more upfront planning would help, ask which areas would have worked better, and which areas wouldn’t be identified regardless of how much planning made.

Make those scenarios explicit, identify the things that took the most to learn, and the cause of learning it late.

Then you can ask yourself and the team “what can we do to expedite learning on these areas?”

Maybe the solution isn’t more research, but microtools to learn faster as you develop.

At this point, I want to introduce you the concept of Moldable Development.

If you are interesting on a new way to understand software, I would recommend you to take a look at it. I will write about my experience about it in the future.

What would you do instead?

Reply in the post on how did you approach this situation, I’m sure we all faced it at some point, but super interested to know how did you overcome the situation.

When I became a manager, I understood the importance of a great culture. Yet, I had a hard time describing what’s culture, what’s a great culture, and how to make actionable actions to influence it for the better.

I didn’t study Anthropology, if you did, please, point out any misconception in the comments!

When I ask people what’s company culture for them, it usually reduces to:

Long story short, how decisions are made.

Then, I read The Staff Engineer’s Path by Tanya Reilly, and it contains a great way to understand your company’s culture, and what people refer to.

When people ask about culture, they might refer to:

• How much autonomy will I have?

• Will I feel included?

• Will it be safe to make mistakes?

• Will I be part of the decisions that affect me?

• How difficult will it be to make progress on my projects?

• Are people nice?

We can say that our culture is how we behave in our day to day, how we make decisions, and based on which values.

I find this way of describing the company’s culture very on point. You can answer to those questions to people you are onboarding, and you can spot any issues in certain areas of the culture.

Tanya even goes further, and provides 7 dimensions in which you can describe the company’s, business unit, tribe, or team culture.

Here is a shorter version of the 7 dimensions based on Tanya’s book.

• Secret vs. Open.
  How much does everyone know? Information is currency? Calendars are private?

  Slack channels are invitation only? Does everyone have access to everything? Even messy first drafts?

• Oral vs. Written.
  What gets shared by word of mouth, and what gets shared written down? How much writing and review is involved in decisions? Features come with formal specifications, or you need to go to the person that made the feature?

• Top-down vs. Bottom-up.
  Where do initiatives come from? A completely bottom-up culture is one where

  employees and teams feel empowered to make their own decisions and champion the initiatives they think are important. But, when those initiatives need support, they slow down.

• Fast vs. Deliberate.
  Rapid decisions and pivot abruptly to try a new opportunity. Or you need to show that you've thought through the whole plan before start executing?

• Back channels vs. Front doors.
  How do people in different groups talk to each other? Formal path of communication, via the teams' managers for example, or people can send friendly DMs cross teams?

• Allocated vs. Available.
  How much time does everyone have? Are teams understaffed or overworked? Are you able to absorb new work as they appear, or does it end in the backlog and needs to get prioritized in the next cycle? (it can mean next quarter OKRs review)

• Liquid vs. Crystallized.
  Where do power, status, and reputation come from? How do you gain trust? Clear

  hierarchy? Are you in a specific point in the hierarchy, and as others move up into the latter, you also move? Or you are more Liquid, where it offers room for change and you need to move yourself to be promoted in the organization?

I use these 7 dimensions a lot to understand my clients company’s culture, and why they are struggling to drive the needed change.

Understand your company’s culture first

As part of my coaching and consulting engagements, I ask leaders which is their company culture based on those dimensions. Interestingly, I receive kind of two main responses:

• That’s not the type of company I want to be part of.

• That’s why we’re not able to drive the necessary change, because the culture isn’t helping us, we need to change it first so that we can do the necessary changes later

Culture is never black or white, but a grey scale in multiple levels.

Plus, I’m sure that you will describe your company’s culture differently if I ask you for the overall company culture, your tribe’s, or your team’s.

The leaders that I support in their journey understand that culture is important, and they want to improve it for better.

BUT, I distinguish two scenarios. Improving company’s culture as:

• C-level, like CTO or CIO.

• Middle management, such as VPs or Heads of Engineering, Engineering Managers, or technical leaders like Staff or Principal Engineers.

In this article, I focus on the group that driving a company cultural change is more challenging, the middle management.

When I talk to middle managers and Principal Engineers about their challenges, they often aren’t about culture as their challenge or goal that they want to accomplish, but as a blocker to achieve the desired outcome.

Principal engineer: I want to drive this initiative to accomplish A, but it would be easier if we had a more Y culture. How can I influence my leadership to change this culture so that I can accomplish the other thing?

Aleix: Well, you don’t aim to change the culture. Cultural change takes time, requires constant leadership support, and a lot of patience. By the time you achieved that, the challenge you have now will no longer matter. Instead, follow the culture. It is the path for less resistance to achieve what you aim to achieve.

If the approach, plan, strategy, you name it, isn’t possible due to the company’s cultural restrictions. Then the problem is your approach that’s not possible in that context. You need to find another way that fits into the company’s culture way of working.

Yes, it can mean that you need to play the company’s rules like being in the right meetings, with the right people. It can even mean that you need to move into the management career to influence the decisions where it happens. Not everyone wants to do it, but some has to.

Focus on achieving your goals and overcoming your challenges within the scope of action you have first. Once you are in the middle of the progress, aim to influence the culture as part of journey.

Cultural change is part of the process

The best way to influence your company culture is part of succeeding in high stake business challenges. You shouldn’t aim for a highly disruptive new way of working for the company, but “the adjacent possible1”.

If you are part of an organization with a top-down approach, secretive, and oral based communication, you can start influencing the company’s culture by driving your initiative by making the information available and written. But keeping the approach top-down. You don’t want to change too many ways of doing stuff at the same time.

This way, when you…

When you succeed

• Achieve your business objectives first, delivering company and customer value.

• You create trust between the all parties. High level leadership, and teams.

• You show that by doing X, Y, Z, you achieved your objectives. Company’s love success, and we all try to repeat success. By doing so, the next time you face a similar challenge, the default approach will be the new ways of working.

When you fail

• You learn why you failed. You don’t blame the culture, but understand why that approach didn’t succeed. Then you adapt your methods, and try new approaches.

• You don’t create high resistance to change due to disruptive new ways of working. That can prevent any new improvement initiatives in the future.

  • The worse that can happen is that the people stop believing in the change.

Make it iterative. One step at a time.

You can learn more about it with this two posts.

You’re an engineering manager of a tribe with three teams. Two stream-aligned teams and one platform team.

At some point, you start noticing critical areas of improvement.

The platform team is under a huge pressure to deliver features because they are blocking stream-aligned teams. Stream-aligned teams lack the proper structured processes, and are making the whole problem even worse.

We wanted to achieve a fast flow of change, but we are seeing that all teams are constantly collaborating to ship the features.

You see the product having some delays, we identify a lack of quality on the shipped product. We understand that it can mean a:

• Not well-defined architecture.

• Lack of testing and other QA practices.

• Missing ownership due to shared responsibilities between teams, making it hard to own a deliverable end to end.

Your team members share that the testing process takes a lot, and it is a bottleneck. The platform is supporting all the stream-aligned teams needs, and they are unable to handle any more work.

At the same time, you’re under pressure to deliver features. You have a budget available, and your manager gave the OK to spend the money with flexible talent, like external consultants or freelances, if you consider it necessary.

You have to take action.

Seeing a problem and do nothing isn’t good for your job security. It’s better to spend money you have available, and try to do something, and fail, than do nothing and still fail, isn’t it?

So, what do you do? How is your culture? What is the acceptable decision?

Let’s hire a set of consultants to help us on the bottleneck, because we want to optimize, the consultants we will be shared between teams.

We hire them temporally to support us on our process.

They are tasked with two goals:

• Unblock our stream of value.

• Train our people.

And all of a sudden, they have been with us for two years. The process didn’t improve, the ownership isn’t there, and the pressure to deliver faster, and better keeps increasing.

Indeed, they are asking more budget to add more people because the processes started to become slow again, and we need more business agility.

Yet, because in your organization you made the decision that is more acceptable by your culture, you’re doing a good job.

But, are you really doing it, or you made the easiest decision?

Why was it the most accepted decision?

• Because you used your budget to add people to the problem.
  But it made the problem worse

• Because you solved a problem with people, because you’re a manager.
  But you know about the processes, and architectural problem. That wasn’t addressed in your approach of hiring external consultants.

• Because you added a new step into the process, and you made them responsible for the quality of the whole product.
  But the product is complex, they are unable to attend the whole team’s needs, the same problem as the platform team had, and they are adding more lead time as more rework is needed.

  • You added more meetings. Shame on you!

Which isn’t the most accepted decision, but an alternative that addresses the problems you identified? Engineering management acting as Enabling Team

You, as part of the engineering management team, have identified the team gaps, the problematics, and adding another step into the problem only makes it worse. You weren’t addressing the root cause.

But instead, see yourself as an enabling team.

You will upskill your teams on the areas that you identified while you gain another point of view. The challenges your team faces.

Being closer to the teams, helping them unlock the necessary change, and facilitate different workshops, trainings, and helping that the new ways of working to stick will unlock a lot of the problematics that you, and your teams are facing.

Why don’t we see management as an enabling team?

Some organizations design the manage role as a people only role.

Missing all the potential of engineering leadership, which it is the combination of people management and technology. We can understand it as the combination of:

• People and processes.

• Technology, such as architecture.

If managers can only influence people, and maybe processes, they will need to act on that dimension. Making their solution space limited and suboptimal.

By understanding our engineering management teams as people, processes, and tech, we enable new possibilities.

Make yourself the next question:

Why do you need to hire a trainer for unit testing if you can do the training?

What is preventing you as a manager of managers to be involved in the teams?

Is it that you are too busy for this work? Why? Is the other work more important, or it is unnecessary bureaucracy?

Stop for a moment, and understand what’s preventing you to do the most sensible actions.

Read more at Team Topologies Newsletter

Update May 12th 2025.

I wrote an extended version of this post as an article for Team Topologies. You can read the full article using the following link, https://www.linkedin.com/pulse/leadership-enabling-team-team-topologies-5icbf/.

If we add the reporting lines per department, it might look like:

A structure like this one would have different communication and collaboration expectations, which each pull the other into a different flow of change. Let’s see them in action.

Within team

Collaboration and decision-making might happen at each layer with some degree of autonomy. This is the most common expectation. We want teams to make fast decisions within their team.

Each management layer also expects to have a high degree of autonomy for decision-making, BUT, it might not be the case when the next communication pattern is more intense for communication with a top-down approach.

Fast communication across layers within the department

Communication happens fast within departments. It is expected that people within the same department can communicate fast. In specific, vertical communication, either top-down or bottom-up.

When cross-layer collaboration is mainly done within the same department, we start sensing more of the top-down. Who decided this? Why? Can we speak with the decision-makers? Why are we receiving a backlog and we don’t take part in the product-ideation process?

A layer makes a decision and then uses its reporting lines to introduce change within the organization.

We can see the flow of change as:

I’m sure teams will have a certain level of autonomy, but the business initiatives are hand-off to teams, creating a slower flow of change as who thinks and who does aren’t the same people.

The responsibility to put different views together and align on the expectations belongs to the team. They receive the needs/priorities differently depending on the department that pushes them down, and it’s the team's responsibility to manage the different incoming items. Well, it’s not their responsibility, but the team that is the affected the most and they need to address it as they suffer the consequences.

This approach usually creates a lot of friction to introduce change and teams naturally evolve into the next collaboration mode.

This structure works well for reporting and a relationship between managers and team members to help people grow and provide meaningful feedback for their careers. Of course, also to communicate things that are exclusively for the department, like now we use X technology and we need to align stuff.

Cross-team collaboration

This might look like a better collaboration to introduce change within the organization, but it also contains traps.

The handover here is more blurry. Because it is hidden in a continuous collaboration mode between teams.

The main difference is that the responsibility to put things together belongs to each layer instead of the team that delivers the software at the end.

Here the friction is reduced, which will improve the flow of change. However, it is far for the organization to reach its full potential.

The more teams you have, the more collaboration is needed. Given a point, you cannot collaborate with as many people as the organization requires, moving back to handovers as the only way to give autonomy without the constant need for collaboration.

Then how?

Based on Team Topologies, the way to achieve a fast flow of change is by having a Stream-Aligned Team that owns the process from idea to production.

The ideal scenario is nice, but how do we reach this point starting from the previous scenarios I shared? What are the problems that prevent reaching our full potential?

Problem 1. Domain experts outside the Teams

It’s common that domain experts are in leadership positions. You want to boost their impact within the organization from subject-matter expert. And it is normal that they have a higher weight on what needs to be built.

Problem 2. Collaboration is expensive

The domain experts starts being pulled into many meetings and their input is needed everywhere. They start moving from explaining the why into asking for the what to be delivered as they are unable to attend all the teams demands.

Collaboration starts to become worse and the meetings aren’t productive anymore. Teams start sensing that they don’t understand the why and the organization is missing the product culture. Domain experts find themselves not understood and explaining the same thing over and over is just creating a burden on them. They opted for a more tell approach to sustain the high pressure environment.

Problem 3. Everyone has their own approach

Teams start creating their own identity that allows them to be resilient to the chaos that’s beyond their team. They understand their area of decision making and they want to master their area of expertise.

Because they are having less decision making on what needs to be build, teams start to focus on the how. They want to feel fulfilled on the craft of their work and create as much as quality as possible to feel proud of their work.

Impacting the user is each day more challenging and influencing the roadmap based on their learnings requires huge discussions and proof their points with data, otherwise the back to the default. Follow the leadership roadmap.

Problem 4. Visibility

We wanted autonomous teams and now, we don’t know what they are building nor if they are aligned between the different business initiatives. We start seeing the product divert in the user experience and which we thought was our user persona.

We start introducing more formal reporting to understand what’s happening within the organization and we consider creating a Program to align all the teams into one common objective.

Teams start to complain about the new bureaucracy introduced to the company, and the sense of we are not an startup anymore. It feels like a corporate!

An alternative to restore hope!

Empower the teams and delegate!

It is not that easy.

As managers and leaders, we have a role and a job to do within the organization. We cannot delegate completely our responsibilities and we need to be involved in multiple things that happen each day.

How can we empower the teams to make their decisions faster when the domain experts/subject-matter experts aren’t part of the team? How can we make sure that teams are aligned without adding multiple layers or reporting that slows the organization down? How do we delegate to teams that misses the skills to be autonomous? How do we make sure that all the information is available when the collaboration is that expensive?

Two team types that intentionally addresses those questions:

• Platform Team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams.

• Enabling Team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.

Platform team behavior

That’s right. Just envision what is your role as leader, provide a good way for teams to make decisions aligned with the company vision. What are you providing for them to make those decisions? Let’s see some examples of company platform:

• Objectives and Key Results.

• Company Vision and Mission.

• Product Principles.

• Architecture principles.

• Tech radar.

• Product Workshops.

You are just saying… we are already doing that! And that’s right! We have been doing this all along without intentionality.

Now, I want you to think how to create this product about company vision for stream-aligned teams so they can achieve fast flow of change by consuming those resources to be sure they are creating products aligned with the leadership by consuming that internal business platform.

Enabling Team behavior

On the other hand, not all teams can consume an internal business platform and make informed decisions if they are missing key skills or domain knowledge.

If the domain experts or subject-matter experts are part of the management or leadership team, you need to provide the stream-aligned teams with a compelling business platform, but also understand which are those skills gaps and training them to become more effective on the long term on the domain expertise.

That’s when you need to behave as an enabling team. Joining the teams when they find obstacles and helping them overcome those without solving it for them. By helping them become autonomous on those obstacles, you will be able to scale yourself and reduce the need of continuous collaboration.

It won’t be that easy

Leadership/management teams influence hard the company culture. Asking from leadership to migrate from old ways of working (handovers for example) into behaving as platforms and enabling teams won’t happen during the night nor it will be the outcome of a reorg.

Indeed, even though they start migrating into that direction, not all teams would adopt the new way of working. The adoption curve also applies here!

I expect two key adoption curves with the proposal of this post:

• Some leadership and management teams adopting this mindset, and slowly being adopted by the rest of the organization.

• Some teams will start seeing leadership as a platform and enabling team, but some would like to keep the old way of working. Forcing those leadership teams to behave as platforms, enablers, but also as handovers as they were previously doing until the late majority of teams start adopting the new way of working.

All the best on your new journey as leadership as a platform! 🙌

Thank you a lot for reading this post 😄.

I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links:

• 😍 Awesome

• 😐 Okey

• 😨 Bad

I want to expand the idea to help people understand why we need to start adopting the Team Contributor (TC) term over Individual Contributor (IC).

Individual Contributor to refer non-manager roles.

In almost all organizations I worked, we used the terms managers/leadership and individual contributors to refer to different people’s responsibilities.

When we speak about ICs, we usually come with specific expectations.

• They are not managers.

• They might be leaders.

• They do the deliverables like adding a new feature to the application, starting a marketing campaign, and creating new infrastructure, …

• We expect them to be the people that get the job done.

• Etc.

The problem with the term individual is that you cannot deliver value to the customers alone. We already identified years ago that today’s software complexity goes beyond what an individual can handle by themselves.

It’s a team activity.

The team is the minimum unit of delivery.

If you read Team Topologies, you might remember Chapter 3 is about Team-First Thinking. Let me quote a specific paragraph.

In this book, “team” has a very specific meaning. By team, we mean a stable grouping of five to nine people who work toward a shared goal as a unit. We consider the team to be the smallest entity of delivery within the organization. Therefore, an organization should never assign work to individuals; only to teams. In all aspects of software design, delivery, and operation, we start with the team.

Team Topologies - Matthew Skelton and Manuel Pais.

I align a lot with this definition of team and being the minimum delivery unit. It changes a lot the mindset of people and which are their expectations of people.

The term you use is your culture

and how the organization will measure people’s performance.

Let me ask you some questions:

• Do you rely on individuals to make stuff happen or teams?

• When you consider a new feature, do you think about the team delivering it or expect specific people to do it?

• Do you measure individual performance or team performance?

• Do you expect an individual to build a feature and move into production (or the next delivery stage) or the team?

You might say that you care about the team, but your actions might say otherwise.

Start using the term Team Contributor tomorrow.

The language we use determines a lot of our behavior. Start using this term tomorrow and see how your behavior evolves into the team direction.

You might see sooner than later:

• People start thinking more about the team as the minimum unit of delivery.

• People start on how to collaborate to deliver value vs. thinking about their part mainly.

• Performance Reviews start taking into account Team vs. only individual outcomes.

Meme for you

A series of actions that you take in order to achieve a result. - Cambridge Dictionary

A process is ubiquitous in our day-to-day job. We use processes everywhere:

• When describing how we ship a parcel to our customer.

• How you need to request vacations.

• How a new item is added to the backlog.

• How the performance review is conducted.

Processes provide clarity on how to achieve a result. A process isn’t bad per se, and yet we find ourselves in processes that prevent us from being efficient enough, leading toward a “bureaucratic organization.”

I have been part of several startups. I loved startups because they were processless. You know what you need to do, and you move forward. But, somehow, in all of them, you start to feel in the direction of a bureaucratic organization after some time.

I will share the different types of processes, how and when you create them, and how to reasonably avoid being trapped with non-value add processes.

What does a process provide us?

Processes have very appealing properties:

• Improves efficiency.

• Provides clarity on how to reach an outcome.

• Moves the responsibility from the people to the “process itself” (or ultimately to the people that designed the process).

Yet, it has some drawbacks:

• They are a simplification in a complex environment.

• They are static or not adaptable enough in a continuously changing world. A process that worked yesterday might not work today.

Adding a process is a very natural thing to do. Just imagine the next scenarios.

A process that makes sense

A person in the organization wants to take vacations. They are the first to ask for it, as we are in a startup and things are fast-moving, and we never did it before. They talk to the CEO and ask for vacations.

• Jules: Sure! Let me know the dates.

• Alex: 3rd of April to the 10th of April. Recall that the 10th is a national holiday in Spain!

• Jules: Done! Please, add it to your calendar as Out of Office to let your colleagues know you won’t be available during those days.

Then, Jules opens a Google Sheet, creates a new row, and marks that Alex will be out from the 3rd of April to the 14th of April, which means that Alex requested 9 vacations days as the 10th is a national holiday in Spain, which means that Alex has 16 days remaining.

Of course, this doesn’t scale! Let’s add an HR tool to track the vacations, and we ask people to add the vacations there.

🔖 Process added. Asking for vacations

People and culture deparment:

• HR setups the tool (only once)

• When we onboard a new person, we add them into our HR tool (once per employee)

Employees:

1. Ask for vacations via our HR tool.

2. Your direct manager needs to approve the vacations.

Not bad. Makes sense this process.

• ✅ Leads to efficiency as now it reduces the work for all parties (manager, people department, and employee).

• ✅ People know how to ask for vacations autonomously.

• ✅ The process is clear and makes sure each party does their job.

Another example:

Developers: When a new customer signs up in our fintech application, do we need to verify anything from them?
PO: Yes, we need to run a Know Your Customer (KYC) process due to legal requirements. We need to verify their identity when they sign up.

🔖 Process added. KYC process

1. We validate the email and phone number

2. We require a picture of their Identity Card

3. We validate the card using X provider

4. We require a picture of their face with a certain hand position that we determine previously so that we can be certain that it is taken in that precise moment.

• ✅ Leads to efficiency as the KYC process is well-known and can be automated.

• ✅ People know how to implement the KYC process in-app.

A process that might not make sense

Startups go fast, and, for whatever reason, the CTO has been deploying the solution manually (pretend this still happens instead of using templates that come with CI/CD out of the box).

The company grows, and a new developer needs to deploy into production.

Developer: We need to deploy this new feature. How do we do it?
CTO: Sure, let me share with you the process to deploy into production.
… some bash scripts, ssh connections, AWS console changes manually, some manual docker builds later…
CTO: Done!
Developer: Let me capture this as a document.

🔖 Process added. Deploy to production scripts and step-by-step manual

In this example, we added a process that might become the company's standard to deploy into production. The process is not challenged; therefore, the Developer Experience doesn’t have space to improve.

A process is blocking the developer team from continuously improving their delivery process.

Another example. The development team starts to grow, developers start building features, and we find that we are not aligned late on the delivery process.

PM/PO: Why are we doing this feature? Did we align with our stakeholders before starting?

(Someone did something that they shouldn’t suppose to do, we add a process to prevent it to happen again).

🔖 Process added. Product delivery process

PM/PO:

1. Manages backlog

2. Set priorities

3. Define Definition of Done

Developers:

1. Assigns themselves into tasks

2. Reports blockers there

3. Asks for QA when the feature is ready to be released

Here we can see how a process added bureaucracy to the organization. After some months, this will become “That’s how this is done in the company,” it will be harder and harder to improve the development processes.

They all are processes, but they mean different things in their contexts

We have seen different types of processes:

• Operations Process: How to ask for vacations

• Business Process: KYC

• Infrastructure Process: Deploy to production

• Team Process: Backlog management

and more.

We can sense that processes by themselves aren’t a good or a bad thing. They depend on the context we add them and how much rigidness they add to the organization.

Why do we end up in a bureaucratic environment, then?

One of the key mistakes we all make is to add a process to solve people's problems.

As the company grows, we have accumulated human mistakes that we aim to prevent by adding new processes.

The process can be desirable for multiple people in different positions:

• Management: I want to avoid this mistake from happening again.

• Team members: I don’t want to make this mistake again. Tell me how to do it.

In both cases, we move the responsibility from the people to the process. Ultimately, if you follow a process, you are doing your job.

A process that aims to solve a people’s issue won’t be able to capture all the complexities of a fast-changing environment that requires high adaptativeness from everyone in an organization has been added.

A process that addresses a people problem will mitigate the issue in the short term but cause more in the mid-long term.

After some time and several processes like this later, you find yourself in a very tight environment that suddenly looks bureaucratic.

The root cause of ending up in a bureaucratic environment is the false expectation that you can fix your people's problems with processes.

Which is the alternative?

The journey won’t be pleasant as you must acknowledge that mistakes are essential for an organization to learn continuously.

People are the biggest asset, and creating an environment to help people to thrive is essential for long-term success.

When mistakes are made, your reaction is critical regardless of your role.

Do you consider a mistake something that brings problems to the person that caused it, or does it bring learning to the organization? Depending on your answer, you will become a bureaucratic or high-performing organization.

When some mistake is made at the human level, I like to remind myself of this Norm Kerth quote:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

From there, I ask myself the next questions:

• In which context did this situation happen?

• What led people to do what they did?

When we answer those questions, we can understand the people's context and then assess if we can solve the situation with:

1. Organization principle. A guiding principle for a certain situation where people can assess if the principle applies to their context and, if not, apply their sense or align the expectations.

2. Sharing context about which is the desired outcome. Often, when we share our desired outcome, people will adopt their habits and methods to fit it without needing a detailed step-by-step process.

3. Adding a process.

Meme for you

Today, I am sharing the need to be explicit on how management and leadership shall follow the same principle of paint drip people.

Paint drip developer

A paint drip developer says you will learn about different skills to deliver value over time as the other products/projects need you to grow those skills. They are becoming what is known as a generalist.

Instead of going deep on one area, let’s say Java. You go broad, learning a little of here and there. Not only at tooling, frameworks, and libraries but also in testing, DevOps, …

Here is an illustration using the concept of a T-shape developer to clarify that it is not only about technical knowledge.

Subscribe now

Paint drip manager/leader

If you are transitioning or have already transitioned to an engineer manager/leader role, it is quite probable that you are already a paint drip engineer. You have been looking at the big picture and understanding multiple disciplines to deliver value. That tends to help people to reach leadership positions within an organization based on my experience.

Yet, when we start our manager/leader journey, some forget about the concept that helped us grow. Be a paint drip person.

It is probable that you already have curiosity in another area, say, product or design. That’s good! But that’s not the end for a paint drip manager. It might be seen as a T-shaped manager tho!

A good manager should also be a paint drip person in the long term. Of course, do not aim to be good at everything as well as you did on your engineering journey! You made one skill at a time over your all journey.

Understanding other roles outside engineering leadership will help you better understand your organization works and help when people are missing in those critical positions until you onboard the right people.

If you are in a start-up like myself, you might find yourself doing roles outside your expertise all the time. Those moments define an excellent paint-drip leader. You adapt to the different organization and team needs by helping where you are most needed.

I have been lucky to work with many paint drip people. They were engineers, designers, product managers, founders, people, and more. They all shared the same triad; learning what is required to push the mission forward.

I hope this post finds you at the moment to continue exploring and learning things outside your role. They will help you grow outside your comfort zone!

Side note

Leadership is hard enough to take things easy—one thing at a time.

First, become confident with your skills as an engineering leader, for example, but keep learning from time to time from other roles.

All the best in your journey! 🧡

References

• Paint drip people - Kent Beck

• 5 engineering manager archetypes - Pat Kua

• Generalist or Specialist — welcome to the PaintDrip Model - Bernardo Carneiro

• We need more Rogers - Bill Gates

• Range: Why Generalists Triumph in a Specialized World - David Epstein

Meme for you

What I didn’t know is that you also have some accountability for the decisions made in the past before you were there. Or at least, I ignored how much they influenced all the decision-making.

Understanding the Legacy

I’m a software engineer. I have dealt with Legacy Systems, refactored them, added monitoring to them, adapted them to the new business needs, and even made the obvious mistake of redoing a Legacy System from scratch.

After several years of dealing with Legacy Software Systems, I thought I knew how to deal with them.

Damn. Legacy Software Systems are easier than Legacy Sociotechnical Systems. In addition, I also ignored that all Legacies are Sociotechnical Systems. Therefore, when I dealt with Legacies, I ignored the Sociotechnical part.

Legacies can show in many forms, but I would like to focus on two main categories:

• A Legacy without people working on it. The dev team might be working on something else, or they left the organization.

• A Legacy with people working on it. People are still working on the products/projects, but leaders/managers or people with the vision/purpose left the organization.

The former is the one I’m most familiar with. A System is abandoned in pursuit of new business models. It starts with a sentence as “we will put this product in maintenance mode to focus on more business priority stuff.”

The latter is one I will speak about in this post. That Legacy is harder to identify. It’s not obvious it’s a Legacy, and it doesn’t feel like it has technical debt only. It can feel like bad management/leadership, poor vision, too much leadership rotation, or lack of direction…

I experienced it when I joined as a leader in a team or tribe.

It happens in other scenarios when an experienced team member or a person with strong influence like a Product Manager leaves and they are being replaced.

This new person will be dealing with a Legacy Sociotechnical System. By having this understanding, we can act on it and acknowledge our ignorance of the past.

Leader A leaves with huge knowledge about the decisions made, commitments, people’s growth expectations, why the teams are organized the way they are, and more. Leader B ignores all of that.

Side topic. Here is a Twitter thread about rotation, learning, and how it affects decision-making quality 👇‍

Avoiding the trap of “I can do it better”

From now on, we will assume we are leader B. We are joining a team or a tribe, and our leaders start onboarding us in the company context.

Our leadership is busy and we will go straight to the points on the onboarding.

• Our culture and purpose

• Our deliverables

• The team structure

• …

• What’s not working and needs to be fixed

Leadership wants us to fix what’s not working. That’s why we tend to focus on sharing the bad parts. Still, we don’t share a thing that it’s so important and valuable. What worked. Or the experiments and decisions that led the company where it’s today.

By listening to what’s not working, we start creating ideas and beliefs about why it hasn’t worked. And when we join the team on the day to day, we seek those facts that can confirm our beliefs.

• Aha! Here’s technical debt, I could have done that better.

• I see, the team isn’t cross-functional!

• There’s not enough testing!

In less than a month, we have plenty of facts that confirm our beliefs. Previous leadership didn’t know their stuff.

Does it sound familiar to you? You just got into the trap of Confirmation Bias.

Confirmation bias is the tendency to search for, interpret, favor, and recall information in a way that confirms or supports one's prior beliefs or values - Wikipedia

To make it worst, you find some decisions that you clearly know that they are wrong.

We couldn’t have done that mistake, we’re better than average. Damn! If we could have joined the team earlier, all that decisions wouldn’t be there and we can be in a way better place now!

In the end, we’re a better X than the average. We will do it our way.

Do you know what is that? Another type of Cognitive Bias. In this case, it is the Overconfidence Bias.

The overconfidence effect is a well-established bias in which a person's subjective confidence in his or her judgments is reliably greater than the objective accuracy of those judgments, especially when confidence is relatively high - Wikipedia

👆‍Image of ourselves when we realize and accept we make mistakes like everyone else and we do the best we can given the situation at hand.

We need to be careful to not accept all the information that we receive as facts. We all have our own perspective of the complexities, what’s working or not working.

When listening to what’s not working, be open-minded.

What led the previous leader to do what they did? What are we ignoring in their context? How can we learn from the past decisions and why they were made that way?

Honor the past

People's work and effort to put the business where it’s today cannot be underestimated. Indeed, it should be honored.

Their work have helped you to get the position you’re in today, they are expecting a lot from you, and you should be grateful that now you can help them in achieving more for more time.

Always consider that you don’t know why they did what they did. Challenge your own beliefs.

You are building on top of other people’s legacy!

It doesn't mean you cannot change it if stuff needs to be changed! It’s about being mindful about you not knowing the full story.

Commit to the Legacy

It’s not about starting from scratch. It’s about getting the Legacy and improving it.

I understood that you cannot adapt everything to your vision or ways of working when you join an organization the hard way. But after fighting the reality and taking a lot of energy with it, I started to accept the Legacy.

If I accept some of the decisions, even if I disagree, I can take steps in a new direction.

If I understand the previous vision, I can understand why the decisions, and we can build a new vision on top of it. That new vision will take into account where we come from. Instead of forcing a team into a new scenario all of a sudden, we take into account where we are and where we want to go.

My recommendation is that when you join a new team/company in a leadership position. Commit to the previous decision as if they were yours. Own them, understand them, and it will bring the different learnings that come with them.

Only then you’re able to drive a new direction to something you believe is better.

Similarities to how we deal with Legacy Software Refactors

• Would you change a full legacy system to a new brand new system from one day to the other?

  • Then, why would you replace a team with another team?

• Would you change an MVP Architecture to Hexagonal Architecture from one day to the other?

  • Then, why would you change the ways of working from one day to the other?

• Would you replace some behavior of the Big Ball of Mood Legacy without adding the proper tests to know if you broke something?

  • They, why would you start moving pieces without being careful about what you broke?

We are dealing with people, and when Sociotechnical System breaks, it will be orders of magnitude harder to fix.

Closing

We need to be way more careful when dealing with Legacy Sociotechnical Systems.

We are dealing with highly complex adaptive organizations, and the best way to manage the future is to understand the past first.

The Legacy is your best ally to build on top of it. Instead of fighting it, join forces to evolve together.

Meme for you

It's a common mistake to give autonomy to a team that needs direction. In this post, I explain the leadership style depending on the team state combining 4 stages of a team with Elastic Leadership, a book I have relied a lot on how I lead nowadays.

Why this post

I have seen a huge surge within the industry to “empower teams” and give “autonomy” to be a “good leader”. And I mark “good leader” in bold because that’s what’s concerning me.

The focus is on the leader instead of the team, and I’m concerned after seeing bad practices from leadership styles going in this direction that harms more the team than it’s beneficial, yet always with the best intentions.

As leaders, we are responsible and accountable for the team and we need to be careful about the way we lead, how it impacts the team and the business.

That’s why I consider giving autonomy for the sake of “being a good leader based on industry standards” without a careful understanding of the teams and business situation to be a red flag on the leadership 🚩.

Again, behind empowering teams, there is always a good intention, yet I find that in leadership we miss guidance on how to move from a “Command and Control”, seen as bad but necessary as you will see in this post, to “Self-Autonomous teams”, seen as good but challenging to become. I hope I can help you to connect the dots!

Forming–Storming–Norming–Performing Model

A lot has been already written about Tuckman's stages of group development or the 4 stages of a team. I’m skipping this part and assuming you’re already familiar with it. If not, I still think you will be able to follow the post due to some pictures

Looking at the 4 stages of a team. We can see that we want to reach Performing Stage, where the team makes decisions on their own, which is the same end goal as "self-organizing teams" described in Elastic Leadership.

Elastic Leadership Modes

Both models say the same, Self-Autonomous/Performing-Empowered Teams is what we want. No discussion here! But how to reach that moment? 🤔

Connecting 4 Stages of a Team with Elastic Leadership

Let's see the leadership style against the 4 stages. They somehow match so well, it even seems natural.

Yet, Elastic Leadership helps you to know how to navigate between modes, read the situation of the team, and adapt yourself to the team and business needs. A dimension I was missing when I started to lead teams.

Subscribe now

Elastic Leadership gives you guidance on what to do to move between those stages in a healthy way, how to detect in which stage you’re.

IMHO, Elastic Leadership is way more powerful compared to the 4 stages of a team due to its completeness and simplicity.

Everything is dynamic

Reality 1. You move between those models several times per quarter

My experience is that staying in the Self-Organized Mode or Performing Stage for a long time is super challenging and requires a team with high cohesion, high trust, and experience working together in the same context for a long time.

I don’t know you but nowadays, with the high people rotation, it’s quite hard to get to this point. That’s why you usually move between the modes frequently during the quarter or even a month.

Reality 2. The team might be autonomous in one part but need direction in another.

What I learned is that the team goes through several moments of maturity in specific areas but not in all of them. It’s kinda obvious… but I needed to step in a rock to learn that 😅

I would also map the team maturity level depending on the responsibilities we have. Something like:

I usually map those things that we do, and focus on the maturity moment to the team to reach that mode of “Self-Organized”.

The things that are more day-to-day, that’s the first thing I aim to delegate and help the team become Self-Organized, meanwhile, I keep with the more high-level stuff until a good maturity is gained that, on adverse conditions, there’s no step back to a previous mode.

This process is slow yet I didn’t find a way yet to make this faster without damaging the teams and the business.

Wrap-up

What I aim to show to new leaders is that, even though they want to be in the performing stage with an empowered team, giving them autonomy, they cannot skip the 4 stages of a team and they do need to adapt their leadership style to the team's needs.

And it implies being a Dictator using a Command and Control Style. Which it's good as long as you do your job to move into learning mode to at the end be in performing mode.

The worst we can do as leaders is wrongly read the team situation and adopt a leadership style that harms more than the opposite. Like being in Forming-Storming and be using a Self-Organizing Mode.

Book reference

The book Elastic Leadership gives you guidance on how to move between stages/modes. 100% recommended.

Tweets for you

In this post, I like to share with you the huge learning I had as a Leader of, I would say, 2 teams in at least 3 different contexts and moments.

Ego factor ( ￣^￣)

I joined Creditas in March 2021 as Engineering Manager, full of energy and ideas, biased ideas, and willing to make an important impact soon. Half needing to prove myself, half impostor-syndrome/ego.

I admit I have an ego, in the past years, it has been conditioning my life decision-making. After some time and therapy, I have been able to recognize when I’m being led by it instead of being myself.

The ego also affected, to some degree, how I lead the team, and in specific, how I introduced change just after joining Creditas. Lucky me and the people around me, I have been able to manage it better and better.

By the book 📕

You might know that I’m a book lover and sometimes I’m square-head, if I don’t find something logical or that doesn’t make sense, it’s hard to convince me.

I had an opinionated vision of how an engineering team should work, in terms of practices, methodologies, and team composition. I’m always open to new information to make better decisions, but the degree of changing direction sometimes I’m as flexible as I should be.

It happened when I joined Creditas. I wanted to help build an incredible team, a team that:

• Does Pair-Programming

• Trunk-Based Development

• Continuous Deployment

• Observability and Monitoring

• Test-Driven Development

• …

That’s a lot, and it means asking the team a lot. You can either:

• Be super strict during hiring, which doesn’t make any sense because very few engineers excel at all that stuff, and it will take you years to build the team.

• You hire people with an amazing attitude and you coach those skills

I went for the second option.

Attitude is key, but it depends 😅

It depends on how you are introducing change.

Push based system

To be honest, most of the resources available are about this type of change. Digital Transformation, Agile Transformation, (or the wrong interpretation of them)… Someone at the top decided that we need to do XYZ. Yet, we think that by introducing coaching and learnings we are doing a great job.

You present the idea to the team.

What about trying this? It comes with training and we will do some katas, book clubs, or discussion panels.

Because you hired people with a great attitude, you probably get a yes to try new stuff. They hopping that today, in this job, they have more freedom to decide how to work and try new stuff.

Today, I disagree.

Because my expectation was that, after the training, the methodology, tool, or practice be implemented in the team. Yes, you can think of I’m being a good leader because I provide training during working hours! I’m so good!

Still, a top-down approach or a Push-Based Approach. It has several drawbacks:

• You don’t give the team the option of not adopting a new methodology, practice, or tool.

• Looks like it’s forced to be done this way, yet they might not feel the improvement you were willing to get from the new approach to do stuff.

• Team members feel trapped and unable to say no to the new approach, leaving them few actions to improve their work environment, one of them is to leave the team or the company.

You might succeed with the first or maybe two times you purpose something to the team to try, after some time, you will start experimenting some resistance to change.

You’re burning people and their good attitude. Because you’re not giving them the option to say no.

That’s when I learned more about Pull Based Systems to introduce change.

Subscribe now

Pull Based Systems to drive change

Pull Based System to drive change is about creating situation awareness about the problems or the improvements you think are worth addressing with the team, yet giving up to the team adopt them whenever they feel more confident they are ready to experiment to introduce an improvement.

As a leader, you’re not in the day-to-day. Assuming which are the next things to improve are exactly that, assumptions. You might know which are the good things that are worth improving based on your experience, and there’s a good shot that you’re right.

Yet, it’s better to collect data and metrics to show the team how you resonate about the things you consider important to be improved.

Showing the metrics to be improved instead of the improvements

That’s your role as a Leader, drive direction. What I have been investing more and more time with the team is about how I think it’s best to measure team performance and drive actions to improve it, aka Situation Awareness.

4 Key Metrics of Accelerate

You can learn more about the 4 Key Metrics in Accelerate’s book or the 4 Key Metrics Community https://community.4keymetrics.dev

You can also find some posts I have about them like:

Aleix's Learnings

How to measure Lead Time based on your Continuous Integration Strategy

What is Lead Time? Lead time is the time it takes to go from a customer making a request to the request being satisfied. We can translate the previous sentence as the time of a card that takes move from Ready to Start to Done in a Scrum or Kanban board…

Read more

4 years ago · 1 like · Aleix Morgadas

Cognitive Load

A concept I learned from Team Topologies.

When we talk about cognitive load, it’s easy to understand that any one person has a limit on how much information they can hold in their brains at any given moment.

Understanding if the developers have a high cognitive load, we can take actions to reduce them. Maybe they are unable to apply direct improvements compared to the 4 Key Metrics, but being able to identify if they can take some actions is awesome.

Flow Efficiency

The formula is straightforward. Yet, measuring it has been a good challenge. Learn about Flow Efficiency, and when you feel confident start giving that to the team.

I consider the first two, 4KM and Cognitive Load, to be better for the team to drive improvements than Flow Efficiency, yet take it into account.

Creating the picture of Ways of Working

⚠️ I’m still experimenting with this idea, read with caution!

Just imagine that you, instead of forcing down the methodologies or ways of working to the teams, you create a good picture about the things you aim to promote inside the company, like a vision of “we consider a team is going with software excellence when they start adopting/excelling at X, Y, Z practices”.

Then, teams will know what you are going after yet you’re not imposing it on them. Each team is in a different context and situation at hand, expecting that rolling out those practices to all of them and causing the same impact is non-sense.

Instead, each team with the situation awareness can go to a group of people that are experts in each practice or methodology you want to introduce into the company, and they ask for help on that matter.

This is a mind-blowing approach 🤯

The team accepts the change based on their pains, availability, and willingness to improve. You don’t push change but you help the team to pull the improvements.

Did you notice the paradigm change here?

Also, I wanted to share that this Pull Based System follows the adoption curve. Those willing to take the risk and adopt the practices are more willing to go there and adopt them proactively, and those that are more skeptical will adopt them when they don’t have another choice.

I learned that it doesn’t matter if skeptics don’t adopt the new ideas, they won’t do it either in Push or Pull-Based approaches. Yet, the enthusiasts and visionaries will lead the change in the teams for them without feeling the pressure of push-based.

A WIN-WIN SITUATION!

Continuous Improving Mindset

Didn't I share with you words of Accelerate yet? 🤣 Sometimes I feel that I repeat myself a lot.

Yet, Accelerate Book had a key part in driving change in the team in a Pull-Based Approach. I can summarize Accelerate as a Continuous Improving Mindset.

Early in the creation of the team, we did one thing. Create the Accelerate’s Book Club and dedicate one hour a week to discuss the chapters.

Since then, the team drives most of the improvements by themselves. I’m not saying that they do everything by themselves but proposing what they want to improve, and then we find the way to do it as a team.

I consider at least 3 different scenarios of improvements:

• Team self-sufficient. The team identifies and improvement and they just implement it without leadership support.

• Team with leadership support. The team identifies, but the improvement area is either out of their boundaries or requires help because there’s no team member with the knowledge to drive the improvement.

• External support. The improvement is out of the team and leader responsibilities boundaries and requires organization support.

I have underestimated how the team can come by themselves with solutions, and drive them, and I even notice those improvements in my day to day but able to identify the good outcomes on metrics like Lead Time and Change Failure Rate of 4 Key Metrics.

Summary

A pull-Based System to introduce change is awesome and we can learn a lot by following this approach, yet it has downsides. Mainly regarding the team’s continuous improvement mindset.

In the end, it’s a trade-off and it will depend on your situation.

I wanted to share with you a new approach I learned and that it’s paying off! I hope you enjoyed it! Help me create more awareness for other managers and leaders that only know push-based approaches as I did some months ago 😄

Share

Book and Course references

Dynamic Reteaming

One of the best discoveries this year. It’s not explicitly dedicated to Pull Based Systems to introduce change, but it covers a good portion of it on the mindset behind Reteaming. Worth every penny.

Platform as a Product - Team Topologies

In the Platform as a Product course by Team Topologies authors, they address the topic of the adoption curve of a Platform when the platform is optional, and how this brings a lot of value to the platform itself.

By applying the same concept for methodologies, you need to create a set of Ways of Working that is enough good that people adopt them because they provide high value in their day-to-day job instead of being imposed.

I will dedicate a post specifically about Flow and what I’m learning from Manuel Pais and Matthew Skelton.

Meme for you

To be honest, it scares me. Moving from being a hands-on contributor to being a manager was already being in the Learning Zone. Managing Managers, it’s my growth zone.

First thing I did, setting clear expectations 😵‍💫

When my manager came with the challenge proposal, I first thing I felt was Impostor Syndrome. I was like “please, wait until I have been managing a team for a little longer, I might be screwing it up and I’m not noticing it”. I might have had some quick wins as a manager, but time is the only factor that will tell if I’m doing it well. After all, you need time to see how the decisions impact you in the long run.

But later on, when I started noticing that I was feeling uncomfortable, being outside my comfort zone, I knew that it was the right path. That’s when I did the right question:

- Aleix: What do you expect from me when managing managers?
+ Manager: You need to find a way to help other managers do what you’re doing.

Following up question for myself, what I have been doing? 🧐

As a manager, I did a ton of stuff for the last 6 months since I joined Creditas. Hiring new team members, understanding the product, changing from Pull Request Collaboration to Pair-Programming with Trunk-Based Development, removed handovers between teams, managed a couple of big fires 🧑‍🚒, helping in adopting some agile methodologies, and more.

Should I replicate the same decisions? Of course not. Those are the visible outcomes of what I have been doing.

Understanding where we are, understanding where we want to be, and managing the day to day to get there as soon as possible.

Understanding where we are 🗺

There’s nothing more frustrating to me than assuming I’m a place and then figure it out that I’m somewhere else. Because then, the decisions you make won’t have the outcome you might expect.

Still, there’s a good thing about getting a different outcome than you expected in the first place, it tells you that you had assumed something that wasn’t actually valid.

What do I do to know where we are? I use the next tools and techniques to do so.

(Almost everything I do is based on Accelerate book by the way)

4 Key Metrics (4KM) to understand Engineering Maturity

The 4 Key Metrics are essential in the way I manage time since it helps me to drive Engineering Maturity in a guided way.

Some people have the conception that being on a Low Performing Stage is a bad thing. Indeed, I consider it good to know you’re on a Low Performing Stage because it helps you to make decisions to move into Medium Perform Stage and so on.

By knowing in which stage you’re at, you can ask the right questions and start finding which is the next small step it will help you reach the High Performing Stage.

Agile Fluency

In the past, I thought that either you’re agile or not. A binary condition. I was so wrong.

Instead, using the Agile Fluency Model, you can acknowledge that there are steps between the pre-agile world and an organization with a strong agile culture.

This model helps you to understand where you’re as a team and as an organization.

Team Topologies

Maybe the Book/Course that is impacting my management career the most.

With Team Topologies, you’re able to assess several things but the most important is Flow of Change.

Are our product teams able to ship value fast? Do they need to do handovers between teams to release to production? Which are the collaborations between other teams? Do we have a strong dependency? Which are the collaboration expectations? How much should our collaboration stand for and for how much time?

Understanding Culture

Understanding the culture you’re in it’s so important and yet so difficult and time-consuming to change. By knowing in which culture you’re, you can take better approaches to implement changes.

• Pathological (power-oriented) organizations are characterized by large amounts of fear and threat.

• Bureaucratic (rule-oriented) organizations protect departments. Each department insists on their own rules, and they do things by their book.

• Generative (performance-oriented) organizations focus on the mission. How do we accomplish our goal?

Lean Management

Understanding the dynamics of management impacts directly how the team ship value. We might have Continuous Deployment, monitoring, and the dream architecture. Still, we need management that helps with delivery performance.

Based on my experience, the most impacting decisions are:

• Limit Work in Progress: How many things we do in parallel. By having a small WIP (2-3 WIP for a team of 6 developers), we will be focusing on shipping work faster overdo a lot of work, and ship none.

• Lightweight Change Approvals: Making changes easy and smooth, we are able to test more often and react fast to failures. Focusing on learning and experimentation rather than preventing falure.

Lean Product Development

Accelerate talks about these points:

• Work in Small Batches

• Make Flow of Work Visible

• Gather & Implement Customer Feedback

• Team Experimentation

They all are key to improve the software delivery effectiveness. I relate those points with:

• Are the User Stories Vertical Sliced?

• Are the User Stories small enough to be done with less effort and still provide value to the user?

• Is all the work that’s being done visible?

• Do we allow time for some architectural spikes or do we jump directly to the most common solution?

Understanding where we want to be 🧭

I use the concept of North Star ⭐️ to share with the team the vision of where we want to be.

Regarding Engineering

Being honest, understanding where we want to be as Engineering is the easiest one I found.

How can we achieve be on a High Performing Stage based on the 4 Key Metrics?

That’s it, that’s the North Star. It might take you years to get there, but the vision is set and clear.

Regarding Management

Management to me should be fluid, we need to adapt to the team's needs and the situation at hand. I don’t have a direct way to measure good management. Please, tell me in the comments if you have a way to do it!

Leave a comment

Still, I could say it’s about adopting the points I mentioned before:

• Vertical Sliced User Stories

• Lightweight change approval

• Making Flow of Work Visible

• Boost Team Experimentation

• Gather and Implement Customer Feedback

• Empowered Teams

In the end, being customer-centric on the decision-making process and empower the team to help to be a self-organized team.

Managing the day to day

I described how I do to know where we are, and also where we want to be. Now, I can share with you a situation that happened to me and how we took the decision.

Fast Flow of Change

Remove Handovers

When we started, the team had a strong dependency on two other teams.

• Team A: Doing the Backend of the Product Solution

• Team Mobile: Doing the Frontend Part for the B2C User

• Team B: Doing the Frontend Part for the B2B User

You can imagine the problematic, different teams, different goals, different roadmaps, and we depended on each other to deliver software. 💩

It showed different things:

• Based on the 4 Key Metrics: Poor Lead Time up to 30-45 days.

• Based on the Team Topologies: We had several handovers that prevented a fast flow of change.

Decision: Move the Frontend Parts for the different users to the Team.

That’s where we want to be. Then we made decisions to be there, which it might take us up to 3 months to achieve End-End Product Ownership, but still, it helps us to be autonomous in delivering solutions to our customers. Impacting positively in the Lead Time metric of the 4KM.

Meme for you

Context

We were two different squads working on two different products during Q2 2021, but working in the same tribe. We knew each other due to some shared meetings we had during the weeks, but we didn’t collaborate closely yet.

During the beginning of Q3 2021, we merged both teams to work on the product A people from Brazil were working on, meanwhile putting on hold product B we, from Spain, we have been working.

We knew that:

• People from Brazil had a high product and technology context

• People from Spain had a low product and technology context

• Existed a high cohesion between old team structures

We needed to work on:

• Knowledge sharing

• Building trust between team members to be one team instead of two teams working separately

• Build the right ways of working that support a Global Team

Starting with the obvious

Handling time difference

First of all, focus on making great use of the overlapping time.

We configured our Google Calendar to show each other time zones (you can see that in the next Screenshot). It gives you visibility on which hour you might want to schedule a meeting to respect each other working hours.

We aim to have as much overlapping time as possible, and we discovered our first cultural differences. Our lunch hours are quite different!

• 🇪🇸 Spain in isolation. From 2 pm to 3 pm

• 🇧🇷 Brazil in isolation. From 12 pm to 1 pm

This leads us to have only 3 hours of overlapping time 😣, we needed to adapt each other lunchtime to go from 2 to 4 hours by changing our lunchtimes.

• 🇪🇸 Spain in a global team. From 1 pm to 2 pm

• 🇧🇷 Brazil in a global team. From 1 pm to 2 pm

By doing this, we could set that our overlapping time to host synchronous meetings and collaboration to be:

• 🇪🇸 Spain overlapping hours. From 2 pm to 6 pm

• 🇧🇷 Brazil overlapping hours. From 9 am to 1 pm

What we did then is creating in hour shared calendar a recurrent event as Focus Hours dedicated to team needs. Our goal is to give priority to our synchronous meetings during those hours to respect each other working hours.

Communication Barriers

We are in a team that not everyone is fluent in English, and it’s causing different difficulties in working as a team.

In order to minimize the language barrier we do:

• Written always in English 🇬🇧

• Meetings, we give a space to practice English. Still, when someone is unable to share their ideas in English, then we can fall back to our mother language, and then someone in the team that knows both languages translates the ideas.

This issue cannot be solved from one week to another, and we need to be patient with each other when someone isn’t fluent in English. Still, after one month of practicing English each day, we saw good improvements between team members 😊

My suggestion, create safe spaces to practice English. I wouldn’t recommend team meetings to be a good place to practice it, but during pair programming, it’s a perfect space to practice English and not being worried to fail.

Boosting Knowledge sharing through Pair Programming + Weekly Rotation

By doing pairing between team members from different countries we achieved a huge learning curve in a small period of time. We set up the pairing as:

• Pairing needs to happen between new team members (Brazil and Spain)

• We rotate once a week

Then, when you rotate the pairs, you mark who paired with who.

This helped us in:

• Knowledge sharing on Architecture, Product, Operations

• Knowing each other and building relationships

• Having safe spaces to practice English

Asynchronous Collaboration and Communication

With only 4 hours of overlapping time, you better make good use of it. We needed to work on how we shared information. Before, we relied a lot on meetings to share context and information.

As a team, we limited the information-sharing meetings as much as possible. Instead, we started to use more and more Confluence to hold information that needs to be durable and volatile information in Slack Theads.

• Async Dailies. We run the daily async, and people share that info whenever they can.

• Meeting notes are stored in Confluence in a section dedicated to host meeting notes and decisions made.

• Discoveries in problems we share the information asynchronously, and we use the meetings to make decisions.

This helped us to use the available overlapping time for collaboration and decision-making instead of informing.

You can see more tips on Asynchronous in this Twitter thread.

Work on expectations on each other

We hosted a session about what we expect from each other, on what we like from people we work with and people that we don’t like to work with.

It helped us to know what was expected of each team member from each other, and then we came up with a Team manifesto. A set of values we honor to work with and we keep each team member accountable.

You can see the team building session explanation here https://www.funretrospectives.com/that-guy-this-guy/

Things I didn’t expect that happened to me as Engineering Manager

Direct Feedback and High Context

I tend to be quite direct about what I think can be improved. Sometimes, without giving all the context on what are my suggestions contexts.

After a month of working with Brazilian people, I found that the way we speak in Spain can be interpreted as rude in the Brazilian culture.

My suggestion is to not assume how people are used to receiving and giving feedback. Dedicate time to understand each other expectations on how people like to collaborate. Then, make these differences explicit between each team member.

Decision Making

When you move async, where the decision happens becomes blurry. As Engineer Manager, I expect the decisions to happen either in meetings or Slack Threads. I would say, that wasn’t as obvious as I expected.

Decisions are always made with the necessary team members, and you need to be explicit when you’re expecting people to collaborate on the decision-making and in which format.

Still, be aware that sharing the opinion in written format is way harder to spoken way. As a team lead, you need to create a space that everyone is able to share what they need to communicate for the decision, otherwise, there’s the feeling that some people didn’t have the chance to express themselves in the decision-making process.

I moved Decision Making again to full synchronous, we are not in a moment to make them asynchronous yet.

Book Recommendations

Subscribe now

I would recommend everyone The Cultural Map Book to everyone that works in a company with people from different cultures. We often underestimate how the cultures influence us and how biased we are towards other people.

Don’t get me wrong, you should care always personally for other people since each of us are different, still, we need to understand the culture of other people to not get misunderstandings.

Meme for you

During the conversation, the next question popped up:

What do the office mean to us after the pandemic?

We all agreed that the pandemic changed how we work together, and we learned how to adapt ourselves to a remote working environment in an extreme context. Still, working remotely and forced to work from home are very different scenarios.

So.. what does the office mean to me after the pandemic?

A safe space for communities

What’s a community to me? A community can be:

• A team

• People sharing an interest in a specific topic

• A Software Crafting Meetup event

• LGBTQ+ Meetup

So, even though it’s a company office, you can make good use of it not only for work but also for non-work-related things that bond people together.

That’s what means the office to me, a space to meet people with shared interests, either from work or non-work.

What does not mean the office to me?

• A place to be “productive”

• A must-go place to produce software

• A place to manage people to see if they are doing their work

• A must be place to feel that you belong to the company

Which benefits do I see in the office?

RELATIONSHIPS.

It just heavy help to build relationships and trust between people compared to make it online. When I joined Creditas during the pandemic, I needed so hard to meet people in real life to create this relationship with them.

It’s super different when you go remote when you already created the relationships vs when you join a new company.

Sure, create them online is possible, but, still, at least one dimension harder compared to in person.

So… the hybrid model

A hybrid model should operate with the next principles in my opinion:

At team level:

• Go to the office is a choice of the individual with shared responsibility.

• When one person on the team is remote, then all the interactions are remote first.

• All the information (diagrams, kanban board, …) must be digital to not depend to be in the office to have all the information to work.

• No important decisions are taken that affects the team happen when team members are remote

The rule of thumb here is do not discriminate against a person for being remote. We have to be aware to create an inclusive workspace, and it is about involving people that are working remotely as well.

What happens with _?

• Workshops

• Town Halls

• Office events

• Important Meetings

• etc etc

It’s up to the team to decide the format, either being in the office or being fully remote or a hybrid.

The Hybrid Model adapts to the current team needs

Giving autonomy to the team to decide the way they work is essential. They know their current situation, so they can adapt if they prefer full remote, full office, or just in demand. And they know what’s best for the team.

Some situations to give an example:

• New team. People don’t know each other, they need to create relationships. Working from the office seems more aligned with the team's needs.

• Team working together for a long time. They know what they expect from each other, why not working from home and be more productive? Let’s get stuff done!

• Part of the team working at the office, part at home. OK! No problem!

• The team has been working together for a long time, but there’s a new product that needs discovery. The team decides that the best format is to be at the office and run a workshop. So, they plan to have a workshop from 1st May to 5th May, and they all commit to being at the office for those days.

The main takeaway is that changing from Remote to in Office to back to Remote will be normal, fluid, and expected. As a team, we need to adapt ourselves to the current needs, and that will include the working space as well.

The only requirement for a Hybrid Model to work well is that the team needs to be Remote First.

Hybrid Model will be a key factor for companies

From the employee point of view, it has multiple benefits:

• You are not required to go to the office as was expected before

• You feel trusted by the company and your colleges to deliver without needing to show up at the office

• You’re free to work from home and attend your non-work-related things, like taking children to school, getting a haircut, working from another city/country, …

• You still can go to the office to meet people in person and do activities that are more efficient and fulfilling in the office, like meetups, hackathons, workshops, or just sharing a meal with your colleagues.

For the employer, it means multiple things:

• Giving freedom to people will help people to stay. People are more conscious about the benefits of remote working, and giving the freedom to choose will (or already is) a must.

• Keeping the office will help to create a community, and feeling of belonging, that is still harder to accomplish on remote work. So, people don’t feel like it doesn’t matter to work with you or another company, but people have a space that they can enjoy or use to fulfill their needs.

So, the hybrid model will help in:

• Improve productivity on the tasks that are better done at home

• Still having a place to run ceremonies and activities that are better dealt at the office when it’s possible (sometimes you’re really full remote and you can achieve this)

• Create a stronger feeling of belonging and improve the company attrition by keeping the best talent

Last but not least

I would like to share with you a video from Simon Sinek about Remote Work that I’m quite aligned with his opinion.

Meme for you

🔔 Disclosure! Meanwhile I feel more confident with the development books, with this recommendations I’m more prudent. Be cautious that management/leadership has huge implications on people, do not apply what books says without double checking the context and situation at hand.

Leadership/Management… the books cannot tell you that much if you miss the experience, and the real experience will be always more than a book can explain to you.

In this topic, I find in those books about leadership/management to help me to not make already known mistakes in the industry and somehow avoid them by being aware of them, but, still, you will make mistakes and you shouldn’t be blocked by fearing to make them. Just be honest with yourself and your peers and let them know when you made one. People tend to understand. #empthy

My recommendations are quite biased on the kind of person I’m, so they might not apply to the kind of leader/manager you want to be. I would say that I’m:

• Introvert. Even though I need to talk with a lot of people, I need to be conscious about how to use my energy in a meaningful way so that I don’t get exhausted after each day.

• People first. I put the people in the center of my decisions.

• Special focus on learning. The best way to lead/manage is by providing the best learning support so people can grow and be autonomous.

• Engineer. I have an engineering background in software. That creates a huge impact on the way to think about my leadership/management style.

• Pragmatic. I don’t tend to build cathedrals, I’m more alike to build bazaars. See reference here.

• Not OK with babysitting. I want to work with people that are adult and responsible, I don’t want to be babysitting anyone, it’s not my job to do so. Therefore I need to be or create an environment that people feel empowered to do stuff and not waiting anyone to babysit them.

One last thing you need to know, I consider that:

• A manager does not need to be a leader.

• A leader needs to have great management skills.

• Management is a title

• Leadership isn’t a title

• Management is a role that can be given to you

• Being a leader is recognition of your peers

Elastic Leadership. Growing self-organizing teams

This is my 100% recommended book to any leader. If I had to use want sentence to summarise what the book says, it would be:

The leadership needs to be fluid and adaptative to what’s required in the moment and situation at hand, to help teams to grow to become self-organizing.

My goal as a leader is to achieve what this book says. The only problem is that requires a lot of experience and practice, and you need to be patient to see the outcomes.

The book identifies three stages of a team, product, or individual, and the leadership style that’s required for each situation:

• Survival mode (no time to learn) with a Comand and Control leadership style

• Learning mode (learning to solve your own problems) with a coaching leadership style

• Self-organization mode (facilitate, experiment) as a facilitator leadership style

So, as a leader, you need to identify in which situation you’re in, and then adapt yourself to the needs of the team, product, or individual.

Nonviolent Communication: A Language of Life

I would say the first book that really helped me to improve my communication. I didn’t appreciate it enough yet the person recommended it to me in the first place.

This book gives you a guide about how to communicate in a meaningful way, respecting each other needs in the way. It will show you the four components of NVC:

1. The concrete actions we observe that affect our well-being

2. How we feel in relation to what we observe

3. The needs, values, desires, etc. that create our feelings

4. The concrete actions we request in order to enrich our lives

How I’m communicating today is totally different partially thanks to this book. In does a strong focus on empathy as well, and how to be assertive.

By reading this book, you will also improve on conflict management. A key skill to have as a leader/manager.

The Making of a Manager: What to Do When Everyone Looks to You

This is the book I wished I had before starting my management journey.

When I was reading the book, I just had some thoughts like:

• “I did this mistake”

• “If I knew this before, I didn’t lose 3 months on something that simple”

• “Damn! that’s what I was looking for!”

If you’re in the early beginning of your manager journey, this book is the 101 masterclass.

The five dysfunctions of a team a leadership fable

As a manager or leader, you need to build a team, not a group of individuals. This is the book to build it.

I found in this book a super great way to understand why we don’t work well as a team, and how to build a team that works well together.

The book will tell you about:

• Trust

• Accountability

• Commitment

• Conflict

It Doesn't Have to Be Crazy at Work

Around 2019 I read this book, and it just shifted how I work. It just helped me to challenge the way I was working, which wasn’t healthy. I was working on startups since the beginning of my career, and I bought the “entrepreneurs dream” that meant do long hours to achieve your dreams.

Today, I just want to work efficiently, that’s why I stopped:

• Working more than 40h

• Corporate BS

• Wanting to change the world

• Do everything for the company

After this book, I just started balancing better my work-life balance, and it just how affects the people around me. I don’t expect to sacrifice for the company and neither I ask the people that are around me to do the same.

Today, I might not apply everything the book says, but back then it helped me to challenge the way I was thinking about work. Worth it.

The Open Organization: Igniting Passion and Performance

I would say that my leadership style has been heavy influenced by this book.

This book was written by the CEO (now chair of the board) of Red Hat, Jim Whitehurst. Red Hat is a company that provides Open Source Software at the enterprise level.

The leadership style to lead the company is super different from what I was familiar with. It helped me to add a new way of thinking about the organizations and how to lead them.

Even though you’re probably not doing OSS, I think the ideas behind this leadership style were in the cutting edge of leading organizations when the book was written. Today, they are becoming more common in the different companies, but still, we are far from getting there.

Empowered: Ordinary People, Extraordinary Products

🔔 I’m still reading it, but I would recommend it anyway.

So far, I feel like Empowered covers what’s needed to create a great team and product. It tells you what matters, and how the leadership takes a role in getting there.

It talks about a lot of stuff, not in-depth, but enough to help you get a sense of what matters so you can later get more informed about the topic if you feel you need to.

To me, this book has been a discovery.

Emotionary: Say what you feel

At 27, I wasn’t able to identify some emotions and some of them I even didn’t know existed even though I felt them. I just didn’t know that there was a name for that feeling. Yes, at my 27.

Being able to identify what you’re feeling is crucial for meaningful conversations and relationships. So, later, you can also empathize with other people's feelings.

Last recommendation: Therapy

I got to a conclusion, you can lead if you don’t understand yourself, your feelings, your emotions, your needs, and you are able to communicate them effectively. Difficult to be able to emphasize with others if you cannot emphasize with yourself.

None of the books were really that powerful as going to therapy.

To lead others, start understanding yourself.

I made a huuuuuge step ahead by being honest with myself and asking for help. Yes, it impacted my career, but the most impact has been in my life, regardless it’s career, family, partner, or self-being.

I’m better with myself by attending to my needs first (and knowing which are those needs, that’s super difficult), and then I can help others.

Today, I can say I’m leading from within without forgetting myself when I’m with others.

Still, I’m aware that being able to go to therapy is a privilege nowadays that not everyone can afford.

Find leaders you admire and ask for mentorship

I ask for a lot of advice and opinions from people I admire. They don’t actually need to be managers or leaders in my organization, they are friends, family, members of the community.

When I ask for mentorship, I allow myself to be vulnerable and admit that I don’t know everything.

It’s mind-blowing how much you can learn from others when you don’t need to look like you know everything. 🤯

Wrap-up

Long journey ahead! Be patient! and enjoy it! Yes, it has its ups and downs, but it’s OK to have them 😄

Just do not try to force the universe to go in the way you thought it would be. Just do your best, and accept the reality as it is.

Subscribe now

Meme for you