Notes is a new space on Substack for us to share links, short posts, quotes, photos, and more. I plan to use it for things that don’t fit in the newsletter, like work-in-progress or quick questions.

Go to Notes

How to join

Head to substack.com/notes or find the “Notes” tab in the Substack app. As a subscriber to leadingIn.tech newsletter, you’ll automatically see my notes. Feel free to like, reply, or share them around!

You can also share notes of your own. I hope this becomes a space where every reader of leadingIn.tech newsletter can share thoughts, ideas, and interesting quotes from the things we're reading on Substack and beyond.

If you encounter any issues, you can always refer to the Notes FAQ for assistance. Looking forward to seeing you there!

Go to Notes

Welcome to a new issue of leadingIn.tech newsletter. I’m Roberto, and this is where I share ideas, practices, and learnings toward becoming a better leader in technology.

I've launched this newsletter as a sidecar to leadingIn.tech as a place to try to put in my own words the learnings from all of the content I read about technology, management, and leadership. This issue is meant to be a compilation of those learnings since this newsletter was first sent.

Subscribe now

The first issue of the newsletter was in late 2020, and I published just two issues; the first one caught me just after reading "The Coaching Habit" and "Leaders Eat Last" two books that helped me start setting the foundations on the leadership approach I felt primarily identified, a servant leader, as someone who’s mission is to help their teams to overcome the challenges ahead by creating safe environments for experimentation, failure, and continuous growth while inspiring them to achieve ambitious missions.

The second issue of this newsletter is also today the second most read issue so far,"What does an Engineering Manager do anyway?" an evergreen post that helped me put in writing the areas where I believe Engineer Managers spend most of their time and also have the most impact for their teams.

2021, was the year where I explored a few topics like hiring, estimations, upstream communication, and improving our resiliency. Early in the year it felt like the worst part of the pandemic was over and things started to gain traction again. But, I've started seeing things through a different prism and my focus moved to thinking about adaptability, reacting to unexpected changes. I’ve closed the year writing about retrospectives, an activity that has become; in a primarily remote environment, one of my favourite moments of getting the team together and openly talk about what ways we could be doing better to work as a team.

Finally, on 2022 I did a small modification about the structure of the newsletter and started dedicating it to continuous improvement, I’ve discovered the book Atomic Habits which I dedicated the first issue of the year. Using the book as inspiration I started a series of posts dedicated to the book “The Art of Leadership; Small things, done well“ on issues 12,13,14,16 and 17. The series were meant to be small bits of learnings extracted from the books that would help me summarize the main learnings from each chapter. While reading it I’ve learned a lot about the levels of abstraction and influence an engineering leader has to deal with depending on their level on the org and the size of it.

My last two issues this year were about one of the most important skills an engineering leader should develop, writing and asking questions. By mastering these two skills you have the most basic tools to communicate and influence in your teams and others.

Thank you for reading me all along, I hope the lines written in this newsletter will you and others to find tools and learnings we can use in our day to day to be better leaders. I would like to invite you to stay with me for one more year and find more ways to share our learnings together.

I would like to wish you a Happy New year andd a wonderful 2023!

Subscribe now

💬This newsletter is better together. Here are the multiple ways you can join the community:

Linkedin (new)

Discord

r/LeadingInTech

Twitter Communities

Welcome to a new issue of leadingIn.tech newsletter. I’m Roberto, and this is where I share ideas, practices, and learnings toward becoming a better leader in technology.

Subscribe now

We are living in uncertain times, the news lately is filled by major tech companies doing layoffs and reducing their workforces. And now Twitter, just like a storm after the acquisition by Elon Musk, lots of people found their jobs to be terminated in just a matter of days. A measure that might seem precipitated and improvised. Especially when shortly after we hear that some of them were even fired by mistake (Whoops!) and then they realize they needed some of the people that were fired. Chances are that they will refuse to come back and that should not be a surprise.

There is a high risk of sacrificing writing things down for the sake of speed, either in favor of building things or making decisions. In this fast-paced world where we give that much importance to speed, sometimes we fail to see the value of documenting our actions. Probably because writing is hard, while it forces us to think, it takes time.

Shortly after the layoffs at Twitter happened, people started wondering how it would impact the stability of the platform. Why? Because we assume as normal that some people are “indispensable” to keep things running smoothly. Because there is valuable knowledge “in their heads“ that will be lost once they are gone. This feels to me like an organizational failure of assessing the bus factor risks.

Will we start seeing the typical “over capacity” messages? Will it happen that a server will come down, and someone will find a disk full of logs that used to be cleaned up regularly by a person who was just laid off? Maybe this is not the case at Twitter, but anyone that has been in software engineering long enough can relate to it.

We all love to build things, and once they are built we often forget that we will not be running them forever. How prepared is the system to be maintained by someone else after you leave voluntarily or involuntarily? How much documentation will the next person find at their disposal?

There are chances that there will never be enough documentation, or that it will become outdated too quickly, and some people might use it as an excuse for not writing at all. But I dare to say that documenting our work is as important as building the things we build. We usually say that software is in continuous evolution, so our written resources should be.

Writing allow us to materialize our thoughts and ideas, to be shared with the people around us. It also enables us to collaborate and evolve these ideas. Writing allows us to leave evidence of the context and the reasonings on why and how we built things.

Good documentation is a tool to support our second-order thinking, so we can understand the possible consequences of our decisions and the consequences of those consequences. See Chesterton’s Fence: A Lesson in Second Order Thinking. Understanding the context of why a fence was placed in the first place will help us understand the purpose of the existing artifacts, and having historical knowledge that helps us visualize the state of mind of the people to build it can help us understand the compromises they needed to take. Because of all of this, writing matters.

Writing matters, to you. To give you space to grow, and to effectively lead by giving autonomy to your teams. To improve your thinking and enrich it with others. To free yourself to be materially present for things to happen or pass on your knowledge.

Writing matters, to your teams. So they have room to work together as a team and better balance the workload, avoiding knowledge silos. To make better decisions with richer context and keep track of them for the ones that follow. To have time to log off and recharge when needed, to improve their engagement and ownership.

Writing matters, to your organization. So it grows in a healthy way and with resiliency. With enough flexibility to adapt to changes and to scale when it needs to. It matters so the culture is preserved and the context is shared with every person that joins it and not lost with those who leave.

Writing matters, to your customers. So they will enjoy the higher quality and stability of the product. So they know how your product works and how it will help them achieve their goals.

We can build better teams and organizations by not making ourselves indispensable because we didn’t write down everything we should have.

We can build better products by allowing the people who build them to make better decisions based on the greater context provided by our writings.

Your ideas matter, write them down.

Share

✉️Related Issues

leadingIn(tech)#3: Resilience

leadingIn(tech)#4: Building teams that will outlive you

leadingIn(tech)#5: Managing your upstream communication

leadingIn(tech)#7: Working Backwards to identify the right talent for your team

leadingIn(tech)#8: Wrapped

leadingIn(tech)#9: 1% better

leadingIn(tech)#15: Eliminate toil and give way to the team

💬 Would you help me build a community of leaders?

Join the LeadingIn.Tech Discord Server!

Welcome to a new issue of leadingIn.tech newsletter. I’m Roberto, and this is where I share ideas, practices, and learnings toward becoming a better leader in technology.

This week’s issue is about the value of asking good questions. As an engineering leader, you will find that you spend much of your time talking to people, trying to understand what are the most important problems that need to be solved, how things work, or understand the root cause of issues, to clarify requirements, interviewing candidates, and much more.

All of these activities involve plenty of active listening and asking useful questions. For this reason, being good at asking questions is definitely one of the most valuable skills any engineering leader needs to develop. Let’s explore in this issue some situations where engineering leaders typically need to display this skill.

Subscribe now

💡 learnings and ideas to become 1% percent better every day

1:1s

In the first two issues of this newsletter, I’ve talked about how I believe that one-on-one conversations are the holy grail of management, as the most important tool you have to connect with your team. These conversations give you the opportunity to listen to your team and understand their concerns.

If you have been doing 1-1s in the past you might have noticed that often it's hard to kick start a topic to discuss, “all is fine” responses become very common. It is here where as a manager you need to put your questioning skills to shine. How do you pick a question that helps the other person open up to you about topics they are hesitant to talk about?

The Coaching Habit book offers you fantastic tools to help you ask questions that trigger valuable discussions that can be used to understand the root cause of problems, help your team to reflect on issues, provide feedback or understand where you can help as a manager to help them succeed. From the book, these are the 7 core questions:

• What worries you? What’s on your mind?

• And what else? (A.W.E. Question)

• What’s the real challenge here for you? (Focus Question)

• What do you want? (Foundation Question)

• How can I help? (Lazy Question)

• If you’re saying yes to this, what are you saying no to? (Strategic Question)

• What was most useful for you? (Learning Question)

Additionally, on the leadingIn.tech toolkit, I’m compiling a list of useful questions that can be used as variations of these.

Retrospectives

I’ve dedicated a full issue to my other favorite tool as a manager, retrospectives. I usually use these sessions to kick off discussions within the team to identify areas of opportunities to improve how we work together or with others.

As described in that newsletter issue I’ve compiled a set of activities that aim to question the team in multiple ways to gather inputs about areas that can be improved. Starting with classics like What Went Well?, What We’d Like To Improve? or What Went badly? questions.

Additionally, these conversations drive questions such as “What can we do today to mitigate this problem?”, “Is this process still adding value?”, “What can we learn from this?” and many more. The goal of questioning in these sessions is to collect the necessary information to make informed decisions about what is working and what is not, but also to create a space for open and blameless discussions that drive action to solve the issues at hand.

Blameless, in the paragraph above is an important word, as a manager you need to make sure that the questions are not asked in a way that leads to pointing fingers. You want the team to work together to identify the issues and collaboratively act on solutions to them.

Post Mortem's

Similar to retrospectives, Post Mortem is a must in any engineering organization that wants to make improve the resiliency of its systems. Blameless is also an important word here, as mentioned in the Google SRE book, the goal of the postmortem activity is to identify the contributing causes of an incident and have the team work together to identify ways to prevent them from happening again in the future.

The Five Whys technique is a fantastic tool to try to reach the root cause of most issues, repeating asking why’s to subsequent responses of the first why will eventually lead you to the source of a problem that you can act on.

Project or Design Reviews

I see design reviews as fascinating tools for engineering leaders to stay in touch with the internals of the systems their teams build. This is an opportunity to be genuinely curious about what your engineers are proposing to build, to ask challenging questions to make sure that they have looked around the corners. To make probing questions to figure out if what we are building is really aligned with the business goals and is solving the problems that need to be solved.

• What is the main problem we are trying to solve here?

• What other alternatives have we considered?

• Why we chose option A vs B?

• What are the trade-offs?

• Does the solution scale? Does it need to?

• What is the cost of not building it?

These and many more questions can drive to really interesting conversations that will challenge your thinking and your teams. Having your team be able to articulate these answers will also help them grow and improve their skills for future designs. The important thing here is to be genuinely curious and not judge. Your team is the one on the grounds closer to the information to make better decisions, your role is to use your experience to challenge their thinking and come up with better solutions by themselves.

Hiring

As an engineering leader, you are not only responsible for managing your teams but building them. This includes hiring as the principal activity you need to be continuously doing. As a Hiring Manager, your role in the interview process is usually about understanding if the candidate has the right experience needed for the role and if they have the right alignment with the company culture.

I really enjoy interviewing and in my experience, I've seen that the best interviewers are the ones that again, are genuinely curious about the stories that the candidate is telling you. As an interviewer, your role is to ask questions that drive the candidate to tell you about their past experiences based on a context that you set up in your question, then based on the responses the skill needed to get valuable responses is to ask the right follow-up questions.

Follow-up questions, help you dive deep beyond the surface of what the candidate is responding to you. Your job is to try to identify how they managed the situation, what they tried and what they didn’t, what they learned about it, and what actions did they take to meet their goals. You want to understand how they manage challenging situations and what resources they have to overcome them as an exercise to predict how they will use them in your team. You are not looking for specific knowledge but for attitudes and reactions to different situations.

And remember to be genuinely curious, your questions should not include any kind of judgment about their responses, you want the candidate to open up and express themselves openly.

Wrapping up

We covered, 1-1s, Retrospectives, Post Mortem, Design Reviews, and Hiring on this issue, but these are not the only situations where you can exercise your questioning skills as an engineering leader. You will find yourself needing to use these skills with customers, stakeholders, service providers, and shareholders. If you noticed, I’ve made emphasis on the two main aspects of how I like to ask questions being blameless and genuinely curious. What I like about being in an engineering leadership role is being able to engage in insightful conversations that drive valuable outcomes of any kind.

Thank you for reading this far, hope you enjoyed it. To continue the conversation, can you tell me what other situations you have found yourself using your ability to make great questions?

Leave a comment

✉️ Related Issues

leadingIn(tech)#1: What’s new this month?

leadingIn(tech)#2: What does an Engineering Manager do anyway?

leadingIn(tech)#8 Wrapped

📄 Related articles

How to Ask Great Questions

The Five Whys Technique

What is a 5 Whys? Step-by-Step Guide to Running a 5 Whys Exercise

📚 Related Books

The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever by Michael Bungay Stanier

Google - Site Reliability Engineering

💬 Would you help me build a community of engineering leaders?

Join the leadingin.tech Discord Server!

Welcome to a new issue of leadingIn.tech newsletter. I’m Roberto, and this is where I share ideas, practices, and learnings toward becoming a better leader in technology.

This week’s issue is a continuation of the series dedicated to The Art of Leadership: Small Things, Done Well by Michael Lopp. This week I’ll be covering the chapter about “Anti-Flow,” a short chapter about a theme I love, “shower thoughts.” I find it fascinating how our brains continue working around specific topics even when we aren’t intentionally doing so. Is it a coincidence that most of our “ah-ha!” moments come from times when we are doing something else? How can we use that to our advantage?

Subscribe now

💡 learnings and ideas to become 1% percent better every day

📚Books

The Art of Leadership: Small Things, Done Well by Michael Lopp

The Anti-Flow

In software engineering, it’s a common topic to discuss how we optimize for flow states, where we are productive and have a continuous work throughput. As an engineering leader, it also translates into time blocks of your day where you meet with people to follow through an established agenda and make decisions or progress at work.

The Anti-Flow is about those moments when your mind is loose on some mundane activity and not constrained by the task at hand. There, your brain (involuntarily?) connects thoughts and ideas to produce something new that sometimes makes that “ah-ha!” moment spark; others give you a fresh look at something you had previously dismissed.

The thoughts generated on the anti-flow states are valuable and necessary inputs for your subsequent flowing sessions. These thoughts can be anything from unblocking yourself from working on a document in that you were not making significant progress, taking a different approach to a problem where there was no apparent solution, or identifying a flaw in your plan that you didn’t think about it before.

All of this seems magical, but it has its challenges; how do you ensure those thoughts generated in the anti-flow state stick so you can pick them up on your next working session? What strategies do you use? Rands, in the book, mentions the process of making memorable sentences that he can remember. In my case, I just save them as a new document draft with the “title” that better describes that idea. Find what works for you and use it to your advantage as a resource to enrich your creative process and value creation.

PS: One of the things I’m enjoying the most about making the switch to work in a company that operates in an async first structure is that it leaves room for plenty of “anti-flow” moments. I’ve discovered that my productivity has increased dramatically with short bursts of work inspired by ideas that generated where my mind had the chance to take a break and produce valuable connections.

As an engineering leader, block your time to get into “anti-flow” states, followed by flow sessions. Do not pack your calendar with unnecessary meetings. And remember, being busy is not the same as being productive.

✉️ Related Issues

leadingIn(tech)#12: Small things done well. Part I; taste the soup

leadingIn(tech)#13: Small things done well. Part II; Delegate Until It Hurts

leadingIn(tech)#14: Small things done well. Part III; Allergic to Wisdom

leadingIn(tech)#16: Small things done well. Part III.2; The Guard and The Culture Creek

📄 Related articles

Anti-Flow – Rands in Repose

💬 Would you help me build a community of leaders?

Join the leadingin.tech Discord Server!

Hi there! 👋🏽

Welcome to a new issue of leadingIn.tech newsletter. I'm Roberto, and this is where I share ideas, practices, and learnings towards becoming a better leader in technology.

This week’s issue is a continuation of the series dedicated to The Art of Leadership: Small Things, Done Well by Michael Lopp. The third part of the book is dedicated to executives and, as mentioned in the previous issue of this series, is especially useful for leaders landing in a new company with an existing team. In this issue, I’ll cover two chapters dedicated to company culture. The first is about how as the company grows, you can often identify the formation of two groups of people; the old guard and the new guard. The second chapter is about how the company culture is formed by the everyday actions of these groups of people working together.

Subscribe now

💡 learnings and ideas to become 1% percent better every day

📚Books

The Art of Leadership: Small Things, Done Well by Michael Lopp

Part III: For Executives

The Guard

If you are an executive that joins a start-up company that has been running for a while and starts to scale, you will find that usually, two groups of people can be identified; The Old Guard and the New Guard.

The Old Guard is formed by the company's early employees who have been there since the beginning of the times; they have been long enough to remember how and why things are the way they are. These people have built a bonding over time due to creating and failing together. They look up to each other and seem to have the superpower to fix things fast when they break.

The New Guard is everyone else that arrives at the company after the first group. You can find them both in an awe state and a helpless state. They are inspired by the work done so far by the old guard but also can feel overwhelmed by not fully understanding how things work and why they were done that way. They bring new energy and new eyes.

Old Guard: “I feel empowered to fix everything.”

New Guard: “I don’t know how to fix anything.”

Now, these two groups don’t know each other well enough. They don’t have shared experiences and haven’t built the same level of trust that the old guard did.

As a leader, you will have a mission to help build that new layer of trust. Your focus should be to create the environment and context where you can get these individuals to join their forces and use the first group's experience and the latter's fresh eyes to build The Guard.

🛡️ The Guard: A team who works together while learning better ways of building things and trust with each other.

The Culture Creek

What is the company culture? It’s not a set of sentences or words someone decided to paint on the walls and in a group of slides. The culture is formed like a creek, parting from an initial set of conditions where the water starts flowing.

Everything that happens afterward is a result of its beginnings and evolves from there. When you put together a group of people, the culture is formed by the stories that matter to them, the stories that are told when similar situations arise.

As a leader, your mission is to be a guardian of the culture, to pay attention to and remove obstacles that prevent the water from flowing its course. You won’t be able to change the course of how the culture is defined, but you can help by keeping it clean.

🎧Related Issues

leadingIn(tech)#12: Small things done well. Part I; taste the soup

leadingIn(tech)#13: Small things done well. Part II; Delegate Until It Hurts

leadingIn(tech)#14: Small things done well. Part III; Allergic to Wisdom

🧰Recent Entries to the toolkit

Developing Leadership - The Podcast for Engineering Leaders

💬 Would you help me build a community of leaders?

Join the LeadingIn.Tech Discord Server!

Hi there! 👋🏽

Welcome to a new issue of leadingIn.tech newsletter. I'm Roberto, and this is where I share ideas, practices, and learnings towards becoming a better leader in technology.

Photo by Will H McMahan on Unsplash

Last week I crossed with the post Why our engineering leaders focus on product over process where it talks about how HubSpot changed what they considered the primary role of an engineering leader assuming that you can only focus as much as on two out of the three main areas of influence for an engineering leader: people, product or process. By the time the article was written the company decided to move from People and Process to focus on the People and Product areas.

After reading that post my first reaction was to ask myself, why do they need to choose at the company level? And I believe they don't have to. On this issue, I’ll try to expand a bit more on my thoughts beyond the first reaction.

Subscribe now

💡 learnings and ideas to become 1% percent better every day

In one of the first issues of this newsletter, I asked myself the question “What does an Engineering Manager do anyway?” at the time I divided it into People, Delivery, Engineering, and Product with a few extra balls. But the main aspect of it is that I believe that depending on the context of the organization or the team the amount of time dedicated to any of these areas will vary. So the role of the Engineering Leader can be also described as eliminating toil and giving way to the team to do the work.

Eliminate Toil

By using as inspiration the concept of eliminating toil from the Google - Site Reliability Engineering book. Let's explore what is toil, with slight modifications.

Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.

By reading this we can understand that an engineering leader’s job is to help to eliminate any repetitive and non-value-adding work, so if we go back to the People-Product-Process triangle we can imagine that removing unnecessary processes that do not help the team to create value will be toil that will slow them down. Meaning that your job as an engineering leader is to help them identify what needs to be moved off their plate, automated or delegated.

• Are your “agile” processes getting in the way? Then help them iterate over it and streamline it

• Are they spending too much time generating status reports for the leadership? Find ways to automate it or to make the report as light way as possible

• Are they spending too much time on fixing production issues or dealing with support requests? Help them identify the root causes, reduce technical debt, or enable other parts of the organization to manage support (e.g: training, documentation, etc.)

Clear the way for your team. So they can focus on solving the problems that need to be solved.

Give Way

Here again, I’ll use another inspiration this time from a post titled “Always be leaving” from my friend Angel which was at the same time inspired by the same quote from Bharat Mediratta in the book Software Engineering at Google

So you have helped your team to eliminate their toil? What now?

I would recommend now giving way to the team to operate autonomously. Take a step back and observe, and find what is the next area where you can add the most value to help them operate at their best. Is it by working on the individual's growth? Or is it by partnering with the product managers to find what is the next biggest problem you need to solve for your customers?

The important thing here is that you remove yourself from the way so you are not necessary for the team to operate as you were about to leave.

As an Engineering Leader, you are responsible for the systems composed of the People, the Products, and the Processes. And your focus should be the one that helps to keep the harmony between them.

🎧Related Issues

leadingIn(tech)#2: “What does an Engineering Manager do anyway?”

📄Related Articles

Why our engineering leaders focus on product over process

Always be leaving by Ángel Cereijo

📚 Related Books

Google - Site Reliability Engineering

💬 Would to help me build the community?

Join the LeadingIn.Tech Discord Server!

After a few months of break, this is a new issue of the leadingIn.tech newsletter. I'm Roberto, and this is a place where I share ideas, practices, and learnings towards the journey of becoming a better leader in technology.

Probably you forgot you were subscribed to it, so I’ll try to make it short. There are multiple reasons I took a halt from writing but the first one was that I got caught in between changing jobs and summer break in between; well, the break extended a bit more than expected.

This issue is a continuation of the series dedicated to the book The Art of Leadership: Small Things, Done Well by Michael Lopp. The section I’ll cover today corresponds to a chapter dedicated to leaders in executive positions. Especially to those landing on a new company. The chapter revolves around how and when a person landing an executive leadership position should act to push changes in a pre-existing organization. Let’s explore.

Subscribe now

Photo by James Lee on Unsplash

💡 learnings and ideas to become 1% percent better every day

📚Books

The Art of Leadership: Small Things, Done Well by Michael Lopp

Part III: For Executives

This third act of the book is dedicated to emerging executives and the challenges it has, these kinds of positions are one step upper on the ladder and demand something extra from the leader, it’s no longer about managing a group of managers in a small organization, now you are responsible for an entire business or an organization. You are far away from the teams but at the same time, you are accountable for their outcomes. Usually, when fires fail to be handled up the chain they will escalate to you. As an executive, you will find yourself using your executive role to assign the right people to be on the front lines to put it out. But that's not your primary role, your role is to set the company for success and prevent the fires from starting in the first place.

Allergic to Wisdom

Startup companies as they grow create unique ways of doing things. And the people in it will firmly believe they can apply their uniqueness in all aspects of the organization, this can probably be justified as this was what made them successful in the first place. This usually translates into spending a lot of resources on innovating in areas where existing knowledge can be applied. In the book, this is referred to as “allergic to wisdom”.

But the truth is that not all aspects of the organization are the subject of innovation. And your job is to manage the resources of the organization as efficiently and effectively as possible to help your teams to move forward and keep innovating in the core areas where your company stands out from the crowd.

So, what do you do as an executive? You act, you don’t ask; you use your experience to identify those aspects where you can generate impact and just act upon it. You’ll share the vision and explain in detail where do we want to go next. You don’t say “back in <company name> we did it this way”, you just push the changes necessary to move the organization forward saving time and resources, even if they are not perfect at first. Then you’ll iterate.

🎧Related Issues

leadingIn(tech)#12: Small things done well. Part I; taste the soup

leadingIn(tech)#13: Small things done well. Part II; Delegate Until It Hurts

Some resources added to the toolkit since the last issue

📄 Articles

15 rules for communicating at GitHub | Ben Balter

Don't make yourself redundant - The Engineering Manager

Engineering Levels at Honeycomb: Avoiding the Scope Trap - Honeycomb

🧰 Other toolkits

Introduction | Engineering Ladders

💬 Would you help me build a community of leaders?

Join the LeadingIn.Tech Discord Server!

Welcome to a new issue of leadingIn.tech newsletter. I'm Roberto, and this is a place where I share ideas, practices, learnings towards the journey of becoming a better leader in technology.

This is the second issue of the series dedicated to the book The Art of Leadership: Small Things, Done Well by Michael Lopp. On the previous issue I covered the first Act of the book dedicated to practices and behaviours line manager can apply to successfully lead their teams, where in summary management is not about doing the things that need to be done but empowering your team to do the things.

On this issue I’ll extract highlights from the second part of the book which is dedicated to Directors (Managers of Managers) covering delegation, trust, creating a safe environment to give and receive feedback and learning from mistakes when things goes sideways to prevent making the same mistake twice.

As a leader of leaders you are in a higher level of abstraction of the work being done and your primary job is to empower the leaders within your organisation to build teams that can effectively execute. Meanwhile you have the responsibility to create the right structure and process that will allow the company to scale.

Subscribe now

Photo by Alex Shute on Unsplash

💡 learnings and ideas to become 1% percent better every day

📚Books

The Art of Leadership: Small Things, Done Well by Michael Lopp

Part II: For Directors (Managers of Managers)

The Blue Tape List

When landing in a new leadership role it’s normal that you find that there are multiple things that you think need to be fixed. You are able to do so because your brain is adjusting to the new context and it’s in high alert mode. You begin noticing things that people that have been in the same place for a while aren’t able to detect. Here is when you need “the blue tape” to identify all those things that might feel off.

As soon as you start gaining context you’ll notice that when you go back to the blue tape list you will be better positioned to handle the items on that list. Some of these items will require attention be indeed fixed but others will have a good reasoning to that way or might feel less urgent. The important thing here is not to rush to go and try to fix everything on day one until you have gained the enough context.

Delegate Until it Hurts

Delegation is probably the most important thing you need to learn to do as a leader no matter the level. But delegation must come with trusting your teams to do the job. Your role now is the one of a coach, we know that you know how to do the work but avoiding micromanaging is the one thing that will help you grow as a leader.

How to Recruit

Always be hiring, even when you don’t have open positions. Some times you will need to be in discovery mode by looking for people that will be a perfect fit for your company, use your network of people that you will love to work with again.

Once candidates have entered the pipeline. The goal is to understand if the candidate has the right set of skills for the job and for the candidate to understand your company’s mission, culture and values. And optimise for the best candidate experience.

Finally when you are ready to make an offer you need to make sure that what you are offering to the candidate is a delightful experience, compensation, perks, understanding of the job, what projects will they be working on, and what is the expected growth path from day one, overall a holistic onboarding process.

Gossip, Rumours and Lies

Chances are that if you are in a senior leadership position where you are a manager of managers you will need a staff meeting. This meeting is a flexible setting where you make sure that your multiple teams are in sync.

In the staff meeting you keep track of key metrics that tell you a story of whats going on in the company. In this meeting you open the conversation for a rolling agenda and leave space for spontaneous side conversations that otherwise wouldn’t happen.

Finally this is the place were your staff can raise any issue, ask questions or discuss those gossips, rumours and lies happening so you are able to articulate a healthy response.

Rainbows and Unicorns

Celebrate your team wins, celebrate work well done. We should not underestimate the impact of continuously recognising the work done by our teams, even for the simplest things.

💡 “A compliment is a selfless, timely, and well-articulated recognition of achievement.”

Compliments should come in the form of recognition that celebrates and encourages certain behaviours. They should be done in a timely manner, on the spot, the closer to the event that triggered the better. It should be well articulated, a “good job!” is not enough. Be specific on what was the act, the value and the impact it generated. And above all it should be selfless and sincere.

Say (and listen) the Hard Thing

We all hesitate when its time of giving critical feedback to someone because inevitably we can emphasise with the person receiving it. But the thing we need to acknowledge is that giving (and receiving) feedback is actually a gift. A gift that will help us be better.

When we receive or give feedback its important to understand that what we are we are being given is additional context of the impact of our actions that we were unable to perceive.

💡 “Feedback is about building trust”

The way we react when we are giving or receiving feedback is what will help us build trust with each other. As time goes and the trust strengthens you open the door better, more complex and harder feedback. Embrace it and use it to grow yourself and your team.

Everything Breaks

As the company grows the need of “A clear explanation of the rules” gets more and more important. Human relationships are complicated and without these rules things can get very chaotic. One thing we need to acknowledge is that the rules need to evolve as the company grows. The rules that were fit when you were only two people wont apply when you are 8 or 100.

Onboarding is another critical scenario where you will need to have this rules in place. Every new person added to the team should be able to understand the company’s vision, values and practices that define how it operates.

Finally you should use failures as the best tool at your disposal to grow your business. Take advantage of every failure and extract the most important lessons that address the root cause of it. Your company should have the mechanisms that allow comprehensive and blameless post-mortems where the most important thing is to learn and adapt so no failure happens twice.

The Org Chart Test

Org charts are a resource to effectively describe how your company operates, how the product is developed, who is responsible for what. These charts need to be easily discoverable and shared across the organisation. Anyone from the company should be able to draw from scratch (without adding any person’s name) describing from any perspective how the company builds its products, how the business units are split or how the reporting chain is structured. This chart should be constantly refreshed to reflect the current state of the company.

🎧Related Issues

leadingIn(tech)#12: Small things done well. Part I; taste the soup

📄Related Articles

Gossip, Rumors, and Lies – Rands in Repose

Everything Breaks – Rands in Repose

How to Recruit – Rands in Repose

Say the Hard Thing – Rands in Repose

The Blue Tape List – Rands in Repose

The Org Chart Test – Rands in Repose

💬 Would to help me build the community?

Join the LeadingIn.Tech Discord Server!

Welcome to a new issue of the leadingIn.tech newsletter. I'm Roberto, and this is a place where I share ideas, practices, learnings towards the journey of becoming a better leader in technology.

Subscribe now

This is the first issue of a series dedicated to the book The Art of Leadership: Small Things, Done Well by Michael Lopp. On issue #9 I shared an overview about the Atomic Habits book. One thing I didn’t cover in that issue is about what kind of habits can make us better leaders. Fortunately Michael Lopp in his book shares a good list of small things that we can do which will compound over time to make us better.

The book is split in three acts, the first dedicated to managers or first time managers struggling to learn about the role which will be covered in this issue. The next issues will cover Act II dedicated to Directors or managers of managers and how do lead by delegating until it hurts. Finally Act III is for Executive leaders where he shares practices to help setting the vision of the company and the culture around it.

Photo by Charles Chen on Unsplash

💡 learnings and ideas to become 1% percent better every day

📚Books

The Art of Leadership: Small Things, Done Well by Michael Lopp

What is it about?

The book is presented as a series of practices for leaders that will provide a compounding effect into helping us be better leaders.

What the key highlights?

Part I: For Managers

Meeting blur: We all know that feeling, you have been all day in meetings. By the end of the day you find your self struggling to get the context from them. This is a sign that you are over committing above your capacity to process that much information. As a leader you need to assure that you are able to deliver high quality throughput and that you are able to meet to all of your commitments. This is leading by example.

The situation: As a leader you will be often in the need to face with the situation. Situations are those things that happen that need a strategic approach to manage it and the team will look at you for managing it. As a leader there are a few questions that you should ask yourself before bringing your perspective to it.

1. Am I the right person to handle this Situation? Find who that person is.

2. Do I have complete context? If not, look for it.

3. What is the track record of my sources of information? Can it be trusted?

4. Do I understand the nature of those inconsistencies? Find that common ground.

5. Do I understand my biases relative to the Situation? Acknowledge them so you can take action to overcome them

6. Do I understand my emotional state relative to the issue at hand? Take your time to cool down if you need to or find a neutral party to help you.

7. Can I coherently explain multiple perspectives of the Situation? This will help you acknowledge the complexity of the situation.

Act Last: As a leader there are two main reasons to be the last to share your ideas in a discussion, first it will give you enough context to evolve your thinking and provide better input. Second if you are the first to provide your ideas you will be setting the tone for the conversation and probably shy away people from sharing their own thought to do not contradict you. Your job as a leader is to enable debate so the best ideas arise from confronting multiple perspectives.

Read the room: When you are part of any meeting you should be able to read the mood of the room. By reading the room you will gain context and insights about “What mood is this particular set of humans in?” which will give you the tools to best approach for you to take to maximise the value of the conversation.

Taste the soup: Your job as a leader is not to prescribe how to do things. Your job is to “taste the soup”. Based on your acquired experience you have developed the ability to identify what are the main components that build an idea. Your primary resource as a leader is your ability to ask critical questions to understand the ideas being discussed and the decisions made. This is the opportunity to exercise your curiosity. Which is the ingredient? Why did you choose A over B? Where is C? Why is it missing? etc.

Spidey-sense: As a leader you probably have built wisdom based on your experience, these experiences have helped you create your own judgment, opinions and learnings. You will probably experience similar situations again and you will be able to detect patterns from them. When you inevitably start seeing these patterns flashing saying that something might be “off” thats your “Spidey-sense” kicking in, “trust it”. Take your time, collect information, connect the dots and eventually you will be able take actions if needed.

Performance: Remember this, “It’s always performance season” for yourself or for your team. As a leader you need to have frequent touch points through the year with your team, identifying the aspects that where you can provide the necessary feedback, suggests alternative approaches and give and actionable insights. You should not wait for “Performance Season” to do so. Your primary job as a leader is to continuously ask yourself “How can I make this human better?”

🎧Related Podcast

The Art of Leadership - Interview with Michael Lopp | Supermanagers

The One About Small Things, Done Well – Rands in Repose

📄Related Articles

Act Last, Read the Room, and Taste the Soup – Rands in Repose

Q&A on the Book The Art of Leadership

The Art of Leadership, by Michael Lopp – Eric Nehrlich, Unrepentant Generalist

💬 Would to help me build the community?

Join the LeadingIn.Tech Discord Server!

Hi there! 👋🏽

Welcome to a new issue of leadingIn.tech newsletter. I'm Roberto, and this is a place where I share ideas, practices, learnings towards the journey of becoming a better leader in technology.

Photo by Javier Allegue Barros on Unsplash

Subscribe now

Today’s article is about how management styles need to change in a world where the work that is repeatable, that can be automated and where technology is continuously substituting work previously done by humans. As this happens a new kind of challenges arise to be solved and the classical styles of management around “planning, organising, staffing, directing, and controlling.” are no longer suit.

The management styles needs to change to enable people to experiment and solve these challenges in a safe environment as Simon Sinek refers to in his book Leaders Eat Last, to create a Circle of Safety.

💡 learnings and ideas to become 1% percent better every day

📄 Articles

The Role of a Manager Has to Change in 5 Key Ways

What is it about?

This article reflects on the trend that is ongoing from a few years already on how leadership behaviours from management positions are changing or need to change from a command-control style towards a team empowering environment. It describes how managers can change in 5 ways, actually they mention 6 ways; from directive to instructive, from restrictive to expansive, from exclusive to inclusive, from repetitive to innovative, from problem solving to challenging, and from employer to entrepreneur.

💡 “Be people who love to learn and love to teach, who liberate and innovate, who include others in the process of thinking imaginatively, and who challenge everyone around them”

What are the key take aways?

• Move from Directive to Instructive, tasks that are repetitive and being able to be reproduced in a procedural form can eventually be replaced by technology and AI. We need to change in a way we encourage people to extend their knowledge and learn through experimentation.

  

• Move from Restrictive to expansive, forget about micromanagement and making all decisions. We need to encourage our teams to take part in the decision process and develop their own judgement.

  

• Move from Exclusive to inclusive, when a single person drives the decisions it limits the actions to the mental model of that person. We need to be able to bring multiple perspectives that enrich the context of the challenges faced and brings alternative solutions to the table.

  

• Move from Repetitive to innovative, if we focus only in predictability and existing systems performance innovation halts. We should create space for innovation to happen, give room for experimentation and learning from failures.

  

• Go beyond Problem solver to challenger, we need to be careful of not staying in the “putting out fires” mode of problems that arise from day to day operation. Some problems are not evident and we need to challenge our people to discover them and find ways to overcome them.

  

• Change the mindset from Employer to entrepreneur, as time passes and organisations mature some leave behind this mindset in favor of less risk taking behaviours, resulting in teams that just follow stablished proceses to meet managements goals. But as the article states “being entrepreneurial is a mode of thinking” where survival of the organisation is about risk taking and putting emphasis on your customer and innovating for them.

  

📄Related articles

Google Tried to Prove Managers Don't Matter. Instead, It Discovered 10 Traits of the Very Best Ones | Inc.com

📚Related books

Turn the Ship Around!: A True Story of Turning Followers into Leaders by L. David Marquet | Goodreads

Leaders Eat Last by Simon Sinek | Goodreads

✉️Related issues

LeadingIn Tech #5: Managing your upstream communication

LeadingIn.Tech #2: What does an Engineering Manager do anyway?

Bonus

Simon Sinek talk about “Leaders Eat Last”

💬 Would you help me build the community?

Join the LeadingIn.Tech Discord Server!

Welcome to a new issue of leadingIn.tech newsletter. I'm Roberto, and this is a place where I share ideas, practices, learnings towards the journey of becoming a better leader.

Today’s article is about that activity that we terribly suck at performing but we still need to do anyway to get things done, and that’s estimating when we will complete a task or a project. You will probably find that this might be a recurring topic in the newsletter, but that’s just because of my awareness of how much I suck at it.

Subscribe now

Photo by Wilhelm Gunkel on Unsplash

💡 learnings and ideas to become 1% percent better every day

📄 Articles

📄[comic] The Planning Fallacy: Why We're Terrible at Setting Realistic Deadlines

What is it about?

The article(plus a comic) describes our pattern of not being able to set realistic deadlines to a task despite having done similar ones in the pasta. Even if we suck at setting them, there are benefits to perform this activity as it pushes us to pursue the completion of the tasks based on the way our brains react to time sensitive constraints.

💡 “We can’t meet deadlines, but we can’t get anything done without them (see the Mere Urgency Effect)”

The downside is that deadlines that are too unrealistic have a negative effect work as they generate unnecessary stress and they hurt our trust with peers and stakeholders when we are unable to meet them. In the this post from the Doist team they some strategies that can help us mitigate these risks.

What are the key take aways?

To mitigate the impact of not being able to accurately estimate the time to complete a project or a task, we can follow these 5 simple strategies:

• Break down the problem into smaller parts and estimate them individually.

• Add buffer to your schedule, assume you will only dedicate a fraction of the available time to complete it. This will give you extra time if things start to delay, as it mostly happens, specially on environments of high ambiguity and complexity.

• Use similar tasks done in the past to compare with your estimations of the current task, the more historical data the better.

• Reduce the scope of what you are trying to accomplish, optimise for quality over quantity.

• If none of the strategies above are enough, communicate early and often the obstacles that appear in your way.

📄 Related Articles

The Art of ETA. How to give precise development time… | by Dana Yudelevich | Level Up Coding

Agile Estimation: Why The Fibonacci Sequence Works

🎬Related videos

How to estimate as as an engineering leader | LeadDev

✉️Related issues

LeadingIn Tech #6: Estimated Time of Arrival Panic

💬 Would you help me build the community?

Join the LeadingIn.Tech Discord Server!

Welcome to a new issue of leadingIn.tech newsletter. I'm Roberto, and this is a place where I share ideas, practices, learnings towards the journey of becoming better leaders.

Photo by Jeremy Bishop on Unsplash

As this is my first issue of 2022 I want to start this “new season” by doing it a bit differently. Last year one of my biggest challenges was to choose a theme that I could feel confident to write about in a more elaborate way but the procrastinator in me turned that into taking months before publishing anything.

To help improve the cadence of releasing news issues. I'll simplify them by turning it into a weekly issue having a leading bits section where I’ll share some learnings and ideas that can be consumed in a light form. The contents will also help feed the resources database I continuously curate as part the leadingin.tech toolkit which is also the main reason of why this newsletter exists after all. Please, take this issue as a pilot that will be subject to improvement over time.

Subscribe now

💡 learnings and ideas to become 1% percent better every day

📚Books

Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear

Honestly I don’t know why it took me so long to finally read this book, or listen in my case. I couldn’t recommend it enough if you haven’t read it yet. It’s for sure a source of inspiration to help me find mechanisms to self improve either personally or as a leader.

What it is about?

Atomic Habits is the definitive toolkit that gives you a framework for growth on your personal or professional life by thanks to a continuous improvement system by setting in place the right habits that will lead you to achieve your goals.

What are the key take aways?

The compounding effects of small and continuous improvements is one of the main takeaways from the book. The book gives you a framework not only for creating good habits but also for breaking bad ones as two faces of the same coin.

Creating a good habit:

1. Make it obvious: Make your habit trigger unconsciously, optimise your environment so the habit is obvious for you to do it.

2. Make it attractive: Make your habit rewarding, use the gratification of completing the task to motivate you to keep doing it. Bundle the habit with another satisfying activity.

3. Make it easy: Reduce as much as possible the friction that makes you start the habit, once you have started you have achieved the most difficult part and you will likely continue.

4. Make it satisfying: Reward yourself for completing your task, make sure the reward is aligned with your long term goal. Track your progress, the fact of visualising your streak gives triggers the satisfaction of achievement. Don’t break the chain.

Breaking a bad habit:

1. Make it invisible: Make it difficult to start a bad habit, hide the cues that trigger them (e.g: uninstall your most used social network app)

2. Make it unattractive: Do the exercise of how the habit is pushing you away from your goal.

3. Make it difficult: Add as much friction as possible, add barriers so the lazy in you will skip the habit

4. Make it unsatisfying: Make yourself accountable for doing it, add a painful cost so you think twice before falling into the bad habit.

Extra:

Here is also a really great video summary of the book

Thank you for reading this far and I hope you have enjoyed this edition, see you next week with another issue.

💬 Would you like to help me build the community?

Join the LeadingIn.Tech Discord Server!

Photo by Patrick Schneider on Unsplash

Hi there!

Welcome to another edition of the LeadingIn.Tech newsletter.

It's been 6 months since I last wrote to this newsletter, and now that we are in December and this is the time of the year where people start crafting their new year resolutions by looking at how their year went and what they would like to change the year after. New years resolutions are an exercise people do to evaluate what aspects of their lives they want to change and plan for it to try to improve their lives. In the software development world this is known as Retrospectives.

Off-topic: December it's also the time of the year when Spotify releases their Wrapped compilation of your year listening music. Here is "My Audio Aura" if you haven't seen enough yet.

Back to the topic. According to the Principles behind the Agile Manifesto teams are expected to frequently run the exercise to stop and look back to review and reflect on what can be improved.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

There are two main differences between a new years resolution and a retrospective. The first one is that unlike those good intended resolutions to "Eat healthier" or "Do more exercise" retrospectives are expected to generate actionable tasks for the team to improve their process with clear owners. The second difference is the cadence, retrospectives are supposed to be frequent and at a regular intervals, ideally if not always they should be done immediately after every team iteration.

The problem with retrospectives happening with a cadence of every few weeks (or less) is that if you are not creative on how to run them it can become a very monotonous routine that will make it difficult to collect valuable insights to act upon.

On this edition of the newsletter I would like to focus on my take on how I run them with my teams to keep them engaged. The idea is to give the team a variety of retrospective setups based on recent context to encourage participation and collecting insights from different perspectives. To achieve it I'm going to detail 6 different retrospective activities that I've picked as my favourites and that I selectively use them depending on the moment or the kind of outputs I expect for every session. Let's go through them.

Team Radar

When:

This is the activity I run with less frequency because the changes you can compile for this session could take longer to generate a visible impact. That's why I usually run them twice a year or when landing to a new team where I want to get a temperature check of the team health.

Expected Outcome:

This retrospective pretends to collect a general overview of the team perception on a set of 5 (or more) dimensions such as:Team, Process, Requirements, Collaboration with external teams, Tools. As a result you will generate a visual to show the team where they stand strong and what areas need to be looked at. By asking additional probing questions on this areas the team creates action items to improve the areas where the team is not happy with the current situation

How it works:

The team vote with an emoji for each of the dimensions, in the end all points get aggregated for each and represented in a radar chart (ideally) . This will show to the team a visual on what are the strengths and weaknesses to put focus on. Finally triggering a conversation on how to tackle on the weakest points and how to double down on the strengths.

😃 (happy= 2 points), 😐 (neutral = 1 point), 😞 (sad = 0 points)

Radar Axis:

• Team: Collaboration, mood.

• Process: Methodologies, mechanisms, organization

• Requirements: Clarity of requirements, goal alignment

• Other teams: Collaboration and cooperation with other teams and stakeholders

• Tools: Tools necessary to work, automation, ease of use, productivity

The end result might look like something like this:

Image: The first Team Radar retrospective when I joined my current team.

Or simply put in a table:

What Went Well, What We’d Like To Improve, What Went badly

When

This is the most common activity as it is the simplest when you are running multiple iterations for a long term project. This activity can be done usually after a sprint or a project is completed.

Expected Outcome

This activity aims to get the team to be vocally self critical on the things that did not work as expected and then gather learnings that can be used to create mechanisms to prevent them from happening in future instances. The focus is on detecting opportunities for improvements in team processes specially if they are recently implemented and you want to collect feedback to improve it.

How it works

Starting with a board with a column for each input type Went Well, To Improve and Went Badly The team takes a few minutes (10-15min) to enter their inputs on each. Afterwards initiates a discussion of the things that went well and why, this is also a as good opportunity to give kudos to peers. From the To Improve column the team collects info about things that are ok but can be made better. Finally the on the Went Badly column where the discussion is oriented on identifying the root causes of what things did not work as expected and find mechanisms to prevent them from happening again.

Three Little Pigs

When

The Three Little Pigs is one of my favourite retrospective activities, its particularly useful after a new project has been in production for a few iterations and you want to identify risks and weak points. It can also help as a post-mortem for moments when system resilience is affected generally after a spike on production incidents or system failures. This activity is a perfect fit for identifying technical debt.

Expected Outcome

The overall expectation to detect technical/operational debt and latent risks that need to be tackled promptly before they can produce real impact to your customers in production. This activity can generate the need to plan for improving the system architecture or refactoring weak points.

How it works

The team identifies what things are just about to break imminently, what things are working but could potentially generate issues if certain conditions are met (e.g: load increases) and finally what things are rock solid that the team is proud of. Then a discussion is triggered on what are the risks and what needs to be fixed to address them. Also It serves as a good opportunity for the team to celebrate those parts that are rock solid and the team is proud to mention.

House of straw – what are those imminent risks that are hanging from a thread that could break everything.

House of sticks – what are those things that are working fine today but we should not overlook because it could generate issues if conditions changes.

House of bricks – what do we consider to be rock solid and resilient enough to changing conditions?

4Ls

When

The 4L is an activity that I like to use after iterations where either because we made an interesting discovery or we learned something new from making a mistake. Also its an interesting activity to focus on the things we liked about how things went and think or visualise an ideal long term accomplishment.

Expected Outcome

The purpose of this retrospective activity is to document learnings after a sprint or a project has been completed specially on situations when the team discovered something novel, learned from obstacles found in the process, lacked something that was expected to happen, or longed for the existence of something that could have made things a lot better.

How it works

Similar to other activities the team starts with a board with a column for each input type, Liked, Learned, Lacked and Longed for. Then they take some minutes to reflect on each theme. The moderator puts special focus on having the team to think about the things that they enjoyed (Liked) and learned something new (Learned). And things where they learned from an issue (Learned) and they felt that something that was missing could have helped address the issue (Lacked). Finally having the team thinking about an ideal state of something that could improve the team productivity (Longed for).

Start, Stop, Continue

When

This retrospective activity is specially useful for young teams that are still trying to define their set of internal processes.

Expected Outcome

The expected outcome is to identify the right set of team processes for the team to operate, identify which ones are missing, which ones are not adding any value or slow down the team and which ones the team is happy with and should keep/improve. At the end of this activity there will be processes that will be deprecated and new ones be trialed for the next iterations together with improvements to existing ones.

How it works

The team collects for each column which processes or activities the team need to start doing to improve in an area, then the ones that are unnecessary or inefficient that need to be stopped. Finally collect the ones that the team is happy with and wish to double down.

The SailBoat

When

For long running projects the Sailboat activity is a very interesting one to collect insights on the team about how confident they feel about completing it successfully. Specially to identify what are the main risks of the project and what things are slowing down the team.

Expected Outcome

The expectation of this activity is to have the team reflect on what are the potential risks and obstacles that can compromise the team's ability to successfully reach their goals. Then having a discussion on how to mitigate those risks and remove obstacles.

How it works

The Sailboat activity is performed as a metaphor of the team (The boat) navigating towards their goals (The island). During the team's journey the team might encounter risks (Rocks) that can impede the team from reaching their goals. Also, there can be present handicaps or inefficiencies that can slow the team (Anchor) and prevent the team from reaching their goals within schedule. Finally the team can also reflect on what are the things that keep them moving forward (Wind) and what makes them enjoy the journey (Sun)

'Wrapping' up

Here it is a quick summary of a very subjective view of how I choose what retro activity to run in each retrospective depending on the kind of inputs I'm interested in collecting from the team. The expectation is to use them to gather relevant information from the team, identify needed changes.

One more thing.

Please keep in mind that retrospectives are not only a place to learn from the obstacles but also its an opportunity to celebrate the team accomplishments. And specially that the team receives the well deserved recognition from their contributions.

Finally, we need to make sure that on every iteration we put emphasis on how the team is improving compared to previous iterations. To make this happen have to commit to the action items identified on each of the sessions with clear owners and S.M.A.R.T. goals

S=Specific, M=Measurable, A=Actionable, R=Relevant, T=Time-Based

More on goals probably on a next newsletter.

Subscribe now

💬 Join the conversation

Join the LeadingIn.Tech Discord Server!

📄 Articles added recently

Equity 101 for Software Engineers at Big Tech and Startups - The Pragmatic Engineer

Experimentation principles. Empower employees to rapidly test… | by Nis Frome

How deadline-driven behavior sends your Scrum Teams spinning out of control | by Todd Lankford

How Many People Can Someone Lead?

How to Achieve Sustainable Remote Work | The New Yorker

Software Engineers Growth framework

Startups need to stop dividing tech and product. Hire a CPTO | Sifted

The GitLab Test — 12 Steps to Better Remote

What does my engineering manager do all day? | by Joon Park

Why it’s difficult to build teams in high growth organisations | by Jason Yip

📖 Books

Rewarding Talent | Index Ventures

🎧 Podcasts

How to Hire Entrepreneurial Engineers and Why You Need Them

Scaling Your Team and Product: Leadership Stories from Product Hunt

🎬 Videos

How to run a better retro

🧰Other toolkits

LappleApple/awesome-leading-and-managing: Awesome List of resources on leading people and being a manager. Geared toward tech, but potentially useful to anyone.

Photo by Emile Perron on Unsplash

Subscribe now

Hi there!

Welcome to the new edition of the LeadingIn.Tech newsletter.

Now that we are done with the first half of 2021 we are getting into what it might feel like a peak season of tech (or non necessarily tech) companies hunting and competing for the best talent of software development family roles. It's no secret that the demand is significantly higher than the offer available. Still many companies spend too much energy on finding the best programmers, that know the latest frameworks or worked with the latest technology leaving behind some high potential candidates because they didn't tick all the boxes in the assessments.

Let me first step back and try to dissect what I actually mean when trying to find the right talent. To do so let's use the concept of Working Backwards as the process solving a customer problem or need starting by imagining what is the experience we want to deliver and then work backwards to figure out how and what will be built. Werner Vogels wrote about this process in 2006 in his blog All Things Distributed where he described it in 4 steps:

1. A Press Release

2. Frequently Asked Questions document

3. A description of the customer experience

4. The User Manual

A Press Release

"The press release describes in a simple way what the product does and why it exists - what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product - not just how we think about it internally."

Understanding that writing a press release is the exercise of setting the vision and imagine how a product launch will look like and be advertised to the customers. The importance of this exercise is to help the team visualise the value being delivered and identify WHY we want to build such products and also understand whether it should even be built at all. The Senior Engineers in your team should be able to set a long term vision for the product and technology but also identify the technological challenges to materialise it. Being able to communicate this vision in a language the easy to understand is also a valuable asset for any engineer in a leadership position.

Frequently Asked Questions

"It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have."

Building a product is not only about what it can do and what problems does it solve but also is about how you solve those problems, how the value being added is perceived from the customers viewpoint. As engineers working in a project being able to understand the importance on how your users will interact and understand the features of the product being delivered is a crucial aspect for the product's success. This part of the exercise also helps the team to identify what parts of the solution will need refinement. It's also a good space to address on the tradeoffs made and setting alternative solutions to address customers concerns.

A description of the customer experience

"Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product."

Reaching this point being able to detail the customer experience and the use cases is an aspect every engineer needs to work on with a lot of attention to details, thinking about not only the expected happy path but also the behaviour of the product when something fails. Being able to detail and be a few steps ahead of potential issues when designing technological solutions is required for ensuring high quality products that reduce frustration for their users.

The User Manual

"The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product."

Finally being able to write proper user manuals is what helps products grow and scale by allowing the customers learn by themselves how the product is used and what steps they need to execute in order to achieve their objectives. Making more effective the adoption of the usage of the product. Writing good documentation unlocks the team to continue to work on improving the product rather than giving first hand support to their customers, which in results makes the whole product development scalable.

How is this related to finding the right talent for your team?

In past editions I've talked about building teams that can outlive their original members by focusing your company's vision and its reason to exist.

While this time its intentional that in a post related to finding talent for software development teams I've talked very little about technical related traits. I've used the Working Backwards process to highlight the importance to "Start with customer experience and work backwards to the technology" because in the end it's all about solving problems for people and helping them understand how you are trying to solve their problem.

Finding the right talent for your company is more about finding the people that is able to work on solving the problems for your customers. Of course having solid technical skills is vital for being successful in a software development role but the ones that take the most advantage of their talent are the ones that use them to solve real customer problems.

The right talent for your team will be able to identify your customer pain points, set a vision on how they want to address the problem while making the right tradeoffs. They will be able to detail a plan to execute it and deliver a robust solution. They will also be able to communicate effectively. The right talent for your team is also a force multiplier that creates an environment that facilitate others to participate and help evolve the product.

The right talent for your team will start with people’s problem and work backwards to find the right technology for it. Having this foundations will give the tools to your team to make the right choices in terms of technology. They’ll be able decide what is the best tool, language, framework, design pattern or database technology to serve your customers. These are the tools that they'll use to serve the mission of the company.

As technology evolves faster than most of us are able to catch up. What it is important when finding the right talent for your company is to look for those that are able to understand the technology, have solid foundational knowledge and able to quickly adapt and learn new ones when needed while still being able to understand that in the end its all about the customer experience.

• For extra points, see below: "An incomplete list of skills senior engineers need, beyond coding" by Camille Fournier (@skamille):

  1. How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it

  2. How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time

  3. How to mentor an early-career teammate, a mid-career engineer, a new manager who needs technical advice

  4. How to indulge a senior manager who wants to talk about technical stuff that they don’t really understand, without rolling your eyes or making them feel stupid

  5. How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it

  6. How to influence another team to use your solution instead of writing their own

  7. How to get another engineer to do something for you by asking for help in a way that makes them feel appreciated

  8. How to lead a project even though you don’t manage any of the people working on the project

  9. How to get other engineers to listen to your ideas without making them feel threatened

  10. How to listen to other engineers’ ideas without feeling threatened

  11. How to give up your baby, that project that you built into something great, so you can do something else

  12. How to teach another engineer to care about that thing you really care about (operations, correctness, testing, code quality, performance, simplicity, etc)

  13. How to communicate project status to stakeholders

  14. How to convince management that they need to invest in a non-trivial technical project

  15. How to build software while delivering incremental value in the process

  16. How to craft a project proposal, socialize it, and get buy-in to execute it

  17. How to repeat yourself enough that people start to listen

  18. How to pick your battles

  19. How to help someone get promoted

  20. How to get information about what’s really happening (how to gossip, how to network)

  21. How to find interesting work on your own, instead of waiting for someone to bring it to you

  22. How to tell someone they’re wrong without making them feel ashamed

  23. How to take negative feedback gracefully

"Love people, use things. The opposite never works"

💬 Join the conversation

LeadingIn.Tech Discord Server

Leave a comment

📄 Related articles

Working Backwards

¿De verdad hay escasez de developers o los empleadores no saben contratar?

📄 Other articles added recently

Managing meetings without succumbing to Zoom fatigue

Stop Fearing Critical Feedback — Fear Not Getting It Instead

Technology Saves the World - Future

The 25 Micro-Habits of High-Impact Managers

The Engineering Leader’s Guide to Crafting a Personal Brand that Stands Out From the Crowd

📖 Books

Working Backwards: Insights, Stories, and Secrets from Inside Amazon

🎧 Podcasts

One CEO's vision for a remote, asynchronous future of work

Photo by Matthew Smith on Unsplash

Hi there!

This is the Issue #6 of the LeadingIn.Tech email. There are few things that scare me more than giving ETA's to stakeholders. I'm talking about "Estimated Time of Arrival" a term often used in software development to ask for the effort or the date for when a given task or project will be completed.

I must confess that whenever I get asked things like "Can you give me an ETA for when X will be done?" I enter in panic mode and all sorts of insecurities arise because deeply inside I know how complex the calculation of such response can get. On this edition I'll go through some common pitfalls that should be avoided to overcome the panic and give the best possible response you can give.

Source: https://xkcd.com/1658/

Subscribe now

Never let your first answer be an actual date

STOP! It doesn't matter how you confident you feel, or how much experience you have. Never ever say the first date that comes to your mind. It will be wrong, period.

It is very likely that you don't have all the context of the ask and that there are a quite few dependencies you haven't even had time to think of.

Even if you will take the time revisit your answer before giving your final answer just avoid saying it just yet. Chances are that the offset can be big enough to hurt your credibility and raise a lot of questions on why is there such a difference from your original date. So do yourself a favour and hold it.

There are no extra points for optimism

Now, you might think that you or your team is experienced enough to be able to accurately estimate the efforts for the ask, and yes actually the effort might be somehow accurate. But efforts do not map directly to ETA's.

The universe is full of entropy and your project plan is not free of it either. Being too optimistic is the same as ignoring this which impacts your capacity to be accurate when giving your estimates. So make sure you add your Entropy value to whatever estimation you do. Just for fun let's use S as a wink to the Boltzmann's entropy formula

This entropy value will depend on the size or your organisation. I'll change depending on the complexity of the project or the dependencies across different teams or even multiple companies you need to complete the work. Larger organisations have more complex systems, dependencies get affected by other project plans, external companies will affect you with other environmental causes. As you can imagine any of these circumstances will make your entropy even larger.

You will need to find what is the best value of S for your project, team, organisation or company. A common known rule of thumb is that S = 1.3 which means that your ETA should be 30% further away than your best estimate. This number could go up or down depending on these many factors.

Now let's give a funny name to our equation for the final ETA you will be giving to your stakeholders, let's name it f(eta). Given that t is the time on when you plan to start, S your environmental entropy and eta your best guess estimation. The first equation will look like this.

Don't let your assumptions fool you

But this formula seems too simple for what happens in reality. When planning a task or a project, it's easy to rush on assumptions and create plans according to those. This is another factor that might delay your actual completion date if along the way you discover that they were wrong. I would encourage you to make those assumptions as explicit as possible and have them written down and discussed with your stakeholders. One way of doing that is by providing a comprehensive Frequently Asked Questions (FAQ) to the input specs. That will not only help you, but the stakeholders to understand what the final solution will consider and what not. If you managed to clear as many assumptions as possible you might still want to get the ratio of how many assumptions are you making compared to your actual requirements and specifications and add it to the equation, let's call this ratio A.

Divide and conquer

Now that you have a listed a detailed set of requirements, you are understanding better the problem and the work that needs to be done to complete the task. At this stage software development teams need to work on breaking the problem into the most atomic parts and start building a design that will satisfy all of the requirements. Each of this parts can be estimated individually and the aggregation of all will give you combined effort towards giving a completion date.

One of the advantages of dividing into smaller parts is that you can individually assign Entropy and Assumptions values to each part which will help you be more accurate in your individual estimations. This is also useful when splitting larger projects in a set of milestones that can be delivered individually.

For the sake of time and not to make this post too long I'll stop adding complexity to the equation by adding time allocation, parallelisation of tasks, dependency trees, or just simply team capacity to the mix. You can imagine now what I meant at the beginning of this text when I said that I used to enter in panic when being asked to give ETA's. Does this equation look similar to your current thought process?

Communicate your final ETA

It's now time to share your detailed plan and your f(eta)'s. This is your opportunity to show how and when are you planning to complete the ask and what specific problems will your deliverables solve. A detailed plan is helpful for driving conversations where what it seems to be a far away date its actually the result of a well thought process that produces better and more accurate estimations. When communicating ETA's you'll need to make sure that all the risks and their mitigation plans are included.

Is it a forecast or a commitment?

This is it, you have given a date. Now another tricky question comes to place "Is this a commitment?" The short answer is no, ETA's are not a deadlines until someone or something makes it so. Deadlines can take the form of marketing campaigns, public release dates or any other time sensitive factor that requires your partner teams to plan ahead and create ripple effects across the organisation if any of the dates are not met and potentially end up hurting your business or your customers.

Remember to be aware that by giving ETA's they'll be used as inputs for your stakeholders who will make plans based on them. This means that by giving accurate estimates and delivering accordingly you are helping reduce the overall entropy for your organisation and your team.

Wrapping up

Next time you need to provide an ETA remember this checklist for you to run when working on estimating ETA's before you give a response:

• What is the value of entropy you will use?

• Do you have a detailed list of requirements?

• How many assumptions are you making?

• Have you split the problem in its most atomic form?

• Have you estimated each part separately?

• Are you planning on having intermediate milestones?

• Communicate the plan together with risks and mitigation plans.

• Have everyone to align on wether the ETA represents a commitment or is for forecast purposes only

💬 Join the conversation

💡 New this month!

I'm excited to announce I've created a discord server and I'm inviting you to join me in the conversation. There you'll find regular updates on whats happening in LeadingIn.Tech and open the door for sharing discussions about leadership and technology.

Be the first to join! See you there... Join the LeadingIn.Tech Discord Server!

Leave a comment

📄 Articles that inspired this post:

📄 Agile Estimation: Why The Fibonacci Sequence Works

📄 The Art of ETA. How to give precise development time… | by Dana Yudelevich | Level Up Coding

📄 Other articles added this month:

📄 Debugging engineering teams: Groundhog Day | LeadDev

📄 How to be Remote-First When You Still Have an Office

📄 How you're causing low employee morale at your company

📄 TBM 20/52: A Product Super-Skill (Balancing Divergence and Convergence) Ten things you need to know before making a build vs. buy decision

📄 The eight flavors of engineering management | LeadDev

🎬 Videos

🎬 Creating and sustaining motivation in engineering teams | LeadDev

Photo by Brandon on Unsplash

Hi there!

Welcome to the new edition of the LeadingIn.Tech newsletter.

As an Engineering Manager one of my biggest challenges as a technology leader is when I need to communicate upwards in the command chain. It is a lot easier for me to communicate with technical peers than to stakeholders up in the management chain. I'll be sharing in this edition some insights on what I've found when looking for best practices for managing stakeholder communication.

Depending on the company size. Senior managers, directors, VP or C-Level need to process tons of information on a daily basis and the higher in the chain the amount gets even bigger. Senior leadership rely on easy-to-scan, concise, timely and actionable information to efficiently manage their organisations. Here is why it is critical for technology leaders to learn how to effectively communicate upwards.

Subscribe now

Easy-to-scan and concise

Scanning through emails and documents can be an exhausting activity so making it easy for the reader to identify the important parts of the content is critical to help them prioritise their attention. Amazon is a well known company for their writing culture. Danny Sheridan in his blog factoftheday1.com recently published his post "Write like an Amazonian" where he summarises in only 5 points the most important practices of the writing culture.

Making things easy-to-scan means that the information can be extracted with little effort. Using few words, reduces amount of time it gets to read the doc. Replacing adjetives and weasel words with data avoids the need for follow up questions such as "how much is much higher?" which is inefficient. Removing unnecessary paragraphs you avoid directing the attention to non-relevant information. And finally while answering questions be direct when answering, if additional data is needed then provide it, this way the reader can decide wether to continue reading if they need additional clarifications about the answer.

Timely and actionable

Keeping your stakeholders on page is critical for earning trust for you and your team. Status reports can feel like a tedious job but a very necessary one. Specially if they are delivered even before you get asked for it. For this it's important to understand what your manager and stakeholders goals are. This will help you understand how your work relates to theirs and what and when the information is relevant to them. Being timely means that the information is available early enough so actions can be planned and taken with enough room. It also means that it is predictable when you will be providing it.

Making information available in a timely manner means also delivering bad news while there is still room to correct the course. If you are delivering bad news it is important to share the right amount of context to understand what was the miss about and how it will be solved. Remember, always bring solutions upfront. Here are some questions to guide you in delivering the bad news:

• What is the miss about?

• What is the customer/business impact?

• Could have been avoided?

• What is the mitigation plan?

• Have you considered other alternatives?

• What did we learn?

• How will we prevent this from happening in the future?

There are also times where you need your leaders and stakeholders to take action. Could be for calling for a decision or requesting an approval. Jehad Affoneh In the twitter thread below and also in his post Making the case to decision makers: the presentation format to follow he summarises the how you can provide information in a format that will help decision makers take action effectively.

1. Start with the conclusion.

2. What’s the problem you’re solving and why does it matter?

3. What are we currently doing about this problem?

4. What are our competitors or industry leaders doing?

5. What’s your solution?

6. What’s the cost of doing it?

7. What’s the cost of inaction?

8. What’s a high level execution plan?

9. What’s your call to action? This is generally a repeat of #1.

Wrapping-up

• Use simple language

• Provide data

• Be concise

• Communicate proactively

• Be predictable

• Anticipate to your stakeholders needs

• Share solutions/conclusions upfront

• Share context

Articles that inspired this issue:

3 problems with managing up

7 Steps to Manage Up Effectively at Work | Fellow.app

9 Expert Tips for Managing Up at Work from Real Leaders

A Tactical Guide to Managing Up: 30 Tips from the Smartest People We Know | First Round Review

Good Writing as an Essential Leadership Skill

How to Manage Up at Work - WSJ

Is managing up a bad thing? | Lara Hogan

Making the case to decision makers: the presentation format to follow

The importance of effective status reports | LeadDev

The science of managing up | Slack

What Everyone Should Know About Managing Up

Write Like an Amazonian

Writing Tips for Remote Workers (And Everyone Else)

Why Managing Up Is A Skill Set You Need

Other articles recently added

Atlassian Announces Its Shift To Distributed-First Policy | Hacker Noon

La evolución del recruitment tecnológico en España | Talento IT Blog

The Role of a Manager Has to Change in 5 Key Ways

The Role of Tech Leads and Engineering Managers 👑 - Refactoring

Transparent Salaries | Buffer

🎧 Podcasts

#85 Juegos infinitos: primeras frases, Mario y Fray Perico y su borrico - Jaime Rodríguez de Santiago

🧰 Other Toolkits

GitHub - kuchin/awesome-cto: A curated and opinionated list of resources for Chief Technology Officers, with the emphasis on startups

Staying Connected – Resilience at Work | Microsoft

Photo by Braden Collum on Unsplash

Hi there!

Welcome to the fourth edition of the LeadingIn.Tech email. On this opportunity I will be sharing some thoughts on building teams that outlive their original members.

In the past edition I've talked about Resilience and how to it creates organisations that are better prepared to endure difficult times. If you are a leader in technology you will already know that 🔍Hiring is a fundamental part of creating a strong company culture that will help the ones that are part of the company work together towards a common cause. A culture that will live longer than the time their initial members stay in the company and that is resilient enough to adapt itself, endure hard times and thrive when there is tail wind to push them forward. This is what Simon Sinek describes as having an Infinite Mindset in his book The Infinite Game by Simon Sinek

Now, let's use a hypothetical job description to elaborate this idea and imagine for a moment that LeadingIn.Tech is a company and is hiring a Software Engineer to build the "content discovery tools" for the toolkit.

Subscribe now

Title

Software Engineer - Toolkit Content Discovery, EMEA Remote

This title is simple but its giving some bits of initial information to the candidate that is navigating through hundreds of similar offers, "Software Engineering" is the role, but is generic enough not to filter out candidates that have background with different programming languages than your company is currently using. Instead if you hire by looking for "NodeJs Developer" you will be locking yourself to the short term goal of hiring for an specific programming language skill when the best approach would be to be looking to hire someone that is capable of solving software engineering problems independently of the technology they use and capable to learn new ones as needed.

The second part of the title says "Toolkit Content Discovery" this gives a hint on what team they'll be and what role it plays as part of the company’s mission. This also shows how the company's organisation is structured in a way that each team owns important parts of that mission so they can easily reflect themselves every time a new milestone is achieved

Last but not least, "EMEA Remote" refers to where this position is to be filled. In this case is for a remote job (just because I love 🌐Remote) with preference for Europe and Middle East regions, let's imagine that the reason for it on this example is to be closer to the EMEA customer audience who might have specific needs.

A vision

At LeadingIn.Tech we believe great leaders are the north star that inspire others to achieve great things together. We want to empower them with the right tools so that they get access to everything they need to unlock all of their potential and of their teams.

A job description very commonly would begin with the company's mission statement. This provides the reason of existence of the company. What are theirs long term goals and what problems are they trying to solve for the future. Having a strong vision is a key part on having an infinite mindset. When hiring, leaders should be looking for people that share the same passion for pursuing the vision. This sections is the opportunity to connect with the people that have the same intrinsic motivations to solve the same problems you are trying to solve.

The product

At LeadingIn.Tech we aim to build the most comprehensive toolkit for leaders in technology and provide them the necessary resources to help them grow and better lead their teams. We know every leader have different needs, thats why at the Content Discovery Team we provide solutions that will facilitate access to relevant context according to their company size, location, development stage, their position or their personal background. At the Toolkit Content Discovery team we build tools to allow them find and discover the right content at the right time.

This section helps the candidate understand how the company and the team they'll be joining will contribute to the long term vision of the company. It'll also help them understand how the company is organised as in our hypothetical position where the candidate can guess that the team owns the end to end experience to let leaders in technology find the content they need that is best adapted to their circumstances. They can also infer from it that they will be working in a rich multidisciplinary team that is empowered to reach their goals.

The role

We are looking for a software engineer to work on the of the end to end development of the experience of Content Discovery, from data ingestion, classification and discoverability. You will:

• Work on a multidisciplinary team delivering impactful projects.

• Lead design and execution of the projects providing high quality solutions.

• Improve performance, stability, scalability and reliability of the services.

• Produce simple and maintainable code as part as a continuous improvement process.

The role section describes the scope of responsibilities and and the expectations of the position. This targets to know about the current needs for the organisation and set a starting point for the candidate to get a first contact on what the actual job is about. What practices and organisational approaches the company follow. This is a great opportunity to describe how great is the opportunity or the challenge ahead is.

The who

The ideal candidate will:

• Have passion for sharing knowledge and helping others grow professionally

• Have previous professional experience in the software development industry

• Good English communicator and optionally in Spanish

• Self-motivated and able to work in autonomy with great organisational skills

• Experience in developing software with two or more programming languages (Java, Kotlin, Javascript, Ruby, etc.)

• Able to work in agile iterative environments with short feedback loops

• Can navigate through ambiguity to provide solutions that will delight our customers*

Now here is where you describe your ideal candidate. Here you'll need to make sure to be describing what it's really important for the candidate to have in order to be successful at the company not just the position he's applying for. You want to describe the behaviours that better describe your company culture. And remember you are not looking for the perfect candidate that ticks all the boxes. You are looking to the best possible candidate that will share passion, that is prepared enough to fill the role and that it has the potential to grow and help others grow with them.

Bonus points

Some skills or knowledge that will help you onboard faster in the role but are not mandatory:

• You are familiar with no-code/low-code platforms and able to automate tasks to generate, organise and deliver content. (Some stuff we use: Notion, Substack, Cloudflare, Zapier, Typeform)

• You have web development experience with HTML5/CSS3

• You have strong knowledge in Javascript and NodeJs

So you can't avoid dropping names of your tech stack right? Now it's the time to brag about the shiny new tech that your company is using and it might give some bonus points to the candidate if they are familiar with them.

Just make sure this is not an unrealistic list of brand new technologies where you ask for years of experience in some framework that was just out a few months ago.

Conclusion

Going back to the theme of this issue, to build teams that outlive you. It all starts in understanding why your company exists, what is the mission and put that into the core of every decision your company makes, and yes even when writing a job posting. As you can see, from the previous dissection of our hypothetical posting by navigating from top to down you'll notice where the priorities are.

The way you communicate what are your priorities is important to bring in the right people for your company, people that share the same passion for the mission. People with the potential to grow within the company not only vertically but laterally. And last but not least, people who will help others to grow with them which makes them multiplier forces. These three pillars are the ones that will put your company in the right place to play the infinite game and have a team that can keep pursuing the company's mission for generations even long after you are gone.

So what about going beyond the job posting. What does a Hiring Manager need to do? How do they present themselves to the candidate, before, during and after the hiring process?

Let’s remember that an interview process is two-ways and it is as much an interview for you picking the right candidate as it is for them to pick the right company.

When looking for resources to learn more about the subject I've asked this on my personal twitter account:

And the answers I've got to these questions were so amazing that came in a perfect timing to get inspiration for this issue:

Special thanks to those that helped inspire this edition:

David (@highwayman)

Emma (@SalamancaPeral)

Ernesto Arroyo 🇺🇳🇪🇺🇪🇸🏁🏴‍☠️ (@earroyoron)

Félix López (@flopezluis)

Justyna_Adamczyk (@Justyna_Adam)

marina @ bliss (@Currofile) / Twitter

Tabita Luis (@TabitaLuis) / Twitter

Ruyman (@ruyman_cc) for keeping me motivated to keep writing.

Angel (@amcereijo) for always helping me to keep the bar high in the contents of this newsletter.

Here are some resources I've found during this month that either inspired this newsletter or got recommended to me while getting inspiration:

Articles

After Hiring: The Remote Guide to Onboarding

Dealing with the problems of scaleups

Designing Without Whiteboards: The Remote Guide to Product Design

Find Your Why: How to Draft a Why Statement

Focusing on wellness at work

Leading Distributed: The Remote Guide to Management

Leading your engineering team with ‘experiments’ not ‘processes’

Polishing Product Management Skills

Re:Focus: Write A Vision Statement That Works

Reengineering the Recruitment Process

Scaling Your Remote Team: The Remote Guide to Hiring

The Art of Async: The Remote Guide to Team Communication

Three crucial skills that leaders must develop to become executives - The Skip

When to Take a Chance on an Imperfect Job Candidate

Writing Tips for Remote Workers (And Everyone Else)

📖 Books

An Elegant Puzzle: Systems of Engineering Management by Will Larson

Books On Recruitment To Read - Emma Salamanca

Cracking the Coding Interview: 150 Programming Questions and Solutions by Gayle Laakmann McDowell

Scaling Teams: Strategies for Building Successful Teams and Organizations by David Loftesness

Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent by Joel Spolsky

Staff Engineer: Leadership beyond the management track by Will Larson

The Infinite Game by Simon Sinek

The Tech Resume Inside Out by Gergely Orosz

Who: The A Method for Hiring by Geoff Smart

🎬 Videos

The Infinite Game: How to Lead in the 21st Century - YouTube

✉️ Other Newsletters

SoftwareLeadWeekly: A free weekly email for curious humans who want to build better teams and companies.

Photo by Suzanne D. Williams on Unsplash

Hi there!

Welcome to the third edition of the LeadingIn.Tech newsletter. On this edition I want to share some thoughts on leadership in times of accelerated changes.

As January 2021 is coming to an end I'm not going give you a list of "the best of" or "the worst of" something like that. Neither it will be about my what were my New year's resolution. Instead I'll talk about how the accelerating pace of changes happening around us are shaping the way I conceive leadership.

Only a year ago you could find people debating whether the change of decade would happen on Dec 31st 2020 or Dec 31st 2021 but nobody thought that a full decade worth of changes and events would happen in between these dates. Let alone that things wouldn't slow down shortly after new years eve.

From the humility of my own set of circumstances I've experienced personal changes such as changing jobs or becoming a parent just before the Covid-19 pandemic. Last year to most of us it felt like the universe had released a Kong sized Chaos Monkey among us and forced us to rethink the way we live our lives and how resilient we were when facing completely unexpected situations.

After spending 8 years in a small to medium sized startup where I was the first employee and where I've built a mental model based on all of the context accumulated by knowing all the "How's" and "Why's" things worked the way they did; then change to a completely new environment in a "BigTech" with the role of an Engineering Manager feeling like an alien overloaded with so much information I couldn't posible digest in a single lifetime. Add to it a global pandemic that forced everyone to lockdown at their homes and work remotely while parenting with schools closed.

Preparing to effectively lead

When I've asked for advice on how to better prepare myself for the new job; one of my future peers pointed me to the book The First 90 Days and I've found it incredibly helpful to prepare myself mentally to switch to learning mode.

The first 90 days helps you change your mindset and prepare yourself first by doing an assessment of your situation when landing into the new role. It gives you some tools to understand what is working and what isn't but also what resources and levers are available to you do drive changes.

Your main asset for success will be your ability to build a network from all levels of the organisation, identifying your information sources, the supporters for change, the blockers and the neutrals. Followed by focusing in accelerating your learning about the culture, and how things work but most importantly; to understand the "Why's" things are they way they are. This will give you a current state outlook so you can start defining a strategy that will be tailored for the situation.

By relying in your manager and supporters you'll need to make sure you have all you need for success so you can start securing early wins that will boost confidence and help you earn trust with your peers and stakeholders. This will give you the momentum needed to have all pieces aligned to take the next steps and shape the processes and people around you to get to the final stages of transformation including your team and partners support.

But things don't end here, this is is just the beginning. To make any transformation last, it needs to be sustainable, resilient and able to outlive the ones that initiated it.

Building Resilience

The capacity to recover quickly from difficulties; toughness.

You could find tons of examples of business that have endured through the pandemic by reinventing themselves as these businesses needed to pivot in order to survive.

A great example of this is AirBnb who managed to not only to pivot to a completely different offering of services in the middle of the pandemic and an IPO but as a result of this they are now better prepared for the future. They did this by reevaluating what is the value they actually offer to their customers but also by listening to them and adapting fast enough to the changes in their environment. Of course they took a hit but they managed to pivot "their entire product line to offer online experiences" in times where travel was restricted and people were in lockdown in many parts of the world.

This kind of adaptation in situations of crisis is better described by Lara Hogan the author of the book Resilient Management from her article: How 2020 has shaped you as an engineering leader | LeadDev:

I used to think that when a caterpillar wraps itself up in a cocoon, it takes a little nap as it sprouts wings, and then emerges as a beautiful butterfly.

It turns out, the process is way more gruesome than that: inside that cocoon, the caterpillar reverts to a primordial state, digesting itself into a kind of soup. (I’m sorry for the mental image!) Eventually, it reforms itself into a wholly new state, and the butterfly pops out, glorious and winged.

I absolutely love this as a metaphor for growth.

Bonus treat for the Rocky fans:

"You, me, or nobody is gonna hit as hard as life. But it ain't about how hard ya hit. It's about how hard you can get it and keep moving forward. How much you can take and keep moving forward."

Cultivating Ownership (In a humane way)

Last but not least I strongly believe that the best leaders are the ones that delegate ownership and doing so in a compassionate way. Creating a safe environment for experimentation, for failure and recognition. In the article Compassionate Leadership Is Necessary — but Not Sufficient they refer to this approach as "Leaders operating in this mode are balancing concern for their people with the need to move their organizations forward in an efficient, productive manner. When tough action is needed, they get it done with genuine caring for people’s feelings and well-being."

By cultivating ownership you are also creating a more engaging environment for people to thrive and innovate in the process. As a result you will be creating a more resilient organization capable of learning and adapting constantly. The flow of information and the decisions will happen in a way more efficient manner.

📄 Related articles

3 Important Lessons From Airbnb's Pandemic Pivot | Inc.com

A Message from Co-Founder and CEO Brian Chesky

Creating Connections. The subtle leadership skill that makes… | by Scott Mabry | Nov, 2020 | Medium

How 2020 has shaped you as an engineering leader | LeadDev

📄 Other articles added recently

2020 remote working learnings. My summary of learnings about Remote… | by Txesk Planells Ceró | Dec, 2020 | Medium

Common Performance Review Biases: How to Spot and Counter Them - The Pragmatic Engineer

Compassionate Leadership Is Necessary — but Not Sufficient

Conway’s Law: Critical for Efficient Team Design in Tech - IT Revolution

Does your organization need a developer evangelist? - Stack Overflow Blog

Giving feedback remotely - Know Your Team | Blog

How to build team morale remotely - Know Your Team | Blog

How we doubled the representation of women in Engineering at Clio | by Ainsley Robertson | Clio Labs

If You’re Building Microservices, You Need to Understand What a Bounded Context is | by Dave Taubler

Leveraging a Manager Weekly Newsletter for Team Communication | SoundCloud Backstage Blog

Management Debt - Andreessen Horowitz

Normalization of non-deviance

Tips for engineering managers learning to lead remotely | GitLab

We're Never Going Back - Not Boring by Packy McCormick

Why this manager put workers in charge of their own raises, career development, and reviews

📖 Books

Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb | Goodreads

The First 90 Days: Critical Success Strategies for New Leaders at All Levels by Michael D. Watkins

Resilient Management by Lara Hogan

Resilient Management, An Excerpt – A List Apart

Book Summary: 'Resilient Management' by Lara Hogan | Pat Hermens

🎧 Podcasts

Aaron Blohowiak from Netflix on Mistakes and Discoveries While Cultivating Ownership

Interview with Cate Huston: Engineering Director at DuckDuckGo

Supermanagers Podcast by Fellow.app

🎬 Videos

How Airbnb Pivoted | Simon Sinek & Brian Chesky - YouTube

👨🏽‍🎓 Courses

How to master 1:1 meetings - online course

Welcome to the second edition of the LeadingIn.Tech newsletter. On this edition I'll give a step back and share to you as part of the toolkit For Engineering Managers my current understanding of what do they generally do.

When learning about The role. The first thing that is important to know for people that are thinking about making the change or are landing into the position is that, it is a people management role within the Software Development or Software Engineering career family which forks into a different career path from the individual contributor path. This means that becoming an Engineering Manager is not promotion but a career change. As a result of it you will be executing different functions that will also require you to acquire a new set of skills to effectively lead individual people and teams.

So what does an Engineering Manager do?

To better describe it, I'll split the Engineering Managers work into 5 categories that in my experience cover most of the aspects of the day-to-day activities and each of them is represented as a section on the toolkit. Depending on the company you work with or the context of the team you will be managing the amount of time dedicated to each of these will vary. If you want to read more about it Patrick Kua has an interesting article about it where he describes 5 Engineering Manager Archetypes

1.👤People

👥1:1 Conversations

The holy grail of management (IMHO.) Holding regular one-on-one meetings with every member of the team is the most important tool you have as a manager to connect with your team. In this conversations EM's give and receive feedback, provide coaching and most importantly work on building a transparent relationship where your team can voice their concerns and feel heard. These meetings also serve as a place to talk about career development and performance. And last but not least provide alignment and direction on the team or company mission.

💯Career

As an Engineering Manager you play a significant role in the career progression your team members. As an EM you are responsible of setting your team for success but at the same time keep them out of their comfort zone so their work remains challenging enough and they continue learning and growing professionally. You are the principal sponsor of their promotions but also the one that manages underperformance when detected.

🔍Hiring

Engineering Managers need to be capable of attracting the right candidates to join their teams. They own the interview process for the open positions for the team. EM's are ideally also the ones that publicise the "goodness" of working in their team. As people are more eager to work with inspiring leaders, this is where you bring in people that believe in your team's mission and that will share the same values that your team holds.

2. 🚢Delivery

This is the Project Management and Operations aspect of the role. As a manager you need to make sure that the team has in place the right processes that will allow the team to deliver value to the customers at the right time and with the highest standards. Setting in place Agile methodologies, building and tracking roadmap progress, detecting and managing risks, handling partner team dependencies and effective status communication with the stakeholders are some of the activities the EM needs to cover.

3. 💻Engineering

Let's not forget that Engineering Management is also a technical position. You are responsible of the technical direction of the team, this means setting in place good engineering practices in your team as owners of the software you produce. The technical aspects also include participating in code reviews or architectural decisions to guide the team into making the right tradeoffs. The dimensions that help you guide this decisions usually include: scalability, performance, maintainability, resilience, infrastructure costs or team capacity. Your focus is typically on automation and to guide the team into when to leverage in new technologies or work on technical debt. Depending on the company some might expect you to participate in coding activities but it is advisable to stay away from the critical path code so you don't become a bottleneck for the team.

4.📦Product

This where as an Engineering Manager your focus will be in helping your team prioritise the work that brings the highest value to the customers. Roadmap planning and stakeholder communication is where most of the time is spent. But as a manager you will find yourself constantly asking "Why" to invest in a given project. Considering, customer value, long term strategy, market opportunity or the return of the investment. As a manager you will also help translate business and customer demands into bite sized projects. Using experimentation and measuring customer behaviour are one of the techniques to help you understand where the value is added.

5. 🌐Remote

I like to have this as a separate category as I feel that it is a relevant enough topic that is shaping the way teams operate today. Being prepared is instrumental for the success of any team that is at least partially adapting to work remotely. This can be achieved by making sure the team has the right processes and tools in place to collaborate in a remote format. And that these are well documented in a handbook that is easily accessible by everyone.

Another aspect is making sure that your team has the right setup in their home or remote office. Also as a manager you should make sure that your team has access to proper training on the tools and best practices to enable them to work remotely.

As a manager you will also need to ensure that there are in place the right activities that will help you build and preserve team culture and cohesion.

📄 Related articles

• 5 Engineering Manager Archetypes

• A step-by-step guide to becoming a better engineering manager

• Being an Engineering Manager

• Engineering Management: The Pendulum Or The Ladder

• Engineering Manager vs Tech Lead - The Imperfect Manager

• How to Become a Great Engineering Manager - DevOps.com

• “Software Roles and Titles” by Eric Elliott

• What is an Engineering Manager? – Amy Phillips

• What is an Engineering Manager? by Michelle Kung

📄 Other articles added this month

• El rol del Tech Lead - Blog Talento IT

• Maker vs manager: How to connect your schedule to your goals

• This Email From Elon Musk to Tesla Employees Describes What Great Communication Looks Like | Inc.com

• Our Work-from-Anywhere Future

📖 Books

The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

If you are a developer who is transitioning or thinking about taking on this role. I would recommend reading it. This book covers the path starting from the first mentoring activities as a senior engineer in a team, going through becoming a Tech Lead then taking the leap into managing a single team, multiple teams or even managing managers and finally covering the CTO and VP Engineering roles.

The book is listed in the toolkit For Engineering Managers and I encourage you to not limit yourself to read it once and forget about it but to use it as a reference guide all over your career. Read it now or in 5 years and you will still be able to get value out of it wherever you stand in the career ladder.

El Manual del Manager

Even thought it's still a work in progress the authors of the book Alvaro, Keyvan and Félix have released the book for purchase with the first three chapters "The role of the manager", "Feedback" and "Product oriented development" and more chapters to come soon. The authors describe the book as the one I wish I had read when I started my career.

Become an Effective Software Engineering Manager by James Stanier

James Stainer the author of the book is also the owner of the blog theengineeringmanager.com where he writes about the role with tons of articles that will help you learn about the role and progress in your career.

🎧 Podcasts

94. Engineering Management - Podcasts | Heroku

NoSoloTech - Podcast: "Engineering management"

This podcast is in Spanish and here they share an interesting conversation on what is like to be an Engineering Manager. The authors of El Manual del Manager also give a few glimpses of what you can find in the book.

🎬 Videos

On Managing Technical Teams as a First-Time Manager: CTO, Engineering, Management | Y Combinator