When I became the CTO of my previous company, the transition was rough. At the time, I didn’t fully understand what the transition was about. In my mind, the job was about getting stuff done and solving complicated technical challenges. 

I told myself that if customers were happy and we kept shipping, I was doing my job. 

I was wrong.

Capturing Reality vs. Crafting Narratives

At first glance, a manager's role might seem a bit like that of a photographer: capturing the reality of the business environment and presenting it as is to the team. This involves relaying facts with clarity and accuracy. 

It feels natural to say it like it is. So and so got laid off, executives are changing direction again, team member X is not preparing before meetings, etc. 

The problem with just saying it like it is is that we tend to forget that everybody else is building a narrative of who they are in their story, and things that happen at work are just part of the plot that is their entire lives. 

Most of the communication issues I caused in the past were about just stating the facts. I would, completely unaware, ignore the gaps between the raw facts and let my team fill in them based on their unique experience and perspectives. Because of this, we would often end up with different stories in our heads without knowing it.

A classic example was me saying: we’re working on feature XYZ now because a couple of leads requested it. The team would nod in agreement and start working. 

All the gaps would show when we needed to try the new feature in our test environment. When addressing the gaps with the engineer leading the effort, they often said: “I’m not sure how customers use our product, but I think this is done.” 

Ouch. Here I was, failing to communicate the customer story and wasting a ton of time.

A good manager is more like a painter; a painter doesn't just replicate what they see; they interpret, add context, and evoke emotions. They weave these facts into a compelling narrative, giving them meaning and helping team members understand how these changes fit into the larger picture.

Do It For The Plot

Behavioral science offers insights into why the ‘painter’ approach is effective. 

Stories are a fundamental way humans process information. According to Uri Hasson from Princeton University, storytelling synchronizes the listener’s brain with the speaker's, facilitating understanding and empathy. When we craft narratives around business facts, they’re informing the team and connecting with them on a deeper level.

A narrative approach to management goes beyond day-to-day tasks. It builds a shared sense of purpose. Daniel Pink, in his book "Drive" (Here’s a nice summary), highlights the importance of purpose in motivating employees. Managers can enhance motivation and engagement by connecting everyday work to a meaningful narrative.

While the factual accuracy of a photographer is essential, our role as managers transcends mere fact-reporting. Like painters, we must craft stories that give context, evoke emotions, and provide meaning. This storytelling approach is not just a communication strategy; it's a fundamental aspect of leading and inspiring a team. 

I used these principles when the whole company had to start implementing security requirements to achieve SOC2 attestation. No more playing fast and loose; everything has to rely on SSO, we can’t be handing out SSH access to everybody and their mom, etc. The team was on board, and there was not much resistance - after all, who wants to put customer data at risk? 

That was until the topic of employee device management came up. 

A very reasonable question of “Are you going to be able to see what we’re browsing and read our email?” (and similar) started to surface during one of our retrospective meetings. 

I knew that just saying, “We’re doing it because it’s in the requirements,” would not cut it; that's step one of eroding trust, making people feel like cogs in a machine, and ensuring they will feel disposable. Obviously, I couldn’t lie either and say that we’re just ticking a box - that’s not the culture we wanted to build. 

Here’s how I tackled the device management & monitoring conversation: 

I did admit that, yes, the monitoring agent that everyone needs to install is powerful - it gathers system stats, can run remote commands, and allows a certain degree of remote control. But I didn’t have to exercise any of that because there was no need: all these capabilities were required so that we can ensure that everyone’s OS is patched, on-disk encryption is enabled, and the screen locks out automatically. We want to prevent any chance of our production systems being compromised if someone’s laptop gets stolen and effectively kills the company as a consequence. 

The last point was an exaggeration, but it was a powerful narrative that got me the buy-in.

You can exaggerate only to emphasize your point and what you’re trying to convey. Do not deceive; lies have short legs. 

That’s what a manager does: you have to blend facts and narrative, be honest, and inspire people. It’s not about bullshitting and crafting elaborate stories - it’s being truthful with a purpose. 

It Goes Both Ways

Let’s look at a counter-example. Your team is working on a complicated feature; everyone did their best to scope the work and divide it into shippable chunks, and the work is progressing steadily until you notice that one of the Pull Requests has been stuck in a draft state for two weeks.

 If you ask the engineer doing the work, they most likely would say: “It’s just taking a bit longer than expected, but everything is fine.” 

It sounds like a reasonable answer, right? 

Wrong!

You need to gather the facts, understand what’s going on, whether the engineer needs more help, or if what the team is trying to build was under-scoped or “it is what it is,” and everyone just has to suck it up. 

Only then can you create a narrative and explain why there will be a delay. You can even turn something that feels like bad news into good news. For instance, “We prevented a huge performance issue affecting production. Yes, things are delayed, but we dodged a bullet.” 

Your team models how to communicate based on how you do it; they will most likely follow and adopt the same strategies. Who knows, maybe you’ll have fewer status meetings.

Never Ending Story

I learned the hard way that first, one has to get the facts right; second, understand the overarching story; and then, and only then, share that narrative with the team. Sometimes, the problem is not what you said but what you didn’t say.

I still remember very clearly the day I talked to a friend about the company I was about to start. He had built and sold several companies and invested heavily in AI before it was cool (again).

I explained to him that I wanted to build a system to help engineering managers regain their time and focus on the important parts of their job instead of the admin. My friend immediately said, why help managers if you could replace them?

 Then he shared this tweet.

The scenario he was describing would look a bit like this: 

Any company could deploy its AI agent, EMAI, to manage its software engineering teams. EMAI is not just any AI. It's been trained on countless software projects from the past decades, holds knowledge from all leading management methodologies, and has real-time data access to the latest technology trends and best practices. It has been specifically designed to replace the role of a software engineering manager.

Let’s indulge this premise and see how this could work in practice:

A Day with EMAI

Morning Stand-up Meetings: Instead of traditional stand-ups, engineers log into their systems and provide a brief update by sending a short voice message. EMAI processes these updates, analyzing voice tones for stress or uncertainty, ensuring it can provide resources or assistance if an engineer faces challenges.

Task Allocation: Using real-time data on each engineer's strengths, past performance, learning curve, and even their preferred working hours, EMAI allocates tasks from the backlog. It uses predictive modeling to optimize for both efficiency and team satisfaction.

Conflict Resolution: If two engineers have a disagreement or are blocked by each other, EMAI steps in. Using its vast knowledge base and understanding of human psychology (aided by its training data), it mediates discussions, ensuring a harmonious team environment.

Training & Upgradation: EMAI monitors the latest tech trends. If a new tool or technology emerges in the market, it identifies which team members would benefit most from training and automatically schedules online courses or tutorials for them.

End-of-Day Reports: Every team member receives a personalized report detailing their accomplishments, areas of improvement, and resources for further learning. These reports aren't just data-driven and include motivational feedback designed to boost morale and foster continuous learning.

EMAI is efficient; it ensures tasks are allocated and problems are resolved with unmatched speed. EMAI is also objective; decisions are data-driven, eliminating potential biases in task allocation, promotions, or conflict resolution.

EMAI also manages to keep stakeholders informed, and it can negotiate with them to find the best solution given their inputs and the business context.

It might sound dystopian, but setting emotions aside and viewing it purely from a business perspective, the idea of replacing engineering managers with AI offers potential efficiencies. In fact, many organizations might be willing to consider this as an experiment. It’s not far off from what a lot of businesses are planning to do or are already doing with customer support departments.

Mind the gap

There’s one thing that’s obviously missing here. The lack of genuine human empathy and intuition might lead to feelings of detachment or isolation among team members. There’s a reason why people just quit their jobs if they feel like all they do is work on an assembly line (no offense here; I spent a few years working in real factories assembling car parts, sandwiches, and more things than I can remember). 

If you step back, however - you’ll notice that ineffective managers can also create a similar environment: rigid processes, constant requests for status updates, and micromanagement turned up to 11. 

Most EMs I’ve talked to have mentioned the fact that they do not want to make the same mistakes their previous managers made, which indicates to me that bad experiences with managers are perhaps the common denominator, especially when you look at how much burnout and lack of motivation is reported within the industry. 

Approximately 80% of developers claim their burnout symptom is a general lack of energy to work and complete coding projects. If empathy is a unique human competence that AI can’t replace, it looks like we are not doing great in the empathy department.

Another argument against AI agents is dependence on data; for example, if there's a scenario outside EMAI's training data, it might struggle to find an optimal solution. However, the same can be said for managers who do not invest continuously in leadership skills or strategic thinking and instead rely on engineering productivity metrics and dashboards charting an average number of comments per pull request (yes, it’s a thing).

And, of course, there are security concerns; relying heavily on AI opens avenues for potential cyber-attacks, but this also applies to any area of business. We're in a new arms race, and new prompt injection techniques are being created every week. AI is here to stay, so we must navigate this anyway.

My friend’s arguments for replacing managers still feel compelling and very plausible, yet I decided to bet on engineering managers powered by coffee (or tea) rather than electricity.

Betting on the future of engineering managers

While AI can recognize patterns and even detect emotions to some degree, genuine empathy comes from shared experiences. Managers can understand personal issues, stresses, and the unique challenges their team members face—both in and out of the workplace. 

Many decisions in the tech world aren't black and white. They require an understanding of various shades of gray born from lived experiences, cultural contexts, and sometimes even gut feelings. Human managers can weigh multiple factors, foresee consequences, and choose paths that might not be immediately evident to an algorithm.

Equally, organizational culture is multifaceted and deeply human. Leaders play a crucial role in instilling values, ensuring a sense of belonging, celebrating successes, and even mourning losses. They shape the team's identity and foster an environment where members collaborate, innovate, and grow. Inspiring people, establishing friendships, and adapting to change are some of the things I can’t imagine being replaced by AI agents (at least for now).

I’m betting on our ability to automate as much as possible the tasks that get in the way of meaningful work so that we can invest in empathy, in being present, and truly serve people in the most humane way possible.

What do engineering managers identify as the most challenging part of their job? The answer is nearly unanimous: managing people. Even with well-honed emotional intelligence and a naturally self-aware disposition, great managers will encounter situations that rigorously test their social and communication skills. 

If you could master just one skill to enhance your career as an Engineering Manager, let it be change management. In this post, I cover the key concepts you need to know about and their practical applications.

Understanding change

Change happens every week; sometimes, we deal with small changes like reducing the scope of a feature. Sometimes, we have to migrate from a monolithic application to a microservices architecture (or the other way around). 

Understanding how change management works will transform how you think about team engagement, prioritize initiatives, and coordinate multiple stakeholders and agendas within the organization. It is a judo move that will keep giving. 

Change is not about what you want to achieve but what others think they will achieve if they embrace change. Change is less about processes and more about people — their security, personal chances of success, and how much they can see themselves as individuals in the future you propose.

One of the biggest misconceptions is that change is a collective activity — it may look like it on the surface. Still, when it comes to implementation, it is actually a very individual process. You, as a change agent, need to be able to manage change at both the team and the IC level. 

No matter how strong the culture is in your team or organization, people adapt to change if you can help them answer very specific questions:

• What does this change mean for me?

• Is my job safe?

• Can I see myself in the future they are describing?

• Can I trust them? Why are they planning to do this?

• Will I still be okay with this team if I don't change?

Change also happens gradually and in stages

The Kübler-Ross model, or the five stages of grief, is often used to explain individuals' different stages when they experience dramatic change. From grief to job loss, we all have to deal with different nonlinear stages of adaptation.

Source: This variation of the Kubler-Ross Change Curve charts the phases of emotional states and actions against time in three stages.

You may not consider some of the changes you want to implement as dramatic as a job loss. However, even if the changes are mild, people will still experience different degrees of acceptance, denial, engagement, and commitment.

Change is not a linear process.

Most change initiatives fail because people driving change do not understand the individual needs of those who will implement the change. How do you implement change and, most importantly, make it stick?

In their seminal book, Switch: How to Change Things When the Change is Hard, Dan Heath and Chip Heath outline a methodology for instilling behavioral change. They call it “The Rider, The Elephant, and the Path,” and it is worth noting that they based it on the work of Jonathan Haidt, a renowned NYU psychologist.

(Note: You can watch Dan Heath explaining the whole concept in this video, but let me reiterate it for you quickly here, too.)

The premise behind this is centered on our knowledge about two separate systems in our brain — rational and emotional. As Haidt proposed, we should think about it as a rider on top of an elephant.

The Strategy

The rider represents the logical, rational part of your brain. That is the part that analyzes, plans and solves problems.

The elephant, on the other hand, represents your emotions. Needless to say, that is the system that powers up your actions.

As you already know, logic plays a surprisingly small part in driving our behavior, but even when we are aware of this, we still trust our ideas and the rationale behind them to drive action.

As Dan Heath puts it:

“The rider can try to lead the elephant or drag it. But if the two ever disagree…who would you be on? The elephant has a 6-ton weight advantage. And it’s exactly that power imbalance making adopting new behaviors very hard.”

Based on this, the Heath brothers concluded that to implement a change, you need to

• Give directions to the rider that will help them get to the destination,

• Motivate the elephant by tapping into emotions,

• and finally, shape the path to allow them to get to the destination quickly and without encountering any significant obstacles.

So, let’s go through those three elements in detail and discuss how you could implement them within your team.

1. The Rider

To motivate the rider, you need to do two things. First, you need to provide direction, which means explaining in detail the nature of the change. Second, you need to provide the knowledge that will help the rider get to the destination.

Here’s why: what manifests itself as resistance to change more often than not is just a lack of clarity. Not everybody can navigate uncertainty the way you might.

Understanding the next steps for something you have never done before does not come naturally. Humans like predictability.

For example, you may feel comfortable saying, “I don’t know if this is going to work, but let’s try it, test it, and see what happens.” For most people working in engineering, this feels natural and is a good way to propose changes, but the truth is that very few people feel comfortable not knowing if things will work. 

There will be anxiety and resistance whenever there is a chance for failure. This is why being agile is so hard. Stakeholders do not like uncertainty, and managing stakeholders effectively requires people who can drive change effectively.

In practical terms, as the Heath brothers point out, this involves following a simple, 3-step process:

Step 1. Reducing the analysis paralysis: We naturally tend to overanalyze problems. The trouble is that such behavior often leads to a complete failure in making decisions and moving forward. Thus, unless you translate the change into something your team is already familiar with, they might respond to it by overthinking it.

Step 2. Scripting the critical moves: The rider represents logic. Because of that, it will only respond to clear instructions. To motivate the rider, you need to translate the goals for the change into concrete behaviors it can perform. For the rider, clarity dissolves resistance.

Step 3. Giving the Rider a Compelling Destination: Logic thrives on goals. A compelling destination will engage the rider and motivate them to undergo the journey. So, give it a vivid image showing the possible outcomes of the change.

Speaking from experience, this might be the easier part - for example, it didn’t take too much to demonstrate the value of merging ~40 repositories into one. The paralysis came from technical questions such as “How are we going to deploy things?” or “Is this going to make Pull Request reviews more messy?”. My job was compiling pros and cons and demonstrating logically why we should move to a mono-repo. Yes, some things got a bit more complicated, but the benefits outweighed the downsides that were rightfully pointed out by the team. 

2. The Elephant

It is much harder to find arguments that ignite emotions than logic. However, at the heart of understanding how to motivate the emotional side of our brains lies the idea that smaller goals motivate us more.

Research study after another has proven that setting up big goals has a diminishing effect on our motivation. Goals motivate people only when they have received positive rewards and feedback from reaching them in the past.

That’s why, to motivate people emotionally, you need to break the change into smaller chunks to offer faster gratification for implementing it.

As Dan Heath notes: “Hope is elephant’s fuel. And when a task feels big, emotions will resist.”

How can we overcome resistance on a practical level?

Never initiate a big change in one go. Instead, break it into smaller steps and set milestones that deliver wins quickly for the team.

One scenario that comes to mind was getting our product and company SOC2 certified - I didn’t unload all of the requirements, checklists, and changes in one go. Instead, I started to make changes step by step, and the more sensitive ones, like installing a monitoring agent on everyone’s computers - had to be tackled initially, with assurances and clear outcomes. People were resistant because it felt like the company was becoming too rigid and that we would be monitoring their every step, where, in fact, all we needed was to ensure that our security baselines were covered. 

After explaining and assuring that I couldn’t care less if they also shop on Amazon during work hours (who doesn’t?), people eased into the fact that compliance does help us land more customers and makes everyone’s life easier in many aspects.

#3. The Path

The final element of the strategy is the path — the process both the rider and the elephant will go through to reach the destination. Just as you need to engage people’s emotions and give them logical arguments to overcome their resistance to change, you also need to shape the path to allow them to absorb it. After all, the fewer the obstacles to implementing the change, the more likely it is to happen.

This may mean automating certain processes, enabling extra resources while change is introduced, providing time and space for teams to communicate, and making data available across the business to build transparency. Removing friction will clear the path for bigger changes to be adapted.

Going back to the mono-repo migration, I have involved the team in figuring out the biggest risks and how to overcome them. Their main concern was managing big pull requests spanning multiple projects and how to roll out changes incrementally. The migration was going to happen regardless because we felt the pain of managing too many repositories - but rather than just implementing the change, we made the process highly collaborative so that everyone could participate and understand the final state before it even arrived. 

In Summary

To introduce change successfully, you should consider

• Defining what the future would look like.

• Defining the steps/ direction people can take to get there.

• Providing safety. Address how change will affect each person and help them see themselves in that future. You may need to do this with each person or each team separately.

• Defining concrete, small steps or actions the team can take to see progress. Use those steps to create ownership.

• Celebrating progress, even the smallest wins.

• Make sure you have involved everybody who may be affected in any way by the change.

• Make sure you involve even the people who will not participate directly but have some influence (PMs, QA, other stakeholders). 

Introducing change in your team or the organization involves two types of work that must happen in parallel.

The first type of work is the change itself — for example, helping your team adopt a new methodology, moving to a new delivery process, creating a new team structure, etc.

The second type of work is managing people during the change. It may involve running 1:1s with multiple people to manage their expectations, writing weekly updates on progress, and opening new communication channels for people to ask questions, etc.

Change management takes extra work that is not in your job description, and it is a thankless job because, if you are successful with the change, everybody should feel it was because they embraced it, not because you led it.

If you are interested in learning more about change management, here are a couple of great books to get started:

• Switch: How to Change Things When Change Is Hard, by Chip Heath and Dan Heath.

• Leading Change, by John P. Kotter, 2012

• The Little Black Book of Change: The 7 Fundamental Shifts for Change Management That Delivers by Paul Adams

• Making the emotional case for change: An interview with Chip Heath

“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw, Nobel Prize-winning playwright.

Understanding Communication Infrastructure

In the last few weeks, as part of my own product research, I’ve interviewed over 60 engineering managers. My goal was to learn more about what processes, channels, and techniques they have developed to improve communication within their teams, and the insights from these conversations have been counterintuitive and surprising.

When I ask EMs about how they manage their team, most of the time, I get a very elaborate and descriptive answer about their delivery process; I hear about Jira implementations, documentation, prioritization, and many other topics related to structuring work. However, I hear a lot less about communication infrastructure.

Communication infrastructure is the intentional design and use of channels, spaces, and tools that have a unique purpose and are part of a communication system that allows the team to have effective feedback loops. 

Engineering a good communication infrastructure is about designing the purpose and protocols needed to get the best out of the communication activity and then implementing tools that facilitate that protocol.

For example, many teams use Slack, but many managers struggle to keep up with the quick decisions made in multiple channels. The problem is not Slack but the protocols and rules around it. 

A common case is teams using direct messages in Slack instead of discussing issues in public channels. This behavior leads to a lack of context, missing opportunities for learning, and a lack of visibility on decisions. In this case, the infrastructure is broken; you have a tool with no defined purpose and no protocols to keep it effective.

The protocols you put in place say much about what you value within the team. 

If transparency is a value, then what are the specific protocols that support that daily?

In my opinion, there is no better place to exercise your values as a team than in how you engineer communication. In this post, I share some abstractions and specific recommendations that can help design better protocols and get more clarity from every interaction between team members.

Developing Protocols

“Communication works for those who work at it.” – John Powell, film composer.

The first step in designing your infrastructure is to look at the recurrent conversations you have within the team. Here are some examples:

• PR reviews

• Status updates

• Rubber ducking and debugging chats

• Rolling out of new features

• Dealing with blockers

• Cross-team sync meetings

• Performance feedback

• Career development

• Reviewing team structure and dynamics

• Retrospectives 

• Postmortems

• Planning in general (sprints, ShapeUp, etc.)  

• Strategic product decisions

• Scoping/requirement definition 

• New tooling discussion

Now, let’s take one of those conversations and review some of the challenges I heard from engineering managers. Let’s pick Retrospectives.

The most common challenges people share are:

• People are too quiet or disengaged during the retrospective.

• People show up without any topics for discussion.

• The session is too long; we spend 2+ hours on a call getting topics ready, etc.

• Nothing happens after the retrospective, and the actions are never completed.

I can relate to those challenges; I have participated in or run retrospectives for the last 15 years of my engineering career. 

Here’s a protocol I’ve found helpful to avoid common challenges. There are many obvious things here, but you would be surprised how easy it is to ignore them and underestimate their negative impact on the conversation.

It is not about micromanaging the team but about setting up the protocol so the team can relax and communicate smoothly.

Retrospective protocol example:

Before 

• Arrange a recurrent event in everybody’s calendar. 

• If the team needs to reschedule, do not skip the retro instead, find a better time within a couple of days and adjust recurrent events.

•  Send reminders to the team about adding/gathering their topics for discussion at least three days in advance.

• Send additional reminders to team members who have not added a topic yet. 

• Gather topics and organize them into groups the day before the retro call. 

During 

• Record the call for those who could not attend and for additional note-taking. 

• Start the call addressing what action items from previous retros got done or not and why.

• Make sure the retro is not just about the work that was done, but there is also space to discuss team dynamics or feedback on the retrospective itself. 

• Agree and assign action items.

After 

• After the call, send a quick summary of any decisions made and the list of action items.

• Prioritize and add items to specific tools (Jira, Linear, etc, etc.)

• Review if items have been executed before the next retrospective, at least one week before the next one.

• Rinse and repeat. 

The protocol above helps engineers think about topics in advance; it promotes asynchronous preparation so the call can be focused on the discussion, creates accountability by reviewing previous tasks at the start of the session, and provides space to evaluate the session's effectiveness. 

Additionally, these protocols enable anybody on the team to run the protocol themselves, so they are less dependent on you running these sessions. Once you have a protocol, you can look into tools to automate tedious things like scheduling, reminders, templates, recording, note-taking, follow-ups, etc.

The key point for protocols is that they can not always rely on your memory and ability to stay perfectly organized. Things change fast, shit happens. You need a resilient protocol conducive to your team having an opportunity to step back, share learning, and take action for improvements.

You can’t just adopt or buy tools and hope for the best. Returning to the Slack example, you can’t just open several channels and hope communication will flow efficiently. Even at the level of ceremonies, although they have an inherent structure, you still have to design protocols for those that work specifically for your team.

“Early in my career as an engineer, I’d learned that all decisions were objective until the first line of code was written. After that, all decisions were emotional.” ― Ben Horowitz, The Hard Thing About Hard Things.

Having experienced both roles in the past, I think being an engineering manager is not that different from being the CTO of a very early-stage startup. You need to hire, define the values and culture of your team, put in place protocols to maximize the impact of every team member, and deal with stakeholders (investors, customers), etc.

As an EM, my main job is to build the systems that help people flourish, so I always start with the protocols that help team members step back, express concerns, share ideas, bubble up problems, and take action on those. 

At a minimum, I suggest having a good protocol for one-on-ones, retrospectives, async check-ins, and ad-hoc meetings.

These protocols are normally underpinned by general rules you agree with your team. Rules are not about trying to control the team; rather, they are about building a shared common sense. 

Here are a couple of examples:

• If you spend more than 5 min on Slack explaining something, jump on a call - It will be faster.

• If a decision was made in a call — write it down immediately and share it publicly.

• Always start with the users and their experience. Everything can be worked out from there.

This checklist has been copied verbatim from the “Communication” section of my previous company’s employee guide. These guidelines set the way we used Slack, Trello, and Notion. And remained mostly unchanged when we had to move to Jira and Confluence. Furthermore, at some point, the team came up with a protocol for dealing with our Pull Request process because they noticed inefficiencies after we migrated to a mono repo. I didn't even write the initial proposal; it was driven by the team from the start.

Having clear protocols also helped fill roles when somebody was unavailable. For instance, when I couldn’t organize the retrospective, anybody on my team could take over confidently.

Before You Bounce: Recap

Managers, at the most basic level, are in the business of information management: collection, summarization, and distribution. Thinking intentionally about your communication infrastructure is part of that role. Here’s what we covered:

1. Identify your recurrent conversations.

2. Forget about the tools and design protocols that are conducive to supporting healthy behaviors and the values you would like to see in your team.

3. Write it down; you will evolve it over time.

4. Automate as much as possible - do not rely on memory or people’s ability to be organized and disciplined, including yours.

5. Set general rules for what to do, when, and where (Consider this as a README for your team).

6. Discuss the protocol often to check if people find it helpful and change them accordingly.

“Communication is the real work of leadership.” – Nitin Nohria, former dean of the Harvard Business School.

I would love to hear about your firsthand experiences - what specific protocols have you implemented in your team? How have they influenced the communication dynamics? Were any particularly successful or not as effective as you hoped?

I started my first job as a software engineer in the early 2000s, and since then, I’ve been part of 9 different teams in companies of all sizes, including my own, and every single time, at some point, we would have a conversation about OKRs.

At first, I was open and equally skeptical about trying it. I was open because, in principle, the idea feels sound: you have concrete objectives, and you have to implement measurable ways of tracking their progress. But, I was still skeptical, the same way every software engineer knows that just because a big, famous company implemented something and worked for it, it doesn't mean it will make sense for your team. Still, in the spirit of being a good team player, I, most of the time, went along with it.

I noticed that most of these OKR conversations happened when either the team was growing and communication seemed to be breaking or when a new manager would experience pressure from the top to justify priorities or improve alignment. 

What I found fascinating about these conversations is that we rarely took the time to debug our underlying issues. Instead, we'd quickly commit to a new way of conceptualizing work. 

I know some of you reading this post may have had great experiences with OKRs, so my goal here is to share arguments as to why I strongly believe OKRs do not work for engineering teams. If OKRs worked for you, please share the specific context that made them work for you in the comments. That way, we all learn from each other. Deal?

Here’s why OKRs do not work for engineering teams

Incompatibility with Agile principles

Notice I’m referring to Agile, not Scrum (I’ll leave my Scrum disappointment for another post). Agile is about prioritizing adaptability and iterative development. In most companies, OKRs are done on a quarterly basis and assume goals will not change based on new customer insights, market changes, or technology breakthroughs.

When it's your turn, you get to break down individual goals that are often only tangentially related to customer needs (if at all), and you have to achieve them no matter what, especially if they are tied to bonuses, etc. In my experience, most people set up easy-to-achieve goals and forget about them until they have to revise them again before reviewing and setting new ones. 

It feels like assigning story points to “issues.” It is an imaginary exercise to try to control what you know you can’t control—estimating effort. OKRs that rely on accurate estimations can set teams up for failure or, conversely, set the bar too low. Good luck if one of the objectives depends on another team (or external factors). 

Potential for Shortcutting and Technical Debt

The pressure to meet aggressive OKRs can lead to taking shortcuts, especially when they're tied to compensation. People will take care of themselves first; if you ask people to set up a goal in exchange for money,  they will achieve it whether it is good or not for the users, the code base, and the business.

Another scenario involves working just for the sake of work - it happened to me: one of my goals was to add a new provider to an existing billing system. When I asked why, I was told that we needed to get it done because it’s part of my goals, and the product needs to support more billing providers. I was confused; if this were a priority driven by customer demand, it would be a part of our regular work stream, and we would have a clear reason for it. Instead, we ended up with half-baked code that would not survive first contact with a real user. But I got my goal done, so we’re all good, right? 

Making learning a key result

While companies invest in various software tools to track OKRs, these tools don't necessarily track learning. The point of having goals is to create a sense of direction, but as we move along the path of trying things, as we experiment, we learn things that may challenge the direction altogether. OKRs are not about challenging the goals. Instead, they are about ticking a box. 

But as you’d expect, learning ends up being one of the things that do end up being a part of OKRs. I’ve seen this firsthand when a person had to do a presentation about a piece of infrastructure they weren’t familiar with. That’s perfectly fine because they were interested in it and expanded the team's knowledge, but… how did that exactly fulfill the objective? Which was... Well, I’m not sure what it was exactly, something about making the team “better.” But what if that person did a presentation and got it all wrong? How do we score this? 50%? There was a result, but did their manager actually care about this? 

Learning is a continuous process; it’s not something that happens because it’s being measured.

Before I wrote this post, I was curious to see what information was out there on OKR and engineering teams. As I expected, 99% of the articles supporting OKRs were written by companies selling OKR consultancy or tracking software. Fair enough, but if you search where the conversation is happening (Slack channels, Reddit, Hacker News, etc.), you quickly find that the general sentiment is one of disappointment and frustration, at least for the ones who shared their stories.

A lot of it comes down to the fact that OKRs are pushed down to the individual, and because of that, the “vagueness factor” explodes and makes people feel like it’s a complete waste of time. 

According to Rick Klau - you’re supposed to set OKRs on a team level. Okay, but then… doesn’t it mean that the problem got shifted one level up, and whoever manages the team is now responsible for the OKR? It smells like a bad case of “you’re holding it wrong.” 

The business world is filled with this type of theater, where teams adopt the latest best practices that work within a very specific context, and then behind the curtains, we all tell each other what a waste of time it was. Most of the time, teams have no power to change the fact that OKRs are part of their organization; perhaps we should push harder. 

But Lukasz, how do I align my company/division/team/people with the business goals?

Go back to first principles. Alignment is mostly a problem with communication and how decisions are made. I always look there first before implementing any framework or process. Talk to people, seek the truth, eliminate fear within the team, find what is confusing, and try to solve that. OKRs can wait.

What we need is getting better at managing technical debt, shipping fewer bugs, improving customer satisfaction, reducing attrition, developing new features, staying competitive, and more. 

If you’re a leader - your job is to ensure that anybody in the organization knows where they are going. 

There are millions of things to rally people around; attempting to translate the broad statement “We are a business and need to make more money” into a cascade of detailed goals and then assuming that this process achieves true alignment is misguided.… It ain’t gonna work out. 

“The best companies don’t cascade goals; the best companies cascade meaning…Our people don’t need to be told what to do; they want to be told why.” 

- Marcus Buckingham, author of Nine Lies About Work 

I think it is fair to say that the vast majority of engineering managers have been through this experience at least once in their careers:

At some point in your life, you may have joined a well-functioning team. However, one day, without seeking your opinion, the top leadership decided that the planning, reporting, and communication processes were no longer working and needed a complete overhaul.

Suddenly, there is a plan to move from methodology/tool/approach A to methodology/tool/approach B. 

As soon as it was communicated, you knew that the changes didn’t make sense, and you found yourself thinking whether it was worth pushing back at all or just going along even though you knew those changes were no good for your team.

Going along feels like a defeat, but fighting for what’s right can bring all sorts of headaches you may not be willing to endure.

What can you do after all? 

When these top-down changes happen, and they don’t make sense to your team, it is easy to default to survival mode, which sounds like this: “I know this does not make sense, but we need to do it anyway.”

Few engineering managers understand the demoralizing impact of surrendering to changes that do not make sense at the team level.

While company-wide initiatives can influence behaviors over the long term, it's the immediate team environment that most directly impacts an individual's day-to-day work, performance, and engagement. What your team does and how your team works largely determines their daily experiences.

So what can you do?

You protect what makes your team work well, regardless of company-wide decisions. 

Under the Umbrella: Micro-interactions

Back in 2021, when our startup was acquired, our team had to adopt the acquirer's project management tooling. Before that, we had our own way of working that kept us efficient and fit into our framework of bets and small projects. But suddenly, we found ourselves in the confines of Jira and using points for estimating tasks. A practice that some of us hadn’t done for over ten years at that point.

Presented with a major disruption to how we were working, I was concerned about momentum and team morale; at that moment, I decided to become an umbrella and shield the team from unnecessary changes. 

We still had to adopt the new system, but I could try to make this transition as easy as possible. I said to the team the following: “We would use Jira (because other systems are connected to it, so we get the benefit of that, rather than being an isolated island), but for all intents and purposes, we will use it just like we used our old system.” 

The team feared that they would be held accountable for missing our “commitments” and fall into a rigid system of trying to play Tetris with the backlog and fit tasks within allocated sprint points. I removed that fear by assuming the responsibility of having those tough conversations with other stakeholders instead of dragging the team into endless meetings about why the approach didn’t work for us.

Points are imaginary numbers anyway, and we all know it. So, as long as we kept our old momentum, we were good, and we could tick off a box and not spend too much time thinking about it.

Here’s another example of how to be an umbrella for your team from the perspective of engineers working within a team. I found this while reading a thread on startup momentum on Hacker News (HN).

“I really like the approach of Netflix 10 years ago when it was still small. They hired mature people so they could get rid of processes. Indeed, they actually tried to de-process everything. As a result, things just happened. Non-event was often mentioned and expected on Netflix at that time. Case in point: active-active regions just happened in a few months. A really easy-to-use deployment tool, Asgard, just happened. The VP of CDN at that time said Netflix would build its own CDN and partner with ISPs. Well, it just happened in merely six months with 12 people or so. Netflix said it was going to support streaming and move away from its monolithic Tomcat app, and it just happened. And the engineers there? I can't speak for others, but I myself had just one meeting a week -- our team meeting where we just casually chatted with each other, to the point that the team members still stayed close to each other and regularly meet nowadays. I also learned that the managers and directors had tons of meetings to set the right context for the team so engineers could just go wild and be productive. At that time, I thought it was natural, but it turned out it was a really high bar.”

Team leaders and the immediate team environment shape a lot of what matters in an employee's work life, such as attention to strengths, clarity of expectations, and feedback frequency. This micro-environment often trumps the broader organizational culture.

Within this team micro-environment, a.k.a. Underneath The Umbrella, you can find an infinite set of micro-interactions that matter and impact people more than any other organizational strategy. A micro-interaction in this context is something you say or do that solidifies or reinforces the values and practices that make your team great. For example:

The language you use to provide feedback says much about what matters to you as a leader. 

How you run meetings directly reflects your value for other people's time and sets an example for how they should conduct their meetings.

Does everybody get a chance to speak during calls, retrospective meetings, etc.? That tells the team how individuals are valued and how much their contribution counts. 

As a leader, you evolve the team by taking care of the small interactions and designing the communication rituals and channels that glue the team together and reinforce trust.  

Engagement, which is a significant predictor of productivity and satisfaction, is more closely tied to the immediate team than to the company as a whole. Team members feel more connected to their close colleagues, and their immediate team leaders play a significant role in determining their level of engagement.

For instance, consistently having 1:1s with team members is more important than the quality of the conversation itself. Yes, that’s right. Good 1:1s are developed over time; open and direct communication only happens when people feel safe. 

The fact that you consistently have them says a lot about how important these conversations are for you as the leader, even if they are uncomfortable or not as productive as you would like them to be.

1:1s are sometimes the only way to discover issues you need to shield the team from; the same applies to retrospectives. 

Paying attention to the small interactions happening every day within your teams is the superpower of any team leader that understands that the team is the most important unit. 

Broader organizational changes may need to be adopted, but paying attention to micro-interactions is what will help your team survive and thrive despite any company-wide change. While company values and culture are essential, day-to-day interactions at the team level have a more significant influence on an individual's work life.

When decisions and changes come from the top with little context or regard for individual team needs, it is important to remember how powerful you are as a leader within your micro-environment.  

A good team leader makes a substantial difference in the team's outcomes and the experiences of its members. Don’t relinquish that power, embrace it.

If you ask any team if they trust each other, they would probably say they do, especially if they worked together for a longer period of time.

There is an abundance of teams that seem to have a good time working together but that continuously deliver unsatisfactory results. Trust can often be confused with getting along or having a sociable work environment. Having fun together can be a sign that team members trust each other, but it can also be deceiving. 

Trust is a leap of faith, a decision to rely on another's actions and intentions. It’s also an emotionally laden process. 

I have worked with many teams that got along well but moved very slowly or lacked a sense of purpose, motivation, or even pride in execution. These teams smiled every day, but deep down, they knew that things could be better; however, avoiding conflict is the default mode. These environments may yield friendships but not career satisfaction. What united the team was not a sense of productivity but the feeling of being stuck together. This might work in the short-term times of crisis, but it is not sustainable and leads to burnout and attrition. 

Back in the mid-00’s, I worked for a small yet fast-growing tech company in the UK. The engineering team was small, maybe ten engineers at the time, and I fondly remember those times. We'd lunch together, organize mini-hackathons, and enjoy Friday drinks. We learned from one another and enjoyed the work challenges. Surprisingly, we rarely discussed the stagnation of our product.

We felt trapped without a clear direction or vision. Each week mirrored the last, offering a familiar routine but minimal progress. No one was eager to address the elephant in the room; we merely wanted a pleasant workspace. We were deluding ourselves. The lack of a clear vision, combined with our inability to discuss pivotal issues, was ultimately demoralizing. Gradually, I sensed my growth stagnating, and I believed others felt similarly.

While we liked one another, we lacked the trust to discuss the hurdles impeding our progress openly. On the rare occasions when we broached serious issues, tensions flared, it was common to see colleagues who were either upset, resistant to change, or close-minded. It became too challenging. I eventually left. I left with a sad feeling that everything could have been so much better if we just trusted each other and took a leap of faith. 

That wasn’t the first (or the last) time I was part of a team with similar issues.

It is in times of conflict and pressure that you discover if your team has cultivated trust among each other. You know there is trust within your team when everybody can speak their minds, challenge decisions, and express their feelings without fear of retaliation, being fired, or just being disliked by the rest of the team.

Trust is when you let people take ownership without you having to chase them or micromanage them. Trust is when you disagree with a particular approach, but you let people, the experts, try things anyway because you are humble enough to know you can be wrong. 

Trust is letting people fail gracefully and helping them do better next time.

Trust is built by following up with every request, every comment, every idea, even if it is to say no. By doing what you said you would do over and over again.

It always starts with you. Be the first to say what others are afraid of sharing. Be the one that shows up consistently and delivers work that inspires others. Be the first one to admit failure and share solutions.

It doesn’t take much to build trust; what's hard is doing it consistently. 

I think it is fair to say that at this point, we all know that the stereotype of an engineer coding in a dark room, burning the midnight oil, has become painfully outdated and ridiculous. However, what we haven't internalized in the industry quite yet is that engineering productivity is less about standardization, dashboards, and metrics and more about a real sense of autonomy.

The truth is that most productive engineers normally look like they are not working much.

Let me tell you about Anna. I worked with this great backend engineer for over seven years; let’s call her Anna to maintain anonymity. She would usually join a quick standup from her phone. She was normally at the playground with her kids, having a good time and getting them ready for the day. Then, she would go quiet for the rest of the day unless we had specific team calls. However, in the evening, we would see a bunch of activity from her show up on Github and Slack. 

I remember at the beginning, I would be concerned that she was working in the evenings, perhaps having trouble with the workload, but I quickly learned that she loved it. Anna told me that she would find peace and quiet after the kids were in bed, and she would get in the flow until she decided to stop. It was not only during the evenings that she was active; during the day, she would revise docs, add comments, and review stuff for other team members. She was not burning the midnight oil; she was effectively chunking her time and would reserve the evening for the more challenging problems.

She also didn’t need to join every standup; we were fully distributed, so we would have asynchronous check-ins in case people couldn’t make it. Anna had control of her day, and she prioritized her life and kids over work. As a consequence, she could do much better work when she sat down to do it. It was done her way at her time. She didn’t have to pretend she was working when she wasn’t. 

She was great at communicating, very direct, and not afraid of flagging any issues. Anna never let the team down; she would set expectations on when things would get done and just do it.

Tasks were completed on time; she always came up with great solutions and identified problems proactively. Anna also took time off often, and she was always upbeat. 

Anna was not the only one; the rest of the team had different routines, but they all had the same in common. They would prioritize life over work, do stuff when they felt they were most productive, and communicate openly about issues or blockers. 

The team knew what to do; it was me, as a manager, who needed to understand how to stop trying to control how people worked. My job was to coordinate, guide, help, coach, and listen, not control.

Most engineers, like everybody else, are trying to get enough sleep so they can function the next day. At least 40% of them have children, which involves efficiently preparing for the day in the morning and, if lucky, finding time for a workout. 

On average, software engineers are in their late 30s-mid 40s, meaning many would have elderly parents requiring their attention. Regular life is full of all sorts of chores and appointments. We get tired; we get ill; we need time to rest, time to play, and time to learn.

The most productive engineers I know take care of themselves. If you are an engineering manager, you have to help them do that.

Yes, there will be times when this sense of freedom will bite you back. There will be this one engineer who, no matter what you do, will not pull their weight, and there will be people who struggle with communication and time management, but that should not be the reason for you to optimize your culture and systems around those who are not delivering. 

Find out what the problem is, use your 1:1s to understand what makes people tick, and build a system that helps empower those who thrive with autonomy while simultaneously developing strategies to help those who are still struggling. 

Don’t punish everybody because of the few.

If you're still skeptical about how rest and autonomy can enhance your team's productivity, we recommend a couple of excellent books filled with scientific research on the topic.

Do Hard Things: Why We Get Resilience Wrong and the Surprising Science of Real Toughness by Steve Magness

Life Profitability: The New Measure of Entrepreneurial Success Kindle Edition by Adii Pienaar

Rest: Why You Get More Done When You Work Less by Alex Soojung-Kim Pang