Share A LEADER'S MINDSET

Independent of how busy and stressful you are, you still hold the last word regarding self-development.

And today, I'm going to show you some of my favourite Productivity tricks and how I expand each.

By improving your daily life, you'll eventually reach Nirvana, or at least to a place where you'll feel like you dominated your day and accomplished what you set out to.

But don't be fooled. This is not a linear or straightforward journey. It will require you to be true to yourself and keep fighting to deliver results consistently. At the end of the day, it will make you a better professional and a much stronger Engineering Manager.

Success isn't about getting more done; it's about having more fun. If you're having fun, productivity takes care of itself.

- Ali Abdaal -

This quote is of the utmost importance. This path we're travelling can't be exclusively filled with pain and sacrifice. You need to find joy in the journey because if you enjoy the little things, you will have the strength to withstand the inevitable pain that the road holds ahead.

Building your own productivity system allows you to become a more centred professional that holds a:

• Higher delivery rate

• Higher effectiveness

• An overall sense of accomplishment

So here are 3 main pillars that serve as the foundation of my productivity system.

1 - Calendar

Mastering your calendar is an art. Sometimes I feel like an artist. Most times, I feel like a starving artist 😝

There are 3 main items that I focus on with my calendar:

Time Blocking

Parkinson's Law states that the more time we have to complete a task, the longer it will take.

What I've learnt throughout the years is that if I block the time I want to devote to specific tasks, it will:

• Know exactly when I need to work on something

• Help me focus on what I need to achieve

• Limit the amount of time I have to accomplish that task.

Knowing when to do a task and how much time I have to do it is an excellent way of organising my day.

Colour Coding

One of the most simple but impactful changes I've made to my calendar was introducing colours to my events.

There are a couple of reasons why it was so effective:

1. It made my calendar look so pweeeeety

2. It helps me very quickly have an overview of how critical my day is.

Right now, I'm using the following colours:

• 🔵 Default colour

• 🟡 1:1s

• 🔴 Important Meetings

• 🟢 External Meetings

• 🟠 Leadership Forums

• ⚪️ Placeholder

I tend to change the colour scheme slightly every 6 months to keep me on my feet.

Daily Reorg

I go through my calendar daily and try to collapse meetings together. The last thing I want is a day filled with gaps and odd meetings that prevent me from concentrating on a single task.

I send messages to every organiser of the meetings I want to change and plead my case. More often than not, I manage to change the meetings and place them together.

Alongside time blocking and colour coding, it helps me build my day.

For example, I try every day to concentrate on my 1:1s until the beginning of the afternoon. In the same way, I devote time to tasks that require high focus in the morning.

Customising my daily calendar is an important part of my day that inevitably maximises my productivity.

2 - Focus

A critical part of my day is the ability to focus almost on command.

This is something that I developed with training, experimenting and finding what truly works for me.

Everyone is different, and I'm sure what works for me might not work for you.

Playlists

Many issues ago, I mentioned Binaural Beats and how they helped me focus.

To this day, I still find it interesting that those sounds lead to so much concentration.

As an alternative to Binaural Beats, I often listen to Hans Zimmer tracks. They also work for me, but not as effectively.

Meditation

After many years of fighting against meditation and struggling every time I tried it, I started doing it recurrently about 2 months ago.

I got to a point where it was becoming tough for me to centre and deal with many of the pressures from work.

It felt like I stopped caring for myself and was always in a constant state of anxiety.

So I turned to meditation as an attempt to recenter.

I'm still learning to meditate, but every time I finish a 10-minute session, I feel like my feet add weight to the ground, heavy, focused, and centred.

Right now, I'm doing a session every day in the morning. It's proven to be a game-changer.

LOTR+HP

My secret weapon is simple.

If I have a difficult task that needs me to go into the zone, 100% focus, there is only one answer: a Lord of the Rings and a Harry Potter marathon.

I lost count of how many times I saw these films, but I know that I don't need to look at the screen since I know the scenes by heart and can almost recite them.

I can't really explain why this works, but the fact of the matter is that it does.

I'm sure you'll have your own set of films, tv shows, albums, songs, etc, that simply bring the best out of you.

Don't simply cross them off the list because it's unconventional.

If it works for you, it works. Period.

3 - Journal

Finally, the piece of resistance.

I've tried morning journals, late-night journals, 5-minute journals, bullet journals, etc.

Right now, I can confess that I don't journal every single day. Still, some days, when I feel absolutely overwhelmed with information, I pick up a pen.

On those days, I sit down and write and write and write.

I've learnt about this method, that you just start writing what's on your mind and then, like water, you try to direct it to a certain location. This great exercise will leave you much lighter and with an interesting outcome in the paper.

I often correlate the chaos inside my mind with masses of water too strong to control. They move at their own pace, and I hold on and go on the ride.

This exercise helps me control that water mass.

Conclusion

These processes and experiments led me to a place where I got to know myself better and eventually helped me optimise my ways.

Going back to the quote from the beginning, this only work because I genuinely enjoy trying these systems, playing around with how I deal with problems and optimising my responses. The journey is the fun part of it.

If I were to describe everything that I do, occasionally try, and above all fail, the list would be massive and would contain:

• Cold showers

• 5 AM wake up

• Fasting

• Achievement Lists

• PARA System

• …

The more I think of productivity, mainly how I apply it to my day-to-day, is very connected with my mental health and how I try to improve it. Tackling my daily problems gives me a sense of control, making me sleep better and increasing my overall sense of daily joy.

These are some of the techniques that I use.

I would love to hear about what you're doing to improve your daily lives.

Feel free to reach me on LinkedIn, Twitter or Email.

Here are a couple of other topics you might be interested in:

• Becoming an Influential Engineering Manager

• Key questions to ask in your 1:1 session

• Essential Reading for Engineering Managers

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

Share A LEADER'S MINDSET

Changing jobs as an Engineering Manager can be a scary thing.

It's not bad; it's just scary.

But investing your energy in evolving specific areas makes this apparently scary situation manageable and thriving.

Impress in key areas instead of being average in all.

You must go from an unknown to someone on the radar within a year. 

And you have 365 days of opportunities to show up and showcase your skills.

To unlock this massive opportunity, you need to visualise possible areas to invest your efforts and energy:

• Company Culture: Are you living the values?

• Relationships: Who do you relate with?

• Company Ecosystem: How to get things done.

• Reputation: Who other people see.

These four areas are primarily net positive regarding effort invested and the return you'll get from it.

Let's double-click on each.

Are you living the values of your company?

Every company has a culture.

They might not put it into words or values, but the company culture exists. It's there.

And often, it's different from what CEOs and other leaders want you to think it is.

Everyday actions speak louder than written and marketable values.

You'll see glimpses of it in the harshest of times, where teams rally to help one another or how by providing candid feedback, teams inevitably grow and outperform themselves. You'll hear whispers in the halls and a lack of governance in everyday practices.

This is all part of the culture.

And throughout your first year, one of two things will happen: you'll either fit in or go into a massive culture clash.

What actions can you take?

• Outline the visible and invisible company values.

• Assess if you're compatible with all of them.

• Understand how you can double down on each of the values you identified.

• Execute weekly and assess how you showcased the values.

What's your circle of influence?

Let's not kid ourselves; we reflect the 5 people we spend the most time with.

For some, that's a fantastic insight, whereas others are getting rightfully scared now.

Within the corporate space, this is also true and important.

Having great connections allows you to see further in the company strategy, giving you extra leverage when it comes to decision-making.

But time goes by, and as you climb the corporate ladder, always remember the people who helped you along the way. You may pass them quickly on the way up, but trust me, you'll pass them much faster on the way down.

Always remember to be kind.

What actions can you take?

• Identify key people in the company and around your scope.

• Drop them a message to understand their availability for a 1:1 session.

• Pay closer attention to those meetings with lots of people. Who's talking and why?

• Shut up and listen. Learn and take notes.

How to go from A to Z

Every single company has its quirks.

And navigating the intricacies of your company is a special form of art.

I know so many people who spend years at a company but still don't know what makes it tick.

I found "getting to know the insides of the company" to be trickier to master during the pandemic.

I remember going on long walks during the onboarding phase, introducing new leads to everyone and explaining who's who and who they needed to talk to depending on the situation.

What actions can you take?

• Start creating a simple database of who's who and what they do.

• Draw out a golden path for specific tasks you need and tie each part to a specific person.

• Keep refreshing that list to stay consistent with people who have left the company.

• Make sure you maintain a relationship with these key people (even if slim)

What do people say about you?

Whether you want it or not, your reputation speaks for itself.

And similar to the company culture, you too have a reputation.

It's up to you to manage it, not through wishful thinking but through daily actions.

Everyone has the right to make mistakes, but making them recurrently will get you a nasty reputation.

I find reputation to be one of the most essential parts of my job.

What actions can you take?

• Lead by example: If you want a team to display a certain trait, you must be the first to display that trait.

• Stop being a know-it-all: You have a team of highly knowledgeable individuals. Don't try to solve everything on your own. Rely on your team.

• Keep learning: The world keeps turning. Keep an open mind and ensure you're up to date with technologies.

• Kindness: It's easy to be a grumpy lead. It's even easier to create siloes. Don't follow the easy path.

Always remember that this is a more than one size fits all solution.

There's nothing as a silver bullet.

Consistency and pristine goal-setting is going to be the key.

What else would you add?

See you next week!

Here are a couple of other topics you might be interested in:

• Brag Documents

• Y-Career Path

• Metrics to Track

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

Share A LEADER'S MINDSET

Conflict is a part of life, and it's especially common in the workplace.

I'm sure this isn't a big surprise for you.

You're spending most of your time dealing with conflict.

But you can look at this from two different perspectives.

Either consider conflict dark and destructive, or you believe it to be natural and an opportunity to grow and learn.

I prefer the latter.

Let me highlight that throughout your journey, you'll see many Engineering Managers display destructive behaviours that go from ignoring the conflict completely to fuelling the fire and making everything worse.

So today, I decided to share 4 strategies to help you deal with those everyday conflicts.

But before we talk about those strategies, let me tell you that your team is clashing due to a lot of:

• unclear communication

• unclear performance standards

• unreasonable time constraints

• unclear expectations

All of these are within your control to prevent.

But today, we'll focus on 4 strategies to resolve the already existing conflict.

Let's dive right in.

Acknowledge the other person's feelings.

You don't have to agree with everything the other person is saying.

You should, however, be able to acknowledge what the other person is feeling.

Validating someone's emotions goes a long way when dealing with conflict, as everyone feels validated.

Four ways that you can validate someone's emotions are:

1. "Thank you for sharing this with me."

2. "I see that this is important to you."

3. "I can see how upset this makes you feel."

4. "I'm sorry that this happened to you."

Acknowledging the other person's feelings will allow the other person to be heard, encouraging honesty and safety in the relationship.

Focus on the problem and not on the person.

It's so easy to get lost in the middle of a conflict.

You'll often feel compelled to focus on the people involved, the different personalities and histories.

But here's another way.

Focus on why the issue started and not the people in the middle of the conflict.

Try to get to the bottom of the issue, not by judging but by asking how we got to this point.

Understanding the root cause will be the key to untangling the conflict.

Be willing to compromise.

No one will get everything they want out of a conflict.

One of the most important things you can do is understand where halfway is and meet the other person there.

Compromise is a heavy word, but adapting and changing your ways will bring you more rewards than sorrows.

Look at it positively and see how this new approach will bring you unique rewards.

Seek help if necessary.

Don't be proud.

Be humble and honest to admit when you can't fix the issue.

Ask for help in those situations.

A neutral third party can be the key to unlocking specific discussions.

Someone who doesn't come into the situation with bias or interest in the outcome.

Summary

Conflict is part of life, and you, as an Engineering Manager, must deal with it daily.

Sometimes you'll be acting as a mediator. Others, you'll be right in the middle of the conflict.

Remember that, above all, you should:

• Stay calm and objective

• Listen to both sides of the story

• Create a safe space for discussion

• Be willing to compromise

• Follow up after the conflict has been resolved

See you next week!

Here are a couple of other topics you might be interested in:

• Brag Documents

• Y-Career Path

• Metrics to Track

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

Share A LEADER'S MINDSET

I've said it once! Heck, I've said it a million times!

Part of our role as Engineering Managers should be to continue learning new skills and decision-making frameworks.

By learning other ways of solving similar problems, you'll increase your decision-making matrix and create custom and often innovative solutions that fit your team and their issues.

So today, I will show you 4 books that every Engineering Manager should read to improve their craft and skillset.

Remember, the issues you're currently struggling with have your specificities, but in most cases, other leaders have analysed and dissected the underlying problem.

It's up to you to make sure you go the extra mile after these answers.

Here are 4 books you should read at least once in your career.

And with summer approaching nothing better than starting to create your reading list.

The Coaching Habit

Michael Stanier

I read The Coaching Habit last year, and it resonated so much with me that it just went up the ranks.

Stanier writes this book with a thought in mind:

• Stop answering the questions you ask. 

• Stop giving advice when it's not requested. 

• Create the space for the person to come up with their answer and guide them through their thought process.

As a leader, this book is a must-read. It will give you the foundations for every coaching and mentoring session and help you redefine how you assemble and conduct your one-on-one sessions.

One thing I enjoyed in the book was when Stanier dives into Neuroscience with the TERA model. 

The idea is that our brain continuously scans its surrounding environment to make sure it's in a safe condition.

The TERA model allows you to reassess your work relations and, in many cases, understand why stressful relationships exist.

Radical Candor

Kim Scott

Radical Candor is a key book for every manager and individual contributor out there.

Throughout the book, you'll understand the importance of feedback and how to provide good feedback independent of the content.

As a leader, it's crucial for me that I and my teams can provide good, actionable feedback to each other. Only by doing this do we build better teams with even better professionals.

This book is great for everyone to understand that they're not perfect. You might be the best at what you do technically, but if you show no empathy and are plain rude in your interactions, you will only diminish the impact that you can make.

Start With Why

Simon Sinek

"Start with Why" is one of those books that, if you haven't read, you need to stop what you're doing and go read it.

The idea is quite simple:

Great brands and great ideas don't start with the what or the how. They start with why.

Only by diving deep into the why, to the visceral reasoning behind why you should do something or why that product will be life-changing, do you reach the idea's full potential.

From a leader's perspective, sitting down with your team and brainstorming on the way of your team, of your product will create connections that will act as the foundations of your team's culture.

Show Your Work

Austin Kleon

This book has weirdly become one of the most influential books in my adult life.

In "Show Your Work", Kleon makes a case for why you should build in public and share your journey.

Nothing is more powerful than a story, and sharing your story as you build is, at the end of the line, priceless.

We no longer live in a world that confines us to our streets, city, and country. We live in a connected world where you will find people that love the same things you do and that want to talk about the same things you do.

So share your journey, your successes, and your failures. Open yourself to the possibility of a connected tribe and where you'll grow as part of the community.

Something that resonated with me was the idea that if you share your journey and build a community, you'll get to a point where when you apply for a job, your community and your journey speak louder than any CV.

To me, as a leader, being able to put myself out there is key, and it's something I always advise. 

Summary

Every Engineering Manager needs to continue to learn and grow. 

And going through an influential list of books is a great way to add to your toolbelt of frameworks, processes and experiences.

Here are 4 of the books I consider extremely valuable for any Engineering Manager to read:

• The Coaching Habit by Michael Stanier

• Radical Candor by Kim Scott

• Start With Why by Simon Sinek

• Show Your Work by Austin Kleon

Now, between you and me, here are a couple of more interesting books (some of them iconic) that could or should have made the list:

• The Manager's Path by Camille Fournier

• Engineering Management for the Rest of Us by Sarah Drasden

• Atomic Habits by James Clear

• Building a Second Brain by Tiago Forte

What else would you add? 

See you next week!

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

Week in and week out, I share different ways for you to become a better Engineering Manager.

Today, I highlight some behaviours that lead to one simple outcome: managers losing their teams.

Before we dive into this list, a word of warning.

Every one of us will identify with what is written below.

This doesn't mean we're bad managers, only that we have room for improvement.

So yes, here comes the buzzword: It's time for a big dose of Growth Mindset!

Face this list with an open mind, thinking about your reality and trying to identify where you need to improve.

Let's go!

Vision

Every manager wants to work with a high-performing, motivated and engaged team.

But as their team fails to deliver, the first reaction of managers is often to blame the team:

• Didn't raise every edge case

• Estimations failed

• They were slacking

Even if you haven't verbalized it, this has crossed your mind. 

I challenge you to dig deeper and find if there is something deeper that is affecting how motivated and aligned with the end goal your team is.

Often, the team is not aware of their mission or vision.

Ask yourself, do they really know why they're there?

More often than not, teams roam directionless, focusing on toil and BAU (business-as-usual) tasks.

It's up to you to make a change, motivate and share the vision with the team:

1. Clearly define your vision. You're the first one that needs a clear perspective.

2. Work with the team to find your common vision.

3. Set clear, SMART goals aligned with what you want to achieve.

4. Define how each team member contributes to achieving that vision.

You'll end up with a team that knows what they're trying to achieve. That's step number one to a high-performing team.

Information

One of the worst things a manager can do is not have the right sense of timing when sharing information and pressure with their team.

You have two possible ways of mishandling this:

You hold all the information and share nothing with the team:

1. All the pressure is on you

2. The team won't feel like you trust them

3. The team won't understand the reasoning behind certain decisions

You share every piece of information as it arrives with the team:

1. The team is in a constant state of stress

2. They can't understand the priorities

3. They won't trust you because you keep drowning them in information and problems.

As a manager, you'll get a lot of information and requests. You need to mentally assess what the teams need and how fast they need it. Use something like the Eisenhower Matrix for it:

• Critical and Time Sensitive? Create a call and share now. It’s a top priority; stop everything you’re doing type of thing. This is to be used very rarely!

• Critical but not Time Sensitive? Wait for tomorrow's daily or the next iteration.

• Not Critical but Time Sensitive? If the date permits, wait for the next iteration. If the date doesn't permit, send them a message now.

• Not Critical and Not Time Sensitive? Go to the backlog of things to discuss with the team.

Find your balance.

Practising transparency is important, but it’s all about timing. Don’t drown your team with requests, still-developing information, etc. Before sharing, always consider the consequences.

Growth

A team is not static.

It's an evolving ecosystem with some members thriving and others struggling, and it's your job as a manager to find the right balance and ensure that everyone evolves and grows.

You'll find a lot of Personal Development Plans in large tech companies. In small and medium companies, you'll see… none.

I find developers going into these companies and:

1. Not having any learning plan

2. Forced to work every day with legacy tech

3. No light at the end of the tunnel: there's no interest in evolving.

These are people that are going to leave the company as the first opportunity arises.

Managers are responsible for ensuring that their team is allowed to develop and improve.

You might hear someone say that as developers get more certifications and training, the more likely it is for recruiters to come for them. But look at the other way, do you only want to keep the average developers?

There are a lot of vectors that will keep your team working with you, not just one.

So make sure your team is on track:

1. Review/Create their training plan

2. Provide clear guidance on their career track

3. Create a culture of learning and development

Summary

If you want a different perspective on how you can improve as a manager before adding more new frameworks, or ways of doing things, start by reviewing what is happening right now.

1. Clear Vision and Goals

2. Correct Levels of Information

3. Path to Grow and Evolve

These are three items that are important for you to revisit, but there are many more. The trick, as always, is to identify and understand why the behaviour is happening and then slowly but surely adjust your ways.

These ideas will be an important step to achieving a high-performing team when executed perfectly.

See you next week!

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

The transition between being a developer and an Engineering Manager is complex and takes work.

You’re going to face a new set of realities, handed a series of uncomfortable scenarios and sooner or later, you’re going to have some pretty tricky conversations.

Today I’m going to show you the skills that you should develop if you want to embark on this journey of Engineering Management.

By mastering these skills, you’ll be more equipped to handle the ups and downs of leading a team and dealing with deadlines and stakeholders.

I’ve witnessed a lot of unequipped managers that, down the line, lead to dysfunctional teams, unhappy individuals and projects that never really gain any speed.

Growth Mindset

The ability and willingness to continue to learn. The conscious reflection that you don’t hold all the knowledge in the universe.

Like when you are a developer learning new languages, new patterns, and avoiding anti-patterns), when you become an Engineering Manager, you must keep acquiring new skills and polishing existing ones.

To me, this willingness to learn and fail should be a significant feature of everyone moving from developer to manager.

The idea behind modern leadership is that Engineering Managers work alongside teams to help them deliver as much as possible, not by way of the whip but by collaboration.

And for this to work, you must be able and willing to learn, fail, evolve and try new things.

If you want to dive deeper into Growth Mindset, I wrote about it a few weeks ago.

Active Listening

When you’re in a conversation, it’s easy to tell when the other person has stopped listening to you and is just waiting their turn to speak.

Their eyes gaze, they become impatient, restless and, more often than not, they start nodding their head to pretend they’re listening.

By writing this, I can clearly picture a couple of people nodding. Can’t you?

To me, this always leads to a sense of dismissal and frustration. I knew I wasn’t being heard, and we were just going through the motions.

If you really want to dive deep into Engineering Management, one of the best skills you can work on is listening and genuinely making someone feel heard.

This leads to a deeper bond with your team and, more often than not, long-lasting connections.

Like so many other skills, listening can also be trained and improved. If you want to know more about it, I devoted this issue to Active Listening a couple of weeks ago.

Communication

You control the words you write and speak. You don’t control how they will be read or listened to.

Different teams from a series of companies and industries share the same feedback. More often than not, the communication practised at their company was not good.

A successful Engineering Manager can receive information, digest it, filter what needs filtering, and pass it along concisely and in a way that fits their team.

Language, emojis, gestures, and humour (or lack thereof) can be used to adapt a message to your team. Make it your own without losing the underlying significance.

We all know how poor communication can lead to tragic results. Sometimes you annoy people, or sometimes you even have people leaving. This is how the company of a friend of mine destroyed any chance their Agile Coaches had of making a difference just by lousy communication.

And this leads me to emotions.

Emotions

To finish, I want to discuss how important it is to leave emotion at the door.

Before you notice, you’ll be placed in the middle of a discussion and asked to take sides. Or you’ll need to deal with someone that takes a technical debate personally. Or be asked to decide who gets a salary bump. Or who to cut due to budgeting.

It would be best to distinguish emotion from care or empathy. Both can be done while following an important data-based approach.

Many managers build their decisions on just empirical data. That eventually leads to teams not clearly understanding why a particular decision was taken.

Be smart and cement your decision using precise data. It will position you as a fair leader who listens to reason more than just what’s hot or trendy.

I’ve written about what it takes to get promoted, how to check if your team is truly happy, how developers should write brag documents to help with their performance reviews and key metrics every Engineering Manager should read. I hope it helps.

In Summary

These 4 skills might be easy to understand and often common sense. What’s unusual is the number of managers that don’t use them or even have them on their radar.

Often I write the “How I became a better leader today” entry in my journal. It helps me reflect on what I did well and, more importantly, where to improve. This would also help you to improve your skills.

Remember, it’s only up to you to make a difference and become a better leader.

See you next week!

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

The first 1:1 with someone you have never met is always challenging. And to be honest, it gets awkward very fast.

You're face to face with a perfect stranger. But this stranger already has a pre-constructed idea of how your relationship will go, high expectations from you and how you can impact their career.

Initially, there is little connection and no trust—only the hope of a bright future.

This week I want to help you in this journey with 5 of the most impactful questions you can ask in your first 1:1. Your long-lasting connection begins here.

Let's start.

What type of work motivates you?

How great would it be if everyone in your team would be highly motivated?

Someone with a strong sense of belonging, truly happy about their work and with a tremendous drive.

And remember that this level of engagement is contagious!

So take this opportunity to understand how to guide your team to high motivation levels.

Remember that you can show them the way, but they must go through the path.

What would you change about the team, process, and projects?

If you're arriving to an existing team, accept that a lot of history will influence the course of your next weeks and months.

This first 1:1 moment is decisive in your career as that team's Engineering Manager.

Use it to learn where each team member stands regarding the state of the team, how the team works and the projects it is doing.

Remind yourself often to take this information with a grain of salt and as data that will help you understand the team's state.

How do you prefer your feedback?

Feedback can be a tricky thing.

You might read some books that you should give feedback fast. Or that you should praise in public.

You'll quickly notice that you'll have some unpleasant surprises if you follow these two practices.

Different people react differently to the same strategies.

Ask them how they want to receive their feedback so you adjust your practices.

Remember, you will have different strategies depending on who you're talking to.

What do you expect from me?

Missed expectations destroy most relationships.

Being this day one of your new relationships, start on the right foot.

Ask them clearly what they expect from you.

Remember a vital thing: As their manager, one of your responsibilities is to help them grow.

Understand clearly how you can help them.

How often do you want to meet?

A meaningful question is hidden behind a simple and innocent format.

This is where you will understand the amount of space this person needs and how many check-ins you need to do.

This is where you go from a manager respecting a person's boundaries to a micro-manager or ghost manager.

Listen to them, and always remember that different people have different requirements.

Be flexible.

In Summary

This is it. An unrepeatable moment where first impressions matter.

The first connection you make with a new team member.

Remember to ask these impactful questions.

1. What type of work motivates you?

2. How do you prefer your feedback?

3. What would you change about the team, process, and projects?

4. What do you expect from me?

5. How often do you want to meet?

Oh, and an important thing! Take notes!!!

How? That is for another issue 🙂

See you next week!

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

If there's one thing we've all heard, it's that "Data is King." But, as Engineering Managers, how can we truly harness this power to guide our teams? How do we transform data into action to make the right decisions at the right time?

Today, I'm going to share four critical data points that every Engineering Manager should track to drive their team's performance.

Using these data points to guide your decisions will make you a beacon for your team. They'll know that the path you're showing them lies on a firm foundation of factual data. 

So, let's turn on our analytical minds and dive in.

Attrition Rate

How many people leave under your watch?

The attrition rate—the number of people leaving your team—is critical. High attrition could indicate issues like insufficient promotions, low salary adjustments, or unpopular changes in direction. Addressing these issues right away can increase your team's stability and satisfaction.

Consider a scenario where your attrition rate spikes following a restructuring within the team. This might indicate that the changes have unsettled your team members, necessitating clear communication and reassurances about their roles.

Lead & Cycle Time

If you've never invested in understanding your lead and cycle time, the time is now.

• The Cycle Time is how long your team spends working on an item.

• The Lead Time is broader, measuring how long it takes since a customer requests a feature until that feature is delivered.

Both give you a great understanding of how painful your customer's interactions are with your team and a lot of information about possible optimisation.

For example, if your lead time is disproportionately high compared to your cycle time, it may indicate inefficiencies in how you prioritise work or how the team handles customer requests. 

Addressing these areas could significantly improve your service quality and customer satisfaction.

Happiness Levels

Team morale is a crucial yet often overlooked aspect of team performance. I learnt that asking simple and anonymous questions effectively and effortlessly gave me the necessary data.

At the end of each retrospective, add a little anonymous survey:

How did you feel about this sprint?

😁 Happy | 😐 OK | 🤬Sad / Grrr

The goldmine is not one or two surveys but the data that consistency brings along the several months. I've only truly understood what I had after nine months of data.

For instance, consistently low happiness levels could suggest a stressful work environment, leading you to implement measures to address work-life balance or internal communication.

Give it a try, and let me know how it feels.

CFR & MTTR

Incidents are inevitable in every team, but understanding their frequency (CFR) and your team's recovery time (MTTR) can inform process improvements and enhance resilience.

For example, a high CFR might point to issues in your testing or deployment processes, while a long MTTR could suggest a need for better incident response strategies.

By understanding and leveraging these four metrics, Engineering Managers can make more informed decisions and lead their teams to higher performance levels.

Start tracking these data points, and let me know about the transformations you observe in your team dynamics and results.

TL;DR

• Attrition Rate: How many people leave under your watch.

• Lead & Cycle Time: How long it takes for you to deliver features.

• Happiness Levels: How happy your team truly is.

• CFR & MTTR: Incidents happen. It's all about how you react.

That’s it for today.

See you all next week!

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

Today, I’m going to show you how to leverage the power of retrospectives.

Every sprint, your team goes through a series of events that will bring them joy, frustration, pain, and happiness. Sometimes these feeling surface almost at the same time. It can be a proper mess.

By learning how to connect with your team and get them to share their experiences with one another, you’ll start creating a bond much stronger than any cool team name, cool product or hip t-shirt.

The problem is that most Engineering Managers are focused on just the velocity of the team, the number of tasks closed or the number of merge requests reviewed rather than slowing down now and building a solid and unified team.

Most managers are focused on the optics rather than on the foundations of the team.

No fluff today.

Let’s focus on exactly what we, as Leaders, should do to host a productive and meaningful retrospective session. This is a session that:

• Promoted communication

• Tackled real issues of the team

• Produced actionable items

Here’s your action plan for your next retrospective. Let’s dive in.

Create a Safe Environment

One of the most important, if not the most important, characteristic of a retrospective is that it needs to be a safe environment for everyone in the room (virtual or physical).

Team members must be absolutely certain that they can share their thoughts, ideas, and concerns without fearing retribution or judgement.

This is the key that will unlock all the benefits of a retrospective.

Blameless Culture

Contrary to what many people believe, a retrospective is not a finger-pointing exercise.

Even though you can put your team members in the spotlight, take this opportunity to work towards improvement in a blameless manner.

For that, the concept behind a Blameless Culture is to focus on the process, not on who did what.

Did a merge review take too long to merge? Instead of asking why Rick didn’t pick that MR immediately, create a process to ensure that MRs can’t be unreviewed for over two days.

Focus on the process. Not on Rick, who was dealing with a bug in production.

Keep Track of Time

It’s very easy to lose track of time during retrospectives.

As the maestro of today’s retrospective, you should always know how long you have at every section of the retrospective.

And remember that you’ll eventually have to decide whether to continue on the topic or move along to the next one.

The trick here is to be transparent about the available time slots with everyone.

Focus in Actions

I see too many teams focus on the discussion and not much on what to do next.

For every item you discuss, make sure you have at least one action and one person accountable for its execution.

You should start every retrospective by reviewing the state of past actions and conclude it by listing every new activity.

Experiment with Different Formats and Visuals

This isn’t a one-size fits all.

Experiment with different retrospective formats. You have so many!

You can try the racing car, the speed boat, the 3 Ls, the Three Little Pigs, the Rock n Roll, etc.

You can even create your own!

Make this a pleasurable experience for your team, that know that any issue raised during the spring will be addressed during the retrospective.

TL;DR

Create a Safe Environment: Promote healthy discussions without fear.

Blameless Culture: This is not a finger-pointing exercise.

Keep Track of Time: Timeblock your retrospective.

Focus on Actions: Make sure you always have actions and people accountable.

Experiment with Different Formats and Visuals: There isn’t a silver bullet.

That’s it for today.

See you all next week!

If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!

If you enjoy the newsletter, the best compliment you can make is to share it with one person.

Share

Have an incredible week! 💪🏼

Parada 👊🏼 ​A Leader's Mindset

Twitter | LinkedIn

This week, I want to talk about modernizing our view of Agile.

Agile revolutionised how we work, but sometimes we forget that the Agile Manifesto was created over 20 years ago.

However, looking at the current state of Agile in the tech industry, you still have companies in all stages of adoption, from iterative and incremental development to managing distributed Agile teams.

COVID motivated a lot of new ways of working and forced us to revisit some of the practices we were using to improve our performance and delivery.

I want to challenge you to revisit how you work and if there are any areas in which you can try a new approach.

Daily Standups

Every morning, you get to see the whole company get together in teams, squads, etc, to address:

• What they did yesterday

• What they’re going to do today

• If they have any blockers.

The concept of asynchronous work introduced an almost meeting-free schedule.

Why should daily standups be any different?

Moving to a complete async working mode is a shock to every team, so why not leverage your existing communication tools (Slack, Teams, etc) to try this technique once or twice a week?

2-Week Sprints

Every year you have 26 iterations of improvement.

Twenty-six times a year, you deliver a new product iteration with new features.

But what if we were to change the approach, and instead of focusing on what fits into a sprint, we would focus on limiting the work in progress?

Stop Starting and Start Finishing

In a Kanban mode, you focus on limiting the Work in Progress, and instead of using the two-week cadence to deliver features, you deliver them as they become ready.

Kanban is about flexibility and about adjusting to change.

If you’ve been continuously working with Scrum and want to try something new, start small and think about your process and how it would change with this continuous delivery flow.

Sprint Planning

With the Kanban approach in mind, you might start to wonder how developers will know what they need to do at a given moment.

It all comes down to good prioritization.

Be clear and open about the policies you use to prioritize your backlog and the amount of work in progress it’s acceptable to have in progress.

This approach brings a series of advantages:

1. Consistent and transparent decisions

2. Teams are more independent

3. Reduced backlog maintenance

If you want to start with this technique, make sure you have a prioritized backlog and let your team plan the next sprint based on it.

Weekly Refinements

Have you ever felt going into a meeting or a refinement that what you’re truly doing is arranging a dedicated time to think about the topic?

There are other ways.

An async documentation-based approach and a clear definition of ready are great ways to ensure that your team has all the necessary tools to define their tasks and initiatives clearly.

Consider how many refinements you spent clearing miscommunications and misunderstandings about projects and tasks.

By prioritizing a documentation-first approach, you have all the information well documented, making the decision-making process more informed and quicker.

Revisit how you’re starting the next initiative and ask yourself if your team's level of documentation and understanding of the project is enough.

Retrospectives

Everyone that knows me knows that I’m a big fan of retrospectives.

I genuinely believe that alongside 1:1s, they’re one of the best methods an Engineering Manager has to bring a team together.

One method to adjust retrospectives is moving them from their typical 2-week cycle into an event cycle: when a project ends, when there’s an incident, etc.

Even if you don’t stop retrospectives every couple of weeks, I suggest you add a new one related to events.

This is something that so many teams forget, and the value it brings is gigantic.

In summary, modernizing Agile for new engineering managers means adapting to the current remote and asynchronous work environment, trying new methodologies such as Kanban, focusing on clear prioritization and documentation, and rethinking the timing and context of retrospectives.

By being open to these changes and taking advantage of the latest trends, you can keep your team agile and continuously improve your team's performance in an ever-changing tech landscape.

I suggest always trying some of these new techniques and reviewing their effect on developer happiness, quality of delivery and how the team functions.

At the time, his team could complete around 80 points every sprint. The obvious thought that popped into my head was: two-week sprints, 40 hours per week, 1 point per hour.

The moment I made this correlation, it was like I had unleashed the spawn of the devil himself.

Note to self, if you’re talking to a developer currently working in the story point system, do not, I repeat, DO NOT, try to make any correlation between those points and hours.

This might sound a bit confusing for those with no idea what I’m talking about, so let’s try to break down the idea behind story points and relative estimation techniques.

Back in the early 2000s, several Agile methodologies appeared as a way to save us from the dreadful Waterfall.

For the dinosaurs amongst us that still recall those Waterfall projects, I’m sure you remember those long strenuous stages that the project would have to go through without any feedback or the uncertainty of if what we delivered to the client was still what they wanted.

Agile came and changed this. We started having quicker turnarounds and quicker testing loops where feedback was constant. With Agile came flexibility and the guarantee that no single developer is the same as another.

If you were to estimate purely in hours, you would either need to overestimate every task, or you would have to know beforehand who would do the task because a Senior Developer will take a different amount of time than a Junior Developer.

The idea behind relative estimation techniques is to dissipate these differences and allow for shared knowledge and shared task estimation.

Let’s look into four different relative estimation techniques, and then I’ll explain how we use these four techniques in conjunction.

Relative Estimation

T-Shirt Sizing

Starting with the most simple one, the idea behind T-Shirt sizing is to assign larger blocks of work (projects or initiatives) to Small, Medium or Large.

To make this work, the first step is to be very clear about what each t-shirt size relates to.

For example, you can have the following correlation between t-shirt sizing and sprints:

• S - less than one sprint

• M - less than a month

• L - less than three months

Or, instead of using time as the metric, you can base your t-shirt sizing on past tasks:

• S - add observability metrics to a service

• M - create a brand new API

• L - upgrade and propagate a new version of Kubernetes

Adapt T-Shirt Sizing to your reality by adding sizes like XS (Extra-Small) or XL (Extra-Large).

This method is an excellent way of removing the fear bias of attaching a timeframe to an initiative.

Affinity Estimation

Moving to a collaborative approach, you can do affinity estimation by grouping tasks of similar complexity or effort.

The best way to do this is to create a card for every initiative (physical or virtual), and each team member moves the cards around, grouping together those that should take a similar effort or be of the same complexity.

You do this several times until the whole group reaches a consensus.

One of the most significant advantages of this method is that everyone should have a deep understanding of those initiatives.

Planning Poker

It’s irrelevant if you’ve led teams for one month or ten years. I’m sure you already witnessed estimating sessions where you hear some voices more than others. This process should not be biased and instead promote collaboration.

A relaxed, fun way of promoting a healthy estimating experience, you can have your team play Planning Poker using cards (or apps). Each individual shares their estimate and then proceeds to a discussion. In my past experiences, you would accept the majority result if the difference was just one level to speed up the process.

Anything above that, you would stop and discuss the reasoning behind the estimation and reach a consensus.

Story Points

And then, we reach Story Points, probably the most used relative estimation technique by modern Engineering teams.

One of the main advantages of this method, as it moves away from an hour-based estimate, is that it considers the effort, the complexity and the unknown behind each task.

• Effort - The amount of work that this task requires.

• Complexity - How difficult the task is.

• Unknowns - How unclear the task is or how many risks it carries.

Usually, teams use the Fibonacci sequence as a standard scale for story points. But why Fibonacci? A couple of reasons:

• Growing intervals - As the Fibonacci sequence grows, the more significant the separation between the numbers is. The larger the estimate, the lower the accuracy of this estimation.

• Simplicity - It’s a straightforward method to use and understand.

• Relative - The nature of the Fibonacci is that each number is the correlation between the ones that precede it. This way, there is a relation between each value and in a way, a similar relationship exists between tasks.

And one of the exciting things about story points is that each team has their own way of estimating, assigning a value to a specific task based on previous tasks, previous experiences, the stability and the seniority and familiarity of the team.

How to use multiple relative estimation techniques?

So now you might wonder how to use these techniques in the real world:

• Start by using T-Shirt Sizing to estimate your initiatives. This will give you a lower granularity but will help you have a ballpark figure of the complexity and effort of your initiative.

• Along with T-Shirt Sizing, use Affinity Estimating to have a clearer idea of your future initiative backlog. This will be useful when you're creating a first draft of your roadmap.

• For the stories and tasks that deliver your initiatives, use Story Points and Planning Poker to align the estimates for your tasks. You can then use reports like Sprint Velocity Charts to understand your team's performance.

How about your team? What do you use? Hours? Story points? Drop me a message on Twitter!

I’ll see you next week 🫡

Year-end Performance Reviews are complete, outcomes are shared, and everyone is set for the remainder of the year.

You can see different levels of excitement, from those who are pumped to take on the challenges all the way to those disappointed by the outcomes of this performance review. Congrats if you were just promoted!! 🚀

But today, I want to focus on a small (hopefully) subset of people trying their best to fit into their career path. Sometimes they’re trying so hard to make a cat bark like a dog that they are in a constant state of high levels of stress and anxiety and with their impostor syndrome going through the roof.

I’m talking about those who decided to go into the Management track and are either hating every second of it or missing the Technical track to the point they’re considering moving jobs.

First, let me say to you that is time to stop and rethink a lot about your career, your overall happiness and, in some cases, even where you work.

I’d love to say that long are the days when career path and progression would only go in a single direction.

In companies that exercise this career path, the only possibility you have to progress from the Senior position is to move into a Management position.

In these companies, moving to the Manager position is a promotion and a point of no return.

If you work in a company with a singular career path, where your future is decided by the willingness to embrace a career in Management, I want to share that there are other realities out there.

A company that exercises a dual career path, also known as the Y-Career Path, is a company that understands that we’re not all the same and that evolution is not only necessary in the Management track but also in the Technical track.

The Y career path is an effective way of maintaining a healthy, happy and engaged workforce as long as you follow specific rules:

• Make the process transparent

• Ensure that the salary bands are similar

• Don’t force anyone down a specific path

• Allow horizontal moves

Let’s break them down:

Make the process transparent.

One of the most important steps to generalising a career path is to document and be transparent about it.

The more information you share, the better you manage expectations.

This clarifies everything and answers one of the most-heard questions from Senior Engineers: “Where do I go from here?”.

Ensure the salary bands are similar.

Without going into a full-blown discussion if salary bands should be public, I want to stress that the best way to incentivize the best people to be in the best roles is to ensure that you’re not creating unbalanced salary bands.

Equal levels in the paths should have similar salary bands.

Meritocracy remains critical, but the possibilities are the same. Don’t punish someone for going the Technical path and vice-versa.

Don’t force anyone down a specific path.

I can’t even begin to explain how important this is. You see this problem recurrently in Management positions.

A team needs a manager, so the most obvious solution is to place the team's senior ahead of it. The most common outcome from this strategy is a team with absolutely no leadership and many problems between them and their manager.

Allow horizontal moves.

At the end of the day, you’re going to have managers who realise that the Management Career Path is not for them. And you’re going to have incredible Seniors that are terrible Managers.

The longer you keep these managers in front of teams, the deeper the hole you’re digging is.

Ensure you allow movements from the Technical Path to the Management Path and from the Management Path to the Technical Path.

Twitter and Meta’s restructure recently highlighted this Y-Career Path, where both flattened their org structure, removing layers of middle management and asking Managers to go back into the IC career.

In Meta’s case, according to Bloomberg, roles as high as Directors were asked to move to IC or leave the company. The higher you move in the Y-Path, the harder it is to transition from one path to another.

While not everyone will be able to transition, having the possibility of horizontal movements gives you a sense of freedom and power of choice unparalleled to the single career path that felt restrictive and often frustrating.

Below are some interesting resources to read if you’re frustrated about your current position and feel there is no way out.

There isn’t one single and exclusive path forward, and it’s up to you to decide what journey you want to take.

I’ll see you next week 🫡

📚 Resources to read:

• The Engineering/Manager Pendulum

• What is a Staff (or Staff-Plus or Principal) Engineer

• Who are Staff, Principal, and Distinguished Engineers?

• The Skills Map of Senior Tech Career Progression

How often have you prepared and carefully laid out a neatly prioritised and estimated year of initiatives and deliveries? Something like this:

It’s like a perfect little story. A three-act structure. The beginning, the middle and the end.

End of story. End of the newsletter. Goodbye! Have a lovely week.

But wait a minute…

Do you genuinely think this depicts at all the reality?

As you look back at your year, that excellent plan above looks more like something like this:

So many things happen throughout the year. Especially in companies that have a fast pace, where you plan and lock in a yearly fashion, the image above is inevitable.

From having wrong estimates, shifting priorities, unexpected requirements, and changes in capacity, you have to be nimble enough to navigate through these times while simultaneously being capable of creating and executing a plan.

So as an Engineering Manager or as someone responsible for creating and maintaining your team’s roadmap, how can you work through this?

My suggestion is to focus on a more flexible approach, something that accommodates change and, at the same time, gives you enough assurance that you can manage a stable team.

The Now, Next, Later format was created by Janna Bastow in 2012, and the focus was to create a roadmap view focused on priorities and problem-solving instead of a deadline-based delivery.

Bastow creates three main buckets:

NOW

• Initiatives that you are currently working on right now.

• You have a high degree of detail on these initiatives.

NEXT

• Once everything you’re working on NOW is complete, you’ll tackle this.

• You don’t have as much detail, but you know that they will be a priority.

LATER

• Everything else you have set on doing but still without a defined date.

• Very little detail, only broad ideas.

• Allows you to know the direction you’re taking.

I’m sure you’re now thinking about how this is all a pretty essay, but it doesn’t fit your reality because you must deliver a timeline-based roadmap.

There’s no way a hip roadmap technique like this would ever work at your company.

Let's see how to use this technique and revisit our wonderful year roadmap above.

Start by understanding how these straightforward concepts can change much of what you’re doing.

Looking at the buckets, you’ll notice a couple of 📉 downward trends as you go from the NOW to the LATER buckets:

• The degree of detail you have on each initiative

• The impact of shifting priorities

• The level of preparation you need for each initiative

What if we tried to apply Now, Next and Later definitions to our yearly roadmap?

Notice how you don’t have a later in this view. That’s because, in the definition, the Later column doesn’t have defined dates, so you end up with nine months of Next.

How can we improve this view? Focus on a quarter view.

First, let me highlight that you should revisit the plan monthly for this technique to work. This allows you to quickly change and take full advantage of the Now, Next and Later roadmap.

Let’s go back to the buckets and define them a little more.

NOW

• The next three months - M1, M2, M3

• Avoid changing anything in the next month (M1) at all costs, but allow some change in the following two (M2, M3).

• You have great detail on these initiatives (motivations, dependencies, complexity, workload, estimation, etc.).

NEXT

• The following three months - M4, M5, M6

• Be flexible to change here as the level of uncertainty is higher.

• You should prioritise your initiatives, have a high-level estimate, and have critical aspects like identifying and informing dependencies.

• Be ready to shift things around, but you know what to tackle next.

LATER

• The final six months - M7, M8, M9, M10, M11, M12

• Let’s face it. You have absolutely zero guarantees here. All you really have is an idea of what you’ll work on.

• Keep a tidy backlog of initiatives and review them often so you’re ready to put them in the next bucket.

This would bring our yearly roadmap to something like this:

I can’t stress enough that even when you’re using a more flexible approach like this, you must know your hard deadlines and prepare accordingly. There’s no excuse if you don’t prioritise a delivery that is ten months away.

As a manager, this system will help you have a better lock of what your team is focused on in the next three months and for the team to feel less of the noise of priorities changing constantly.

Finally, let me just highlight that you shouldn’t shoot for a perfect roadmap.

It doesn’t exist.

Work instead on your prioritisation skills, your reaction time for when things change and how you deal with customers and stakeholders.

I’ll see you next week 🫡

In today’s email:

• Toil: This is ruining your org

• DeveloperWeek Europe: An exciting event.

• Post of the week: 5-star on social media.

TOIL

This is a well-known term in tech.

Every time your team stops their sprint programmed tasks to focus on grunt, repeatable and automatable work, it's probably toil.

At first, these are just a couple of harmless manual tasks, but before you know it, your team is swamped with meaningless tasks that occupy nothing more than time and produce no value.

Let's move this into a practical example.

Imagine you have a web server that usually fills up its disk because the .tmp folder gets bigger and bigger. Have you lived through this?

With this scenario in your mind, let's see the definition that Google has for toil tasks:

• Manual - You stop everything you're doing and manually clean that folder.

• Repeatable - This keeps happening; you must revisit that folder every few weeks.

• Automatable - Can you create a script that does this automatically? Can you reduce the amount of interaction you have with this task?

• Reactive/Non-Tactical - You stop everything you're doing to look at this disk space scenario. Is this truly the best you're doing with your time?

• No enduring value - If you do nothing else, going in and cleaning that folder has no value considering that you'll have to do the same in a couple of weeks. Why is that folder filling up? Why not attack the root cause?

• Don't scale - It's all fine when you have one webserver. What about 1000? How does this scale?

Think about your reality.

It's almost independent of what field you work in. There's always toil work.

I tend to get annoyed when I have to do things recurrently. If automation is possible, I always try to script my way through work.

What tasks and work do you do that is, in fact, toil work?

Once you clearly label your toil tasks, you can then move into a data approach:

• How many toil tasks did you do in the past week? What about the past month? And the past year?

• How does that translate into time? How much time is toil taking from you?

The first part of dealing with a problem is accepting that you have a problem, and for you to do that, you need to understand toil and how it affects your daily work.

You should now be able to:

• Review which of these tasks are automatable.

• How long it will take you to automate them.

This second point is critical.

Contrary to popular belief, not everything is worth automating.

Let's say that you take 4 hours automating a task that manually takes 1 minute to perform.

That means that only after 240 tasks do you move into the profit zone.

Only you know if this is worth it. If you have 50 tasks like this yearly, I highly doubt it's valuable. However, the return will be swift if you have 1000 tasks a month.

Look, this isn't always a slam dunk, but you need to look over your team as a leader.

Toil has clear adverse effects on a team:

• Meaningless tasks

• Constant context switching

• Reduces team capacity

• Non-strategic focus

It's important to remind you that, in the same way, you shouldn't aim for 100% availability. You shouldn't seek 0% toil work.

Toil tasks will eventually appear. Your goal as the team leader is to keep them manageable.

So now I ask, have you ever considered toil? How much toil do you do on your day-to-day? How about your team? How affected are they by toil tasks?

DEVELOPERWEEK EUROPE 2023

I’m happy to announce that I will be a Featured Speaker at DeveloperWeek Europe 2023.

I will share my views on how we, Engineering Leaders, should deal with this crazy environment the Tech Industry faces.

We’re usually asked to do more with less. How about if we change it and try to do better?

This will be the topic on April 26th.

Check the link below for more information.

Stop Trying To Do More With Less

POST OF THE WEEK

A couple of weeks ago, we had the privilege to get Kelsey Hightower at a fireside chat at FARFETCH.

I'm not even going to get into how amazing the chat was, but I want to focus on something that he said, which is still resonating with me after several weeks.

Be more than you HR Title.

Kelsey Hightower

How often are we sidetracked by office politics, promotions, or the lack of them?

How often do we lose focus over small, petty things?

I know that this was a line in a middle of a conversation, but if you think about it, it’s a pretty deep one!

Well done, Kelsey!

In today’s email:

• Return to Office: Mandated return to the office

• Fridays at the office: A weekly habit

• Post of the week: 5-star on social media.

RETURN TO OFFICE

Well, here at last, dear friends, on the shores of the Sea comes the end of our fellowship in Middle-earth. Go in peace! I will not say: do not weep; for not all tears are an evil.

The Return of the King
J.R.R. Tolkien

As the adventures of the Fellowship of the Ring come to an end, it appears that the time of remote work is also seeing its last rays of sunshine.

When COVID-19 hit us in March 2020, most companies worked in traditional offices or campuses. Me, you and probably most of the people you know were sent home, and we all learnt how to work from home.

We faced many challenges, from washing cans of conserves, quarantining supermarket bags, installing, uninstalling and then re-installing Zoom as it faced security issues. We learnt how to deal with waving hello and goodbye at every meeting and how to be productive without having everyone together in the same room. Heck! Zoom is more than a brand. It’s an everyday expression!
(Did I mention how good we all became at making bread?)

We have a saying in Portugal, “Primeiro estranha-se, depois entranha-se”, that roughly means, at first, you find it strange, but then it becomes your second nature.

I think that remote work was precisely this for most people in the tech industry. At first, everything was quite complicated. We had to re-learn how to do dailies, 1:1s, how to capture and give feedback, how to read people, etc. But quickly, we saw the benefits of being able to focus without interruptions, of not having to commute, and above all, of improving our quality of life.

Throughout these months, some companies re-called their workforce back to the office, most of them in hybrid mode, being the most recurrent a 3-2 mode with a portion in the office and the remaining at home. Apple and Google were examples of this back in the summer of 2022.

On February 17th, Andy Jassy, CEO of Amazon, published a message where he calls back Amazon workers to the office in the 3-2 format. Contrary to what happened with Google and Apple (at least as public as this one), it received massive backlash from employees as they were mandated to the office with only a couple of months in advance.

It’s critical to add that Amazon hired employees remotely, primarily focused in the country and not on their location. This meant someone could be allocated to an office a mere six hours away. Suddenly, everything changed, and people had to either relocate or eventually move on to their next adventure.

Meta’s Mark Zuckerberg also published the same intentions in March to get back to the office in 2023.

After all the layoffs, are we seeing the end of the remote work saga?

I’m sure that companies like Gitlab and Todoist will remain remote-first companies because they were already remote companies before COVID.

Maybe the consequence of this is the introduction of hybrid work. Offices will regain their life, and businesses that depend on these offices being full will resume activities at what were previously normal levels (catering, cleaning, renting, hardware, etc).

FRIDAYS AT THE OFFICE

A while ago, I mentioned that I would make my visit to the office a habit, and after nearly nine months, I wanted to bring you feedback on this change quickly.

You can read all about it here Redefining my Working Mode.

At first, it was incredibly bizarre to go back to the office. This happened as COVID-19 dissipated, but we were still using masks and following restrictive measures.

However, getting back together with colleagues from work and going for coffee and lunch with them was an incredible upside! How quickly we could sort issues that otherwise would take several zoom calls, and sometimes how we rallied together towards the goal of completing a project.

Oh, and the whiteboards! To this day, I’m yet to find a good substitute for getting everyone around a whiteboard wall and brainstorming.

I’ve mentioned several times that I’m a fan of hybrid work. But above everything, I’m a fan of getting the most out of everyone. Sometimes that means that people go once a week to the office, others go every day, and others just once a month.

It’s all about balance, but it’s been nine months, and honestly, I think this was one of my best decisions!

Primeiro estranha-se, depois entranha-se.

Fernando Pessoa

POST OF THE WEEK

How often do we, as managers, feel like innovation isn’t part of our job?

I want to raise a flag and say stop 🛑

There are several ways that we can and should innovate.

Think outside the box!

In today’s email:

• Compa Ratio: Meet the target.

• A Few Tips: Being a Comp Planner isn’t easy

• Post of the week: 5-star on social media.

COMPA RATIO

We’re at that stage of the year that you’re either completing the End of Year Performance Review or have just completed it. And the last stage is the one that is the most nerve-wracking: Compensation Review.

Your teams will find out how they’ll deal with all the macroeconomic instabilities the world is currently dealing with: war, inflation, high-interest rates, etc.

If you’ve been following the newsletter, you probably already know I’m a big fan of The Pragmatic Engineer. A couple of weeks ago, Gergely wrote an issue on the expected compensation increases for this End of Year cycle. Please dive into the article below, but one of the main takeaways is that most companies will give out raises below the inflation.

If you want to see your country's inflation rate, please check TradingEconomics.

The Pragmatic Engineer

Compensation Increases in 2023

January is that time of year when most companies finalize their annual compensation increases for the next 12 months. Between January and March, they are communicated to staff. In 2023, how big will be the raises of software engineers and tech workers? I asked professionals with inside knowledge about what they are seeing in budgets. More than a hundred people responded - including many readers of the newsletter. Thank you! The majority of people being CTOs, engineering directors, engineering managers and HR folks. A few respondents are tech leads and software engineers to whom the increases have been communicated. Two CEOs also shared details…

Read more

3 years ago · 62 likes · 3 comments · Gergely Orosz

From the get-go, you can see a major difference between the bullish market and compensation cycles we witnessed in previous years.

It’s interesting to see this data when most people expect to match the current inflation to be able to deal with the price increases in their day-to-day livelihood.

Some of you are Compensation Planners - the ones that get to decide how the budget for raises is distributed in your team. For those of you who are in this position, get ready for a bumpy ride.

Expectations are some of the most challenging barriers to overcome, and here I want to highlight a method to assess the state of your team against key metrics.

Enter the Comparative Ratio, aka Compa Ratio.

The idea behind this ratio is to position each individual from your team against a well-defined target.

Many companies, particularly larger ones, have salary bands - pay ranges defined by the company per role. Usually, you use the Compa Ratio to compare the salary of an individual against the middle of the salary band for that position:

This will give you a percentage of where you will position each team member.

The possible outcomes are:

• < 100% → Salary is below target.

• = 100% → The target was achieved.

• > 100% → The salary is above target.

This might seem like a straightforward ratio, but it’s a great way to create a layout of your team, understand where you need to invest, and use data to guide you through the decision-making process.

While you won’t use the Compa Ratio to make decisions exclusively, it’s an incredible way to generate quick ideas.

A FEW TIPS

I want to add some quick notes for all of you Compensation Planners.

Keep Emotions Out

This is one of the most valuable pieces of advice I can give, and I can’t stress enough how important this is.

As your team grows, you will have more and more singularities. If you let them cloud your judgement, you will reach a set of very hard-to-justify salary increases.

Data is Key

Once you set aside emotions, focus on data-driven decisions.

I usually start by ignoring any budgets, and try to lay out the landscape of my team, understand how the compa ratios are distributed, when was the last raise, when was the entry date, etc.

In my mind, there is no such thing as data overload. Not when it comes to something as important as this.

Tell a story

To me, it’s essential to be able to tell a consistent story that explains your thought process and that, from your macro vision, is very clear and aligned with your company's priorities.

Having data to support your decisions and not running away from your route will strengthen your story.

What if it leaked?

A couple of years ago, someone told me that the best way to think about salaries is to plan for the salary sheet of your team to leak and see if you’re ready to justify everything.

If you’re comfortable with what that sheet states, you can justify your decisions (again supported with data), and you know deep down that you fought for your team as a whole.

You’re not going to please everyone

This might seem obvious, but when you’re looking at that sheet, you want to be that fantastic boss everyone loves because you’re awarding amazing raises to everyone.

While you might live in an environment where this is possible, most managers don’t.

This is your job, your responsibility. You’re not supposed to be a friend. Your goal is to be fair and focus on the company's priorities.

This is the time of year when we go from best to worse. It’s a phase, and yes, it blows over.

You can do it!

POST OF THE WEEK

If there is something that you, as a team leader, will continuously work on is Team Communication.

Your team will go through several phases, some absolutely brilliant while others where you don’t understand why messages are not going through.

Keep working with your team, and clarify why you focus on a particular topic.

Use retrospectives, use transparency and focus, and above all, make it everyone’s job to keep fighting for a better team.

In today’s email:

• The Flatening: Be prepared for a brand-new layout.

• SVB: Panic at the disco.

• Post of the week: 5-star on social media.

THE FLATTENING

Let me paint you a picture of the current status of the tech market.

On January 23, I wrote that 55970 tech workers were already announced that they would be laid off. A mere 50 days later, that number grew to 128202 tech workers with announced layoffs. And note that we still have news that Meta plans to add a few more thousands to these numbers.

As the market keeps contracting, companies are adapting to become leaner and reduce the size and bureaucracy created by the massive scale-up of the past five years.

A big part of reducing the size of a company starts with reducing the layers of management. You can see clear examples of this, for example, with Meta’s plan to reduce the number of Engineering Managers and above.

I believe it’s inevitable to have a restructure of leadership at these companies doing layoffs and trying to become more economically viable.

First, let me suggest that you look around. Try to understand where your company stands in this tech economic crisis and how it’s structured.

Has your company been through layoffs? Are you going through layoffs right now? Does it have a significant leadership per individual contributor ratio?

We will see small teams merge to create larger teams with a bigger scope. Managers increase the number of their direct reports. And while I don’t think every middle manager will disappear, many of them will. Having such a heavy leadership layer in smaller and more effective companies is unsustainable.

Similar to what happens with individual contributors, only the top managers will remain. There are two possible routes for the remainder: going back to individual contributors or finding a new challenge. The higher the seniority of the manager (ex: director, head, senior manager, etc.), the harder it is to move to the equivalent individual contributor role.

Now, while it’s fairly easy to see the positives of increased efficiency at all company levels, this has to be done responsibly, with the risk of paying a heavy penalty.

In general, flat structures rely on constant communication, decentralized decision-making and the self-motivation of employees. As a result, flat structures are associated with innovation, creativity, speed, resilience and improved employee morale. - FORTUNE

The number of reports of managers will increase significantly, as well as the number of scopes. The work towards a healthy work culture and mental health that has been done in the past twenty years might be at risk.

Important to highlight that when I mention culture here, I’m not talking about the variety of cereals that companies have in their kitchen.

We’re still at the beginning of this trend, and we’re yet to see the exact result and consequences.

As a manager, the best you can do is keep your network strong and not lose your technical side, as the future might require you to return to the individual contributor path.

SILICON VALLEY BANK

So layoffs are a reality, hiring is almost frozen, and, as I mentioned above, companies are flattening their ranks. If these don’t look bleak, here enters the Silicon Valley Bank fiasco from this past week.

The Silicon Valley Bank (SVB) is a top 20 bank in the US, specialising in tech startups. According to Milk Road, ~50% of all US venture-backed tech and life sciences used SVB to hold their funds.

In a nutshell, SVB was forced to shut down by US Government. About $175B of customers’ deposits were seized, and as customers made a run for their money, it wasn’t available.

This means that companies had their assets frozen, and guess where these assets come in handy? To pay salaries and other companies at the end of the month.

We’re already seeing reactions from the market, like Remote’s CEO Job van der Voort is already jumping ahead of the chaos and saying that the company will advance the salary for people working in affected companies through Remote.

Could this be a publicity stunt? Maybe. But the fact of the matter is that this action will effectively help those not going to be paid this month because of the SVB fiasco.

Why am I raising this topic? Because this is another massive hit to the Tech Industry.

Yesterday I read an impressive tweet reporting a fist hand experience of a founder affected by the SVB. I highly recommend that you read the entire tweet.

This could be an isolated case or the beginning of a rollercoaster that will impact the remainder of 2023 and perhaps spill over to 2024.

If you want to read more about what happened (with a lot of important details), I recommend the issue below:

Net Interest

The Demise of Silicon Valley Bank

“When you’re not working, what do you do to de-stress?” That was the last question Greg Becker, CEO of Silicon Valley Bank, fielded at an investor conference on Tuesday this week. “Cycling is my advice,” he replied. “Living in Northern California and being on the peninsula. That’s just—I think it’s the best bike-riding cycling in the world, period…

Read more

3 years ago · 859 likes · 67 comments · Marc Rubinstein

POST OF THE WEEK

It’s funny that amid this week’s newsletter, where I’m talking about the contraction of middle management, I focus on something like Empathic Leadership.

When I mean that this flattening process has a significant penalty risk, I mean that behaviours like empathic leadership, authentic leadership, coaching and mentoring of individual contributors or other leaders might disappear.

And this is really important for us to keep in our mind. Circumstances might change, but we, as leaders, are responsible for building our teams! 🚀

In today’s email:

• Be Accountable: Not everything is perfect all the time.

• Leadership for the Rest of Us: I couldn’t wait to read this book.

• Cool stuff on the web: The best stuff on the web.

• Post of the week: 5-star on social media.

BE ACCOUNTABLE

Last week I talked about how important the way you communicate something is. How the same strategy, with the same goal, but communicated differently can lead to entirely distinct outcomes and acceptance levels from the teams.

This week I want to continue on the topic of communication, but this time how you, as a leader, communicate with external teams, your clients and partners, and the issues or outages that the product that you're responsible for had.

I've seen the full spectrum throughout the years: from communicating clearly every incident, filled with documentation, to no communication whatsoever. Let's dive into each strategy, and I'll let you choose the style you want to proceed with.

As a disclaimer, I'm biased toward a full transparency model.

THE BLACKOUT

Let's start with an apparently protective method: The blackout.

By not communicating with customers that your product had a downtime, you may be shielding your team from external criticism or senior leadership having a wrong idea about the quality of your team.

Why I firmly believe that you shouldn't go down this route:

1. Your customers see that the product they use is unavailable without communication from the owner team.

2. By not communicating or performing post-mortems on incidents, you're depriving your team of the possibility of improving.

3. Your partners, and other teams that work with you, will lose confidence in the effectiveness and reliability of your team.

Notice that by going into full blackout mode, you affect your most crucial triad:

It's tough to imagine a medium to a long-term strategy based on this working method.

FULL TRANSPARENCY

On the other end of the communication spectrum, you will find a team that focuses heavily on communication.

This team tells their customers exactly what is happening with the product they use every week.

You might argue this brings an overload of work to the team. But this makes the team even more responsible for the product they maintain and evolve.

The responsibility of communicating weekly the status, downtimes, post-mortems, nest

Why I believe that this is the best route for a team to take:

1. Your customers know that any unavailability will be followed up with thorough communication. They trust that their product is being cared for and that your team values them as customers.

2. By continuously working and documenting the state of your application through clear communication and post-mortems, your team is aware of the critical actions that your team needs to perform to improve the product.

3. Your partners, and other teams that work with you, know that any outage has a follow-up, and the team will act to prevent future occurrences.

This way of working, or something close to it, is the best approach a team should take.

As a leader, I am fully aware that I need to go through two types of experiences:

• One where I praise my team for being awesome and delivering challenging and value-creating initiatives and projects

• Another is where I communicate outages and failures caused by a code or configuration change or a failure somewhere in the process.

We first need to understand that outages in our products will happen, and our team will make mistakes (just like we do). The important part is how you and the team deal with outages.

You must hold the team and yourself accountable for what happened and help them work through the outage, help them improve and prioritize the actions coming from the post-mortem.

You see, I take transparency and accountability as cornerstone values in a leader. Be accountable for your team, communicate clearly with your customers, and keep improving your product.

LEADERSHIP FOR THE REST OF US

This has been one of the books I’ve been dying to read. So what better time than during insomnia?

I can’t find any other word to describe me at 4 AM than the eternal Red Forman:

Obviously, I couldn’t put the book down and just perpetuated the insomnia.

Just as a quick intro, Sarah Drasner is a Director of Engineering at Google. On top of other achievements, Drasner published this easy-to-read (circa 220 pages) book on leadership for the everyday leader.

I’m a big fan of the writing style, and Drasner captures a full 360 degrees of the challenges waiting for brand new Engineering Leaders.

On a side note, this book has some of the most amazing cover art I’ve ever seen.

I’m still going strong in this book, but if you want to improve your leadership skill set, I couldn’t recommend “Engineering Management for the Rest of Us” more.

If you’re enjoying this article, feel free to click the ❤️ button on this post so more people can discover it on Substack 🚀

COOL STUFF ON THE WEB

• 🎧 Diary of a CEO - I love this show! Diary of a CEO was one of the most unexpected shows I found in the past few months, and you’ll find an incredible range of guests and topics that span from sports to business and leadership.

• 🐦 Bird’s eye view of an entrepreneur/solopreneur path - Creating content, publishing in different mediums, and building an audience, a community is exactly like the image below. It has its ups and downs, highs and lows. The moments where we feel like we’re really helping other people, while others where we feel like a pure impostor.
  
  Step by step. Day by day. Post by post. We keep building 🚀

POST OF THE WEEK

It’s incredible how many people think that working flexible hours, asynchronously or remotely, are the same thing.

Do you agree with the list below or the pros (🔥) and cons (🧊)?

In today’s email:

• Communicate Clearly: The dangers of miscommunication.

• What problem are you trying to solve? Take a deep and honest look!

• Cool stuff on the web: The best stuff on the web.

• Post of the week: 5-star on social media.

COMMUNICATE CLEARLY

This week I was talking to a friend that works in a very operational type of team: they’ve been working together for a long time, don’t do a lot of tracking of tasks or backlog, but have been working like this for a long time and their delivery rate is quite good.

Note that this is not a product team but more of an IT/Infra team.

They were surprised by the sudden arrival of agile coaches in the company and the idea that they were the answer to all of the problems.

Listen, I adore agile, and I think that agile coaches are fundamental at a certain point of growth of a company, but, like every big change, it needs to be supported by a vision, by a top-down decision of where we are and where we want to be.

In this scenario (and this is my interpretation), the top-level executives were led into the idea that by implementing agile, they will:

• Increase productivity levels exponentially, delivering more initiatives than before

• Increase overall happiness levels of the teams, and this way, retention levels

• Reduce the amount of confusion and miss-communication cross-teams

• All of that without having any initial impact on the company's current roadmap.

At the end of the day, implementing Agile is the silver bullet the company has been missing. Due to the lack of senior leadership communication, I think they will inadvertently create a pit between teams and the newly created Agile Coaches Dept.

Right now, there are either unrealistic expectations of those agile coaches or no idea who they are, why they’re here and why they will try to change how teams work.

Unless there is a shift in the communication style, teams will see them as outsiders, and the impact and change they end up creating in the company will be significantly lower than it could have been.

Let’s focus on your team or your cluster now.

If you are going to shake the waters, communicate. Explain your vision and share the reasoning behind your decisions. You might get some surprises like:

• Your team might contribute with insights that will strengthen you even more, your idea.

• The team might also contribute with a set of experiences that will prevent you from wasting time going through certain roads.

Independently of what will happen, your team will know that you trust them enough to share your vision with them before acting and that you value their opinions.

A quick note before I go. When doing this, ensure you add deadlines to the discussion to prevent going through a neverending rabbit hole.

WHAT PROBLEM ARE YOU TRYING TO SOLVE?

This is it. Full stop. End of the newsletter. If you only take one idea, one concept of this week’s issue is this question.

Talking to my friend, I reviewed some of the agile practices I’ve worked with for years. Like so many other frameworks or methodologies, these practices alone will not save the way your team works.

Agile doesn’t introduce or remove bugs from your system. Waterfall is not to blame if you add passwords in clear text and commit them to GitHub. These systems are not there to solve every single problem you have, but they’re there to improve the process.

One of the most productive and (honestly) incredible people I’ve worked with is an Agile Coach. She taught me so much that, to this day, has completely changed how I look at our work and how we do things.

Simple things like cycle time, lead time, team velocity, better ways to estimate tasks, understanding that our estimates absolutely suck, retros, and retros of the retros to improve the retros… It was a really cool time because I shifted part of my brain into making sure that the team, the organism, worked independently and as adults.

No, we’re not here to start and stop your sprint.

No, we’re not here to create, close and move tasks in a JIRA board.

As a team, we are responsible for all of us being in charge of this.

With that in mind, we always rotated responsibilities, with each member learning and practising their craft in running retros, hosting refinements, and managing sprints.

Throughout those months working with Inês Santos, my mindset changed to always ask the question, “What are we trying to solve here?”.

When I stared at a JIRA board, I was trying to understand where the tarpit was or how to “stop starting and start finishing”.

Going into retrospectives, I always tried to understand what we were trying to do a retro on and adjust it. The type of retro you use to discuss a sprint is different than the one you use to discuss how a team feels about their mission and is different from the one you use when you put together two teams that don’t get along.

So, whenever you’re faced with a new scenario, a new problem, or new people joining your company, turn your growth mindset into hyper mode and ask yourself:

What problem are we trying to solve?

(Thank you, Inês, for being such a positive influence in my work! 🚀)

COOL STUFF ON THE WEB

🌤️ Andrew Huberman Morning Routine

I’m sure you’ve heard of the great Andrew Huberman for those who like to focus on self-improvement. In this video, Huberman goes deep into his morning routine.

No way I can deal with the salty warm water first thing in the morning.

Are you following any specific morning routine?

📝 Daily Stoic - Control and Choice

I’ve been going more and more into Stoic principles, and this one gets me every single time.

Have a clear understanding of what you can and can’t control. Reflecting and reaching a clear conclusion gives me a better understanding of how and where to dedicate my energy.

I feel that I start as an immovable rock, but once I understand the intricacies of what I can control, I immediately become water.

Be water my friend.

Empty your mind. Be formless, shapeless, like water. You put water into a cup, it becomes the cup

Bruce Lee

📰 Platformer

For the past few weeks, I’ve been reading the Platformer.

So far, it’s a good source of tech news and has a lot of insights into Silicon Valley companies.

What other newsletters would you recommend?

Platformer

News at the intersection of Silicon Valley and democracy. On Monday, Tuesday, and Thursday at 5PM Pacific.

By Casey Newton

POST OF THE WEEK

This survey is still going strong but wow! I thought we would see more people working from the Office 100%.

Really impressed!

If you haven’t voted yet, please do and share your current status 🚀

In today’s email:

• Technical Debt: Time to pay your dues!

• Leadership Debt: It’s not just the others that create debt.

• Cool stuff on the web: The best stuff on the web.

• Post of the week: 5-star on social media.

TECHNICAL DEBT

I'm sure you've heard all about technical debt!

Heck, it's a topic of conversation within the first hours of leading a team. You hear people talking about it in retrospectives by the water cooler, and it's one of those topics lost deep within the team's backlog of tasks.

So let's start at the beginning.

Do you know when you take a shortcut or make a trade-off that will help you deliver a feature faster? The "we'll fix this later"? That's what technical debt is.

By itself, the decision to take a shortcut shouldn't be a problem. However (and get ready because I'm going to use that word I love so much), as technical debt piles up, it compounds! 

And this is where the problem lies.

Before you know it, your team has several, and usually undocumented, shortcuts throughout your codebase that made sense at a point in time but now slow down progress.

Technical debt can take many forms: 

• skip creating all the necessary tasks due to time constraints

• take shortcuts, prioritising a more straightforward solution

• making assumptions, etc. 

This leads to poor code, making it harder to evolve and find and fix bugs.

Now that you know and can identify technical debt, here are some essential practices to avoid, manage and remove your technical debt.

Keep a Technical Debt Ledger.

I can't stress the importance of documenting decisions enough.

How often have you received a project where critical decisions were made but no documents support the reasoning behind these decisions? Or having to develop a feature, but you need to understand why the team took shortcuts two or three years ago, and the people involved in those decisions are probably no longer with the team.

A Technical Debt Ledger is a document where you track the debt of your team. You write down every shortcut, quick decision, shortcuts, known bugs not fixed, known areas lacking testing, etc.

A ledger should contain key information such as when the debt was added, the reasoning behind it, how much it costs to fix it and above all, the linked task to pay the debt.

If you want to start using Tech Debt Ledgers, I created one in three different formats for you to use: Google Docs, Notion Template using Tables and a Notion Template using Databases.

You can find the templates in the newly created Free Resources area.

Make removing Technical Debt a Priority.

I'm 100% sure you know that you have to make it a priority for your team to reduce technical debt. But I've also heard time and time again how difficult it is for Engineering Leaders to prioritise Technical Debt with Product Owners/Managers.

So let's start by working collaboratively and not in us vs them category:

1. If your product owner needs to learn about technical debt, educate them and explain how it impacts the development process. Make sure you highlight the risks for the product by not removing that debt.

2. Highlight the benefits of paying your technical debt, focusing on the developer's productivity and happiness levels.

3. You should often report on the impacts that reducing your technical debt has on the team's ability to deliver features.

If you're not working within a product environment, you're in control of your team's roadmap, so you're the sole responsible for making it a priority:

1. Reserve time in your roadmap quarterly for Technical Debt initiatives

2. If you have small, achievable tasks that remove your Tech Debt, reserve a part of your sprints to do them.

3. Have you heard of Inbox Zero? Well, I recommend Ledger Zero! Be proud of your Ledger and share your progress reducing it.

Find the root cause.

Last but not least, if you recurrently add technical debt, you should find out why this keeps happening.

Only you know the reasons behind your team adding tech debt, but here are some common ones (you'll notice that they're all intertwined):

1. Tight Deadlines: Probably the reason #1 behind adding technical debt. Teams take shortcuts because they need more time to deliver features.
   👉🏼 Review how your team estimates tasks and the time you're reserving to complete those features in the roadmap.

2. Lack of Resources: If you need more resources to perform specific tasks, it's expected that your team takes some shortcuts or delivers tasks with lower quality than expected. 
   👉🏼 Review what is expected from your team and ensure you have the profiles in your team necessary to perform those tasks. Raise the flag if you don't. Communication and transparency are key.

3. Changing Requirements: If requirements keep changing, it's natural that your team tries to adapt, which usually means making decisions that go in the direction of delivering fast instead of right. 
   👉🏼 If changes are recurrent, negotiate added time for execution per change. Explain the benefits of focusing on the right approach and avoiding adding technical debt.

Most (if not all) teams have some technical debt. The main difference is the strategy and the way they manage that debt that makes the difference.

Contrary to your belief, good practices in managing tech debt are in your control.

Take advantage of this opportunity.

Technical Debt Quadrant by Martin Fowler

LEADERSHIP DEBT

As I said. I'm 100% sure you have already heard about technical debt.

Have you heard of Leadership Debt?

Don't think teams only add that debt. As an Engineering Leader, you're adding debt as well.

Close your eyes and imagine you saying the following: "Let's do it like this for now, and we'll revisit this approach/decision in the future". 

How many times have you said this?

Here are a couple of examples of situations where you might increase your Leadership Debt:

• On Call practices: Let's use two elements instead of 3. Yes, there's some risk of burnout, but we'll revisit this situation in the future.

• Communication issues: Team A keeps requesting tasks from us within a limited timeframe. Let's do it for now, but we'll revisit it so it doesn't happen again.

• Backlog Management: The team continues with an unclear backlog. Let's ensure they have enough tasks for this sprint, and we'll review them in the future.

• Mission & Vision: The team needs a clear mission & vision for what they're doing. Let's focus on this delivery, and we'll revisit it in the future, so they're more engaged.

I could go on for days.

As a Leader, you also add debt. 

It's your responsibility to manage it and clean up the house. 

COOL STUFF ON THE WEB

🎧 Modern CTO - The Tech Layoff Crisis

This is an interesting take on why we’re witnessing so many layoffs in Tech, emphasising the United States market.

📚 Cloud FinOps - Collaborative, Real-time Cloud Value Decision Making

Starting to read this book on how organisations can spread the values and culture of FinOps to manage their cloud spending better.
I’ll def come back to this topic in a later issue.

📰 ByteByteGo - How does ChatGPT work?

Almost everyone has heard of ChatGPT, but do you know how it works and processes information to deliver accurate responses? Alex Xu shares how it’s done. A must-read!

ByteByteGo Newsletter

EP 44: How does ChatGPT work?

This week’s system design refresher: 8 Key Data Structures That Power Modern Databases How does ChatGPT work? Does the cloud really save costs? Amazon’s system architecture (1998 edition) New Machine Learning System Design Interview Book by ByteByteGo…

Read more

3 years ago · 141 likes · Alex Xu

POST OF THE WEEK

Twitter has reached a new low point as it’s starting to make security features exclusively for Twitter Blue subscribers.

I’m yet to find an app that provides the same service as Twitter - Mastodon doesn’t quite cut it.

Open to suggestions!