Why Reorganizations are the Kryptonite of Productivity, Product Engineering and well-gelled Teams

Stable organizations might appear slow. But smooth means fast.

Welcome to the Captain’s Codebook newsletter. I'm Ilija Eftimov, an engineering manager at Stripe. Each week (or two) I write a newsletter article on tech industry careers, practical leadership advice and management how-tos.

An engineer's career maturity

When starting my first job, my only goal was to become productive, 'grow up', and be financially independent of my parents. Looking back on that journey to becoming a productive engineer, I can identify different phases. Over my decade in the industry, I've had to go through these phases repeatedly. I'd wager that the journey starts as a 'Novice' and "ends" as a 'Visionary'. Visually:

As a new engineer in my first job, I was a novice. A couple of years later, I thought of myself as 'senior' (or proficient). Still, now I know I was merely becoming intermediate. It took me another few years to feel (and truly become) proficient, but that proficiency was mainly limited to the context of my first job. Getting to the 'Expert' level probably takes another 7 to 10 years. And that was assuming I would stay on the same job for that time. The alternative is to have a mentor(s) and get the opportunities to learn and grow in other companies. Which I luckily did.

At my second job, I was indeed 'Proficient'. But even though I felt good about my abilities, I couldn't start at the 'Proficient' level in my next job, especially because it was only my 3rd job. I "degraded" to 'Intermediate', but once I onboarded and got a solid grasp of the business, I climbed back up to 'Proficient' within a year or so.

Even though we can take all our knowledge, dotfiles, and notes to the next job, moving jobs is never easy. Gaining expertise takes time. It requires context, knowledge, connections, and user insight. Getting to the 'Expert/Leader' level is even more difficult. It often requires execution through others, which requires a very different set of skills that most software engineers only start grappling with after a ~decade in their careers.

Proficiency

To be a proficient contributor, every engineer needs a good balance of the relevant skills. I would summarize the necessary skills in the following buckets, in no particular order:

• Ability to navigate the organization. Understanding of ownership, the decision-making centers, where the experts congregate, how to reach them, etc.

• Relationships. Engineers must have good relationships with their team, other engineers, PM and EM, cross-functional partners, etc. Simply put, they should be on good terms with everyone they're working with.

• A user-first mindset. The ability to empathize with and think like the user and articulate the user's friction with the product.

• Product strategy. Understand how the product differentiates from competitors. Look for gaps and shortcomings. Look for opportunities. Where will the product be in 2-5-10 years?

• Solid command and understanding of the tech. This spans beyond the tech stack or the programming language. It's understanding of the company's software development lifecycle, how to deploy, source code versioning, data warehouse, observability tooling, etc.

• Autonomy, accountability, and dependability. The ability to shape features, articulate user needs, plan projects, lead people, execute, deliver quality, and keep the bar high—all that without needing someone to look over their shoulder.

All of these are difficult to acquire. After joining a new company, engineers need months, if not years, to begin building for their users. Learning to navigate the organization requires someone to fly the engineer's flag. Building a relationship cannot be rushed—it takes time, effort, empathy, and respect. By using the product, an engineer can adopt their users' mindset. But they also need to talk to their users by reading feedback or participating in user calls.

You get the picture - becoming proficient is difficult. It requires consistently working hard over an extended period. That's why highly proficient engineers are worth their weight in gold. These are context-heavy skills that, once fully materialized, make the engineer an unstoppable value-creation machine. They must be given the room to acquire the skills and use them to become deep product and technical experts, leading and growing other engineers around them.

Reorgs debilitate engineers

Managers think that reorganizations are a good way to refresh the organization. Reorgs realign teams against new business priorities. Or, they're an easy way to handle people dynamics (e.g., new leaders being convinced they know best). Wrong. Well-designed organizations age like fine wine. They don't need a reorg to get refreshed. They get refreshed due to their success by adding new people to their bloodstream and further growing their success.

If an engineer needs at least a year to fire on all cylinders to become a true domain expert, reorgs stifle that growth. They interrupt continuity. Changing teams is stressful for people. It forces the engineer to change their environment. Even in cases where there are no team changes, but teams only absorb new domains, significant stress is still incurred. And don't even get me started on the fatigue reorgs create.

To engineers, reorgs are horrible. They make engineers lose time and energy in handing over ownership of services or processes. Some reorgs kill projects or efforts that the team(s) was previously working on. In the waste that reorgs cause, ownership of some components or services is often dropped or forgotten about. Expertise is lost. When some projects get defunded, engineers get frustrated, disappointed, and leave.

To some extent, it's easier to trade off organizational dysfunction for a stable environment where product teams can create value for the customer and the company.

Loss of Institutional Knowledge

When engineers are shuffled around, institutional knowledge is lost. Documentation might be missing or stale. Engineers develop deep understanding and intuition that is difficult (impossible?) to document. Examples include their systems' behavior, product quirks, workarounds, long-running user friction, and historical decisions. Or why that one feature that you think makes sense to exist doesn't.

Like losing personal things when moving houses, context is lost when moving people in an organization. Engineers don't lose it on purpose. They focus on what's in front of them: the new domain or technology required to succeed in their team. New knowledge replaces old.

However, this old context and knowledge are crucial for efficient problem-solving and innovation. The context within which a product was built is messy. It's a skein of thousands of decisions over the years. The ones that survived the test of time can be seen in the code. But the things that didn't survive the wrath of the user and the lessons they brought - will be lost.

This context is a long-running thread running through the product's fabric. Reorgs are the scissors.

Erosion of Trust and Loss of Talent

Every time organizational lines are redrawn, one thought pops into everyone's mind: am I gonna have a job after this is over? When engineers feel that their job security is threatened or that their contributions are undervalued, it leads to a decline in trust, morale, and engagement, thus making it harder for leaders to motivate their teams. Innovation happens in gelled teams based on trust and respect. If a reorg damages this trust, it will take a long time to rebuild the connections, the grit, the confidence, and the productivity of the teams.

The most significant downside of reorgs is the potential loss of key talent. Engineers who feel unsettled by the changes or disagree with the organization's new direction may choose to leave. The primary effect of people leaving is the loss of valuable skills and knowledge. However, there are secondary effects, such as the domino effect—when key individuals leave, others become demotivated and choose to go. The remaining who decide to stay will certainly not feel the psychological safety they once could contribute to.

Dilution of Expertise

Another side effect of reorgs is the dilution of specialized skills and knowledge. While the reorg attempts to diversify skills or align with new strategic directions, engineers find themselves in roles or projects that do not fully utilize their strengths or areas of expertise. Some engineers get reassigned to different parts of the organization where their skills are not critical. Such misalignment again leads to frustration, as the engineers cannot fully use their skills and knowledge.

A new team configuration integrates members from different backgrounds or experience levels. This, too, can dilute the core expertise of the group. Newer members require time to ramp up, slowing the progress of projects that rely on deep technical knowledge. This is not to say that mentorship is bad; it's, in fact, great, but leaders must consider whether the time is right and whether the team can support it.

Niche areas of expertise might not be considered critical in the new organizational lines. Engineers with niche skill sets might be overlooked and feel undervalued. Lack of recognition impacts the motivation of the experts in these areas. If these experts leave, the organization will be vulnerable in these specific, potentially critical aspects of its operations.

Increased cognitive load

When an engineer works in a familiar environment, the cognitive load coming from the environment is minimal. Coming to work remotely or in the office feels like being in the groove. The people are familiar. The problem area is known. Relationships with stakeholders are established. The team is gelled. All that's left is to execute.

When the organizational line changes, the environment increases the cognitive load. Engineers in the organization must adjust to their new roles; with every team member added or removed from the team, the team dynamic changes. It's like a barely new team. In reorgs, ownership lines change occasionally. When a team takes ownership of a new service that uses a different technology, additional friction, and cognitive load is thrown on the engineers.

All of these ways of adding additional mental effort detract engineers from executing at their highest capacity. When mental bandwidth is spent on fitting into the new environment, there's less mental bandwidth for engineering work. Engineers are not able to apply their best skills to the problem, which slows down the team's rate of innovation and the individual's personal development.

Cultural realignment

The increased mental load is felt the most when a newly restructured team needs to gel. Newcomers to the team need to learn the ways of the veterans—all the idiosyncrasies, the standups, the planning sessions, how they do retros, how they disagree, what's allowed to say or not, and when it's generally accepted to call meetings or to call it a day.

Yet, the veterans will observe the dilution of established norms and practices. The team flourished on these norms for [TIME], yet now they have these newcomers that they need to onboard and show them the ropes. It's a predicament. These cultural shifts affect how knowledge is shared in the team, how the decisions are made, and even how risks are taken.

This all leads to a less cohesive work environment, in which the manager and the team must completely realign.

---

And that’s it for this issue! If you liked this, consider doing any of these:

1) ❤️ Share it — Captain’s Codebook lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!

2) ✉️ Subscribe — if you aren’t already, consider becoming a subscriber. Seeing folks read the newsletter energizes me and gives me ideas to write.

3) 🧠 Let’s chat — I am always on the lookout for questions to answer, to help out with challenges, or topic ideas to cover. Hit me up on LinkedIn, Twitter or send me an email to blog@ieftimov.com.

Until next time,
Ilija