October will start differently from other months. I will no longer manage a team, but managing managers that manage teams.
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!
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
