DEV Community: Eduardo Klein

Conflict Resolution and the Escalation Trap

Eduardo Klein — Wed, 12 Nov 2025 03:47:02 +0000

Have you ever noticed how a small disagreement can spiral into a massive conflict? A minor miscommunication escalates into heated arguments? These are examples of the escalation trap, a concept rooted in systems theory that shows how seemingly minor actions can trigger reinforcing feedback loops, amplifying problems far beyond their original magnitude.

In this post, I explore the escalation trap and how de-escalation — a critical soft skill often overlooked in professional environments — can break these destructive cycles.

What is the Escalation Trap?

The escalation trap is a reinforcing feedback loop where one party's action triggers a reaction from another party, which in turn prompts a stronger counter-action, creating a self-amplifying cycle of conflict and tension. Unlike balancing feedback loops that tend toward equilibrium, escalation loops push systems toward extreme states.

In Thinking in Systems, Donella Meadows explores how systems are governed by feedback loops. The escalation trap is a specific type of reinforcing feedback loop (also called a "vicious cycle") where each action amplifies the system's tendency toward conflict. The more a person escalates, the more another one feels justified in reacting back, and the cycle accelerates, leading to outcomes neither party originally intended.

A good example of quick escalation is a traffic conflict. One driver unintentionally cuts off another, who gets angry and honks and yells. If both parties become angry and allow themselves to escalate, the conflict may quickly lead to physical threats and violence. On the other hand, the ability to de-escalate may quickly resolve the issue, allowing everyone to move on in a matter of seconds.

Extreme examples include arms races by nuclear powers and quick escalation of violence between religious groups or soccer fans.

A Simple Business Example

Imagine two engineering teams in a tech company: the backend team and the frontend team.

Day 1: The frontend team reports a critical bug in the API response format. The backend team, feeling blamed, responds defensively: "The API is correct. The frontend team isn't using it properly."
Day 3: The frontend team, frustrated by the dismissal, reacts by escalating the issue to their engineering manager and labeling it as a "critical blocker."
Day 5: The backend team's manager intervenes, escalates back by questioning the frontend team's technical competence in a larger meeting.
Day 7: The conflict has now involved senior leadership, created tension between teams, slowed down product development, and damaged working relationships.

What started as a technical issue evolved into an organizational conflict through escalation. Neither team is malicious; both believed they were defending their interests. Yet the system's structure trapped both teams to an outcome worse for everyone.

This reflects what Meadows describes as a fundamental principle of systems: the structure of the system determines its behavior. The escalation trap emerges from a system where actions trigger defensive counter-actions, creating reinforcing loops.

The Cost of Escalation

Escalation may get expensive, both emotionally and economically:

Emotional toll: Stress, anxiety, and reduced morale spread through teams
Productivity loss: Energy spent on conflict diverts from productive work
Relationship damage: Trust erodes, making future collaboration harder
Poor decision-making: When threatened, people make defensive rather than optimal choices

De-escalation: The Way Out

The antidote to the escalation trap is de-escalation — the intentional action of reducing tension and breaking the reinforcing feedback loop. Rather than matching escalation with escalation, de-escalation introduces a balancing feedback loop that reduces conflict and creates space for resolution.

De-escalation is not a weakness. It's an important skill and an strategic choice to interrupt the negative spiral and create conditions where problems can be solved effectively.

De-escalation operates by changing how you respond to provocative actions. Instead of triggering the next loop in the escalation cycle, you can respond with:

Calm language and tone: Signals that you're not a threat
Empathy and understanding: Shows you recognize the other party's concerns
Acknowledgment: Validates their experience without necessarily agreeing
Collaborative framing: Shifts from adversarial ("you vs. me") to cooperative ("us vs. the problem")
Clear boundaries: Maintains respect without aggressive defensiveness

Traffic conflit resolution

Let's further explore the traffic conflit I previously mentioned. Consider both scenarios:

Without de-escalation:

Driver A cuts off Driver B
Driver B honks angrily
Driver A, feeling attacked, slows down intentionally
Driver B becomes furious and makes an obscene gesture
Driver A, now enraged, escalates further
Both drivers are now in a dangerous situation, risking accidents, injuries, or worse

This is the escalation trap. Two reasonable people became dangerous through escalation.

With de-escalation:

Driver A cuts off Driver B
Driver B, though frustrated, takes a breath and assumes an honest mistake
Driver B doesn't honk; instead, gives a brief, friendly wave
Driver A, recognizing their mistake, appreciates the grace and waves back
Both drivers move on, and everyone arrives safely

In the second scenario, Driver B made a strategic choice to de-escalate. By not matching Driver A's error with aggressive honking, Driver B broke the escalation loop. The result? Safety, reduced stress, and everyone moving forward.

Backend and frontend teams' de-escalation

Now, let's also return to our earlier example of the backend and frontend teams, but imagine a de-escalated version:

Day 1: The frontend team reports a critical bug in the API response format. Instead of becoming defensive, the backend team responds: "Thanks for reporting this. Let's schedule a quick call to understand what you're seeing."
Day 2: Both teams meet. The backend team listens carefully to the frontend team's concern. They discover the issue stems from a misalignment in expectations, not malice. Both teams contributed to the confusion.
Day 3: Together, they create a solution: updated documentation, a quick API adjustment, and agreed-upon communication protocols for future issues.
Result: The problem is solved faster. Relationships strengthen. Trust is built. Both teams learned something. The organization benefits from improved collaboration.

Developing Your De-escalation Skills

De-escalation is a learnable skill. Here are practical ways to develop it:

Develop Self-Awareness: Before you can de-escalate others, learn to recognize your own escalation triggers.
Practice Pause and Breathe: The most powerful de-escalation tool is the pause between stimulus and response.
Listen for the Underlying Concern: Escalation often masks deeper concerns: fear, feeling unheard, loss of control.
Assume Positive Intent: Most escalation happens when people assume the worst of each other. Always assume the best intentions from other people.
Use Calm, Cooperative Language: Words shape people's behavior. Choose them wisely.
Validate Before Disagreeing: When people feel heard, they're less likely to escalate.
Seek Common Ground: Escalation thrives on division. De-escalation thrives on cooperation.
Know When to Step Back: Sometimes, the best de-escalation is recognizing when continuing a conversation will only escalate further.
Build a Culture of Psychological Safety: De-escalation works best in environments where people feel safe being vulnerable.

Conclusion

The escalation trap is a fundamental pattern in systems: small actions trigger reinforcing loops that amplify conflict and drive systems toward destructive extremes.

De-escalation is the lever that interrupts this trap. By choosing calm over defensiveness, empathy over blame, and collaboration over adversarialism, you don't just resolve immediate conflicts—you transform relationships.

Businesses are typically high-pressure environments focused on delivering results and meeting ambitious, often uncertain deadlines. Management deliberately introduce some level of conflict and pressure to drive performance. In this scenario, avoiding the escalation trap is no easy task. It demands both skill and intentional action.

Leaders who understand de-escalation become invaluable. They transform potential crises into opportunities for strengthening teams and improving outcomes.

The next time you're in a conflict — whether with a teammate, customer, or leader — pause and ask yourself: "Will my next action escalate or de-escalate this situation?" Choose wisely.

Problem-Solving in Software Engineering

Eduardo Klein — Mon, 27 Oct 2025 02:38:54 +0000

Problem-solving is at the heart of software engineering. Whether debugging a production issue, designing a new system, or optimizing performance, the ability to approach challenges methodically and effectively distinguishes exceptional engineers.

In tech companies, where complexity scales rapidly and novel challenges emerge daily, strong problem-solving skills are non-negotiable. Yet, for many engineers, it is challenging to define what "good" problem-solving looks like or how to develop these capabilities systematically. Without a clear framework, it's difficult to assess growth, identify development areas, or set meaningful career goals.

In this post, I share my perspective on the varying levels of problem-solving competency for software engineers within tech companies. By breaking down this skill into actionable levels — from beginner to expert — I aim to provide a framework that software engineering managers (SEMs) can use to assess and develop their team's problem-solving capabilities.

This is similar to the work I've previously done for Effective Communication, which I'll compile with other skills at some point in the future into a guide for software engineering competencies.

This structure can be integrated into career ladders, supporting personal development and career progression. It can help engineers identify growth opportunities and set clear goals, fostering an environment where challenges are approached confidently and systematically, and product development thrives.

Problem-Solving Expectations and Levels

To make problem-solving more tangible, I will describe it through five dimensions:

Framework and Tool Proficiency: Masters a variety of frameworks, tools, and libraries commonly used to solve engineering problems, enabling efficient and effective solutions.
Coding and Design Craftsmanship: Demonstrates the ability to craft elegant, efficient, and maintainable code solutions through the thoughtful application of algorithms, data structures, and design patterns.
Architectural Understanding: Develops architectural solutions that address complex system requirements and integration challenges, ensuring scalability, reliability, and maintainability.
Analytical Thinking: Breaks down complex problems into smaller, manageable parts and systematically approaches their resolution using appropriate strategies.
Continuous Learning and Practice: Engages in continuous learning to acquire new problem-solving methods and improve existing skills through regular practice and exploration of emerging technologies.

I try to establish adequate expectations for each level and provide evidence and examples.

Beginner

Framework and Tool Proficiency: Understands basic functionality and can utilize frameworks and tools with guidance.
Coding and Design Craftsmanship: Demonstrates awareness of fundamental algorithms and data structures. Writes functional code that follows team standards and applies simple design patterns in straightforward scenarios.
Architectural Understanding: Has a basic grasp of software architecture, focusing mainly on individual components rather than the system as a whole. Follows architectural guidance and design decisions made by more experienced engineers.
Analytical Thinking: Breaks down simple problems and identifies potential solutions with some guidance.
Continuous Learning and Practice: Actively seeks out learning resources and begins incorporating them into daily practice with regular mentorship.

Evidence

Completes tasks with low assistance
Proactively seeks support in the face of obstacles
Asks questions to clarify problem requirements and solution approaches
Attends and participates in training sessions and workshops on frameworks and tools
Engages in regular code reviews and refinement sessions to learn from more experienced engineers
Approaches feedback received in code reviews with an open mindset

Example

An engineer who regularly consults with peers or a mentor while working on projects, asking for advice on which design patterns and tools to apply, and uses tutorials to understand the basic functionality of frameworks and design patterns.

Competent

Framework and Tool Proficiency: Comfortably uses common frameworks and tools to solve routine problems efficiently.
Coding and Design Craftsmanship: Crafts readable, modular code for moderately complex projects by thoughtfully selecting appropriate data structures, algorithms, and design patterns while ensuring adherence to team conventions.
Architectural Understanding: Understands basic architectural principles and can contribute to discussions on system components and their interactions.
Analytical Thinking: Analyzes problems effectively, proposing logical solutions and alternatives.
Continuous Learning and Practice: Regularly updates skills with new techniques and frameworks, integrating them into work processes.

Evidence

Independently solves problems using standard frameworks and tools
Successfully applies design patterns and can effectively explain their benefits
Actively participates in team discussions about architectural decisions
Provides logical reasoning for chosen solutions to problems
Enrolls in courses or reads books on software development topics

Example

An engineer who efficiently utilizes existing frameworks to build new features, chooses design patterns that optimize performance, and contributes meaningfully during team architectural discussions.

Proficient

Framework and Tool Proficiency: Proficiently navigates and adapts frameworks and tools to address complex problems. Identifies gaps in current tools and introduces improvements when necessary.
Coding and Design Craftsmanship: Chooses appropriate design patterns, data structures, and algorithms, and proactively refactors existing codebases to improve maintainability and performance.
Architectural Understanding: Contributes to the design of system architectures and can foresee the implications of architectural decisions.
Analytical Thinking: Proactively identifies potential problems and implements effective solutions before issues arise.
Continuous Learning and Practice: Actively seeks out cutting-edge practices, integrating them into existing workflows and sharing knowledge with peers.

Evidence

Leads projects that require the use of advanced frameworks and custom tools
Conducts workshops on design patterns and tools and their real-world applications
Proposes architectural changes that enhance system scalability and reliability
Conducts thorough analysis and presents findings to influence strategic decisions
Creates custom tools or frameworks that are adopted across the organization
Contributes to technical blogs or speaks at conferences to share knowledge
Identifies architectural issues (e.g., scaling challenges) and suggests improvements

Example

An engineer who anticipates scaling issues, designs robust architectures, and implements advanced design patterns to optimize the system's performance while mentoring others on these approaches.

Expert

Framework and Tool Proficiency: Innovates and customizes frameworks and tools to create unique solutions for unprecedented challenges.
Coding and Design Craftsmanship: Masters design patterns, mentors their strategic application, anticipates maintainability challenges, and shapes engineering culture around algorithmic thinking and sustainable design.
Architectural Understanding: Architects complex, scalable, reliable, and maintainable systems, making strategic decisions that align with long-term company goals.
Analytical Thinking: Identifies systemic issues and implements strategic solutions that have a positive impact on product direction, overall efficiency, and user experience.
Continuous Learning and Practice: Leads the adoption of emerging technologies and practices, fostering a culture of innovation and excellence.

Evidence

Innovates and customizes frameworks and tools to create unique solutions for unprecedented challenges
Mentors engineers on using design patterns to solve complex problems
Develops and implements long-term architectural strategies
Leads cross-functional teams to solve high-impact problems
Publishes articles and papers or contributes to open-source projects
Sets technical direction that influences the entire organization and industry

Example

An engineer who architects technology strategies for the company, designing innovative solutions that set industry standards, while mentoring teams to elevate their problem-solving capabilities.

Conclusion

Problem-solving forms the foundation of effective software engineering. By focusing on these five dimensions, we can create a structured approach to developing these competencies within our teams.

Setting clear expectations for each level of problem-solving proficiency allows SEMs to guide their teams toward continuous improvement. Like building a utility belt of tools and techniques, developing problem-solving skills is an ongoing journey that requires deliberate practice and regular refinement.

This framework provides engineers with a roadmap for growth, helping them identify where they are, where they want to go, and what skills they need to develop along the way.

The traits and pitfalls in Software Engineering careers

Eduardo Klein — Tue, 05 Aug 2025 02:05:45 +0000

Over the years, I've seen software engineers grow from new hires to trusted technical leaders, but I have also witnessed many competent engineers stall out in their careers, stuck in patterns and behaviors that hold them back.

What separates those who thrive from those who plateau isn't just technical skill, but a combination of habits and subtle pitfalls that shape their professional journey.

As individuals, we need to be intentional about our career growth, and as leaders, we must provide our teams with clear paths to progression. Yet we often lack a practical model or reference point for this development.

The following lists represent my personal perspective on what truly matters in the software engineering career journey. If you're a Software Engineering Manager, I hope these traits and pitfalls help you assess your team during performance reviews and guide their skill development. If you're a software engineer, you might recognize patterns in your own work and discover concrete ways to advance your career.

These are the key signals I look for, and the common traps I've seen catch even the most talented professionals.

Software Engineer

A competent Software Engineer independently delivers well-structured solutions to defined problems, collaborates effectively with teammates, and demonstrates solid technical judgment within their area of responsibility.

Traits

The typical characteristics of a software engineer.

Proficient Coder: Writes clean, efficient, and testable code with minimal supervision.
Debugging Skills: Independently troubleshoots issues across the stack.
Basic System Design: Understands trade-offs in small-scale systems (e.g., database choices, API contracts).
Tool Mastery: Comfortable with team workflows (version control, CI/CD, debugging tools).
Team Player: Actively participates in code reviews, standups, and retrospectives.
Task Ownership: Delivers medium-complexity features end-to-end.

Pitfalls

Common pitfalls that prevent a junior engineer from becoming a competent software engineer.

Technical Skills

Shallow code reuse: Reusing code without understanding why it works, leading to fragile solutions.
Over-engineering: Adding unnecessary complexity to prove skills.
Testing neglect: Writing code without tests, assuming "it works on my machine".
Debugging dependency: Relying too heavily on seniors to solve tricky bugs instead of deep-diving.

Soft skills

Silent struggling: Wasting time stuck on problems instead of asking for help early.
Code review passivity: Approving PRs superficially, like “LGTM”, or not defending feedback constructively.
Task focus: Focusing only on assigned tasks without understanding the bigger picture.
Process subversion: Dismissing rituals, such as standups and retrospectives, as "overhead", instead of leveraging them.
Comfort zone stagnation: Only volunteering for tasks in known areas.

Senior Software Engineer

A Senior Software Engineer leads complex technical initiatives with minimal guidance, makes architectural decisions that balance technical and business needs, and actively mentors others while serving as a trusted technical authority within their team.

Traits

The typical characteristics of a senior software engineer.

Technical Excellence: Deep expertise in their domain (coding, debugging, system design).
Ownership: Accountable for projects end-to-end, including failures and maintenance.
Problem-Solving: Breaks down ambiguous problems into actionable solutions.
Mentorship: Guides junior engineers and fosters team growth.
Communication: Articulates trade-offs clearly to both technical and non-technical stakeholders.
Autonomy: Solves complex problems independently but knows when to escalate.
Code Quality Advocate: Ensures maintainability, testing, and scalability within their team.
Collaborative Leadership: Coordinates work across teammates (e.g., reviews, design discussions).
Tactical Decision-Making: Balances short-term deliverables with long-term tech debt.
Domain Specialization: Deep knowledge of their team’s systems and product area.

Pitfalls

Common pitfalls that prevent a software engineer from becoming a senior software engineer.

Technical Skills

Ignoring system design: Focusing solely on code without understanding broader architecture.
Prioritizing speed over quality: Sloppy code, tech debt, or ignoring long-term impact.
Stagnating technically: Not learning new tools, patterns, or domain knowledge.
Staying in the execution zone: Only completing tasks without designing solutions or questioning requirements.

Soft skills

Focusing only on technical skills: Neglecting leadership, communication, and mentorship.
Underestimating communication: Not documenting work, explaining trade-offs, or aligning stakeholders.
Avoiding collaboration: Working in isolation instead of influencing cross-team initiatives.
Neglecting mentorship: Not helping junior engineers grow or share knowledge.
Resisting feedback: Defensiveness instead of treating feedback as a growth opportunity.
Not thinking proactively: Waiting for direction instead of spotting and solving problems early.
Avoiding ownership: Not taking responsibility for projects end-to-end, including failures.

Staff Software Engineer

A Staff Software Engineer shapes technical strategy across teams, solves ambiguous problems with organization-wide impact, and influences engineering culture through technical leadership that extends beyond their immediate scope of work.

Traits

The typical characteristics of a staff software engineer.

Strategic Vision: Aligns technical work with business goals.
Influence Without Authority: Drives consensus across teams/orgs on high-impact initiatives.
System-Level Thinking: Designs architectures that span multiple services/teams.
Ambiguity Navigation: Thrives in unstructured problems with no clear "right" answer.
Breadth Over Depth: Connects dots across domains (e.g., product, infra, security).

Pitfalls

Common pitfalls that prevent an engineer from becoming a staff software engineer.

Technical Skills

Not thinking strategically: Failing to align work with business goals or long-term impact.
Over-specializing: Lacking breadth in architecture, product, or domain knowledge.
Prioritizing speed over quality: Sacrificing scalability, maintainability, or long-term value.

Soft Skills

Poor stakeholder management: Inability to articulate trade-offs.
Waiting for permission: Not taking initiative to drive projects or solve high-impact problems.
Failing to delegate: Micromanaging instead of empowering others.
Not adapting to ambiguity: Struggling with unstructured problems or unclear requirements.

Conclusion

Career growth in software engineering is rarely about a single breakthrough moment. It is about consistently developing the right traits while avoiding the pitfalls that trap even talented engineers.

Take a moment to reflect on where you are in your journey. Which skill are you actively cultivating and what may be holding you back? The difference between thriving and plateauing often comes down to this kind of honest self-assessment and deliberate action.

Whether you're a junior engineer looking to make your first step up or a senior engineer aspiring to Staff level influence, the path forward is clearer when you know what to build and what to avoid.

Your career is yours to shape. Start with one trait to strengthen or one pitfall to address, and build from there.

The Software Engineering Manager Role

Eduardo Klein — Mon, 04 Nov 2024 18:05:33 +0000

A Software Engineering Manager (SEM) is a multifaceted role, blending the technical expertise of a seasoned software engineer with the leadership and strategic skills of a manager.

At their core, SEMs are responsible for leading teams of software engineers (SWE). They typically:

Manages the design, development, and maintenance of software applications or services;
Directs or supports the work of software engineers to promote the best practices and foster improvement;
Has a good comprehension of software development, including topics such as programming, testing, building, deployment & delivery, software architecture & design, and many more.

There are a variety of software engineering concepts, practices, tools, etc., essential to understand, such as but not limited to:

Software Development Lifecycle (SDLC).
DevOps, Cloud Computing, Microservices, etc.

The Engineering Manager by Camille Fournier

When reading The Manager’s Path, written by Camille Fournier (Managing Director of Engineering at JP Morgan Chase & Co), I found the following description for the Engineering Leader role, which is the leader of a team.

The description is helpful for SEMs who want to understand their place and want to develop skills, as it covers all the basics of the role.

The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.

The person who fills this role is expected to have a large impact on the success of [the organization] as a whole. In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused on these projects. As part of keeping the team focused, the engineering lead will partner closely with the product lead to manage project scope and ensure the technical deliverables are met. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.

The engineering lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, and solicit and deliver individual feedback frequently (not just in the scope of review periods). In addition to strong management skills, the engineering lead acts as a leader for the technical roadmap for their product group (pillar). They clearly communicate the timeline, scope, and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt, and communicate suggested timelines for prioritizing this to the management team.

The Engineering Manager by Dave Anderson

Dave Anderson (former Amazon GM and Tech Director and author of Scarlet Ink) shares a great discussion on the importance of technical skills for effective engineering management. We can summarize the key takeaways from the article as follows:

Balancing Involvement and Delegation

Long-term vs. Short-term Impact: SEMs must involve themselves in projects with long-term impacts, such as major service designs, while delegating short-term tasks like temporary scripts.
Big Risk vs. Small Risk: High-risk tasks that could severely impact customers necessitate SEMs involvement, whereas low-risk tasks can be delegated.
One-way vs. Two-way Doors: SEMs should engage in decisions that are difficult to reverse (one-way doors), such as designing external API schemas, while delegating reversible decisions (two-way doors).
High vs. Low Political Impact: Projects with significant visibility or political implications require SEMs involvement, whereas low-priority tasks can be delegated.

Critical Technical Skills

Operations: SEMs need a deep understanding of system operations to lead through high-severity events, discuss operational issues, and explain crises to leadership.
Architecture and Design: A thorough grasp of system architecture and design principles is essential for discussing system dependencies, scalability, and performance with the team.
Coding: While not required to code regularly, SEMs must understand the coding process, including development workflows, code reviews, and deployment procedures, to ensure quality and efficiency.

Skill Development

Building a Mental Model: Managers should engage with engineers to develop a comprehensive understanding of system operations and interdependencies.
Understanding Customers: Managers need to grasp how their technical systems impact customers and monitor these interactions closely.
Learning Engineering Processes: Shadowing engineers and asking questions helps managers understand coding and deployment processes.
Acquiring Technical Vocabulary: Continuous learning and seeking explanations for technical terms are crucial for managers to bridge knowledge gaps.

Progressive Deployments

Eduardo Klein — Sat, 02 Nov 2024 03:04:11 +0000

Rolling out a product or improvement involves deploying and launching new features or updates to an existing user base. This is an integral part of operating any digital platform.

A well-designed rollout plan is essential for successfully launching these improvements without negatively affecting customers' operations. A comprehensive rollout plan should address, at a minimum, the following key aspects:

Testing protocols: Before rolling out to the entire user base, testing the new features or updates in a controlled environment (like staging) or with a smaller subset of users (beta testers) can help identify and fix issues.
A progressive deployment plan and rollback process: A progressive deployment plan ensures that updates are introduced in phases, allowing for real-time feedback and adjustments, while a rollback process guarantees a swift return to the previous version if any issues arise, minimizing disruptions and potential risks.
A communication plan that addresses key stakeholders: A well-structured communication plan is vital, ensuring that customers are informed and prepared for any changes while also equipping customer support and technical support teams with the necessary information to address queries and resolve issues.
User documentation: Providing comprehensive and updated user documentation helps users adapt to new features or changes.

Progressive Deployment Strategies

From the above aspects, I want to delve into the progressive deployment plan.

A progressive deployment aims to minimize risk and improve customers' and developers' experience by implementing change to a small group of users, which allows fast feedback and faster rollback in case of failures. There are a few strategies that we can adopt for a progressive deployment:

Canary Deployments: A new software version is partially rolled out to a small subset of users before a full rollout. The purpose is to test and monitor the new version in a real environment with actual users. If the canary deployment works well and no issues are identified, the new version can be rolled out to the entire user base. If issues are found, it’s easier to roll back, preventing all users from being affected.
Blue/Green Deployments: Two identical production environments are maintained. The “blue” environment runs the current version of the software, while the “green” environment gets the new version. Once the new version is ready and tested in the “green” environment, traffic is switched over, making “green” the live environment. This allows for near-instant rollbacks in case of issues and ensures minimal downtime during deployments.
Rolling Deployments: The new software version is gradually rolled out to all users, replacing the old version incrementally. This is typically done server by server or container by container, ensuring that only a portion of the system is updated at any given time. If problems arise during the deployment, it affects only the portion being updated, allowing for easier rollbacks and reduced impact.
Shadow Deployments: The new version of the software runs alongside the old version but without actual user traffic directed to it. Instead, real user requests are duplicated to the new version in real time, allowing teams to monitor and test how the system behaves under realistic conditions without affecting the actual user experience.

Feature Flags

Feature flags, also known as feature toggles, provide flexibility in the deployment process. They allow specific features to be turned on or off at runtime without changing the code.

Instead of deploying a new version of the software to a subset of servers or containers, the feature is deployed everywhere but is enabled first for a small subset of users (e.g., beta testers) and then progressively rolled to the entire user base in phases.

This ability supports various progressive deployment strategies and is widely adopted in cloud, multi-tenant environments.

Effective Communication in Software Engineering

Eduardo Klein — Wed, 16 Oct 2024 12:43:25 +0000

Effective communication is vital for successful product development teams in tech companies, including software engineering teams. As software engineers (SWEs) and software engineering managers (SEMs), our focus often leans heavily on technical excellence and delivery processes. Yet, without clear communication, great ideas and initiatives can fail.

In tech companies, where cross-functional collaboration is crucial, the ability to convey complex ideas clearly is not just a nice-to-have — it’s essential. Effective communication bridges gaps between leadership, product and growth teams, partners, and clients, ensuring alignment and shared understanding. However, many teams struggle to articulate their thoughts or adapt their language to diverse audiences, leading to misunderstandings and inefficiencies.

In this post, I share my perspective on the varying levels of communication skills for SWEs within tech companies. By breaking down the competency of effective communication into actionable levels — from beginner to expert — I aim to provide a framework that SEMs can use to assess and develop their team's communication skills.

This structure can also be integrated into career ladders, supporting personal development and career progression. It can help SWEs identify growth opportunities and set clear goals, fostering an environment where communication flows freely, and product development thrives.

Effective Communication Expectations and Levels

To make effective communication more tangible, I will describe it through four dimensions:

Empathy and Perspective-Taking: Understands and appreciates others' feelings and viewpoints. Empathizes with others to better understand and address their concerns.
Active Listening: Fully concentrates on and understands what is being said. Acknowledges the speaker and gives feedback to show understanding.
Clarity: Expresses ideas in a straightforward and clear way. Uses precise words and logical sentences. Avoids jargon to minimize misunderstandings.
Adaptability: Adjusts communication style for different audiences. Modifies language and tone to ensure the message resonates.

I try to establish adequate expectations for each level and provide evidence and examples.

Beginner

Empathy and Perspective-Taking: Demonstrates basic awareness of the need to understand and consider others' viewpoints. Begins to ask questions to clarify others' perspectives.
Active Listening: Listens to others but occasionally interrupts or misses key points.
Clarity: Communicates basic ideas clearly but may struggle with complex topics. Uses jargon without ensuring others understand.
Adaptability: Tends to use the same communication style regardless of the audience and may need guidance to adjust language for different stakeholders.

Evidence

Listens attentively during team meetings and one-on-ones
Asks clarifying questions when unsure about tasks or requirements
Communicates project status and blockers to immediate team members
Uses basic technical terminology correctly in team discussions
Writes clear documentation for their code and processes

Example

An engineer who effectively explains their work to colleagues, using simple language and checking for understanding through questioning.

Competent

Empathy and Perspective-Taking: Regularly attempts to understand others’ perspectives and asks clarifying questions to ensure they grasp the other person's viewpoint.
Active Listening: Demonstrates consistent active listening by paraphrasing and summarizing others’ points.
Clarity: Communicates more complex ideas clearly and tailors messages to the audience.
Adaptability: Adjusts communication style for different audiences but may need support to fully align with stakeholders’ needs or preferences.

Evidence

Actively participates in team discussions and contributes ideas
Facilitates productive team meetings and discussions
Adapts communication style when speaking with non-technical teammates
Provides regular, unprompted updates on project progress
Explains technical concepts to junior team members effectively
Prepares and delivers presentations and demos on their work
Writes comprehensive technical documents and proposals

Example

An engineer who leads team meetings and technical discussions, as well as ensures all participants understand the key points by summarizing and asking for feedback.

Proficient

Empathy and Perspective-Taking: Consistently considers and integrates multiple perspectives into communication. Demonstrates empathy in discussions and decision-making.
Active Listening: Engages in active listening as a natural part of communication. Frequently verifies mutual understanding and encourages others to express their views.
Clarity: Communicates complex technical ideas clearly and effectively, adapting language and style to suit diverse audiences. Regularly ensures mutual understanding.
Adaptability: Flexibly adjusts communication style based on audience feedback and context. Proactively seeks to build a common vocabulary where necessary.

Evidence

Communicates complex technical ideas to both technical and non-technical audiences
Negotiates effectively with leadership and other stakeholders
Presents confidently to larger groups, including leadership and cross-functional teams
Proactively addresses potential miscommunications or conflicts within the team

Example

An engineer who facilitates cross-functional meetings, including leadership, using clear and concise language to ensure all stakeholders understand the discussion.

Expert

Empathy and Perspective-Taking: Intuitively understands and anticipates others' perspectives and needs. Guides conversations to foster understanding and collaboration.
Active Listening: Exemplifies active listening, creating an environment where others feel heard and valued. Facilitates discussions, ensuring all voices are included and understood.
Clarity: Articulates complex ideas with exceptional clarity and precision across diverse audiences. Coaches others in effective communication strategies.
Adaptability: Seamlessly adapts communication style to suit any audience, situation, or context. Establishes and promotes effective communication norms within teams and across the organization.

Evidence

Develops and implements communication strategies for large-scale projects
Represents the engineering team in high-level discussions with executives and external partners
Mediates complex discussions and conflicts across multiple teams
Delivers compelling presentations at company-wide events or conferences
Creates and maintains a shared technical vocabulary across the organization
Writes influential articles or blog posts that enhance the company's reputation in the tech community
Coaches other leaders on effective communication techniques
Establishes communication best practices and guidelines for the entire engineering organization

Example

An engineer who leads initiatives across the company, ensuring all stakeholders have a common understanding.

Conclusion

Effective communication is a multifaceted skill that is crucial for the success of tech teams. By focusing on those four dimensions, we can create a structured approach to developing these competencies within our teams.

Setting clear expectations for each level of communication proficiency allows SEMs to guide their teams toward continuous improvement.

This framework provides engineers with a roadmap for growth, helping them identify where they are, where they want to go, and what skills they need to develop along the way.

The Ivy Lee Method for Managing Priorities

Eduardo Klein — Mon, 15 Jul 2024 14:42:49 +0000

The Ivy Lee method is a classic productivity method popularized by Charles M. Schwab, an American steel magnate who supposedly sought Ivy Lee's advice in 1918. Ivy Lee taught this method to Charles Schwab and his employees at Bethlehem Steel Corporation. Under Schwab's leadership, the company became the second-largest steel maker in the USA.

It is said that Lee asked Schwab to send him a check for whatever he thought the advice was worth. After three months, Schwab was so impressed by the results that he sent Lee a check for USD 25,000, equivalent to several hundred thousand dollars nowadays, highlighting the importance of Lee's advice.

The Ivy Lee Method

Here's the straightforward method Ivy Lee suggested:

At the end of each day, write down the six most important tasks you need to accomplish the next day.
Prioritize those tasks in order of importance.
When you arrive the next day, concentrate only on the first task. Work on it until finished before moving on to the second task.
Approach the rest of your list in the same fashion. At the end of the day, move any unfinished tasks to a new list of six tasks for the following day.
Repeat this process every day.

What I would like to highlight from the method:

Its simplicity is outstanding. It is quite simple to get started and continue using.
The method runs counter to the idea of multitasking, which is scientifically recognized as detrimental to productivity. Multi-tasking causes us to make more mistakes, retain less information, and spend time in context switching.

Prioritizing your six tasks with the Eisenhower Matrix

Modern productivity advice suggests using the Eisenhower Matrix to help you prioritize the six most important tasks. I find this idea really useful; I'm a true believer in the Eisenhower Matrix paradigm.

I'd guess Ivy Lee taught Schwab and his team how to effectively prioritize those six tasks to make that big amount of money, but that lesson was probably lost in history.

Equivalent in structure, you could prioritize the six most important tasks following other prioritization systems, such as the Value vs. Effort matrix, 1-3-5 rule, 3-3-3 method, etc.

Following the Eisenhower Matrix system, it is advised to:

Choose the six items from quadrants 1 (Urgent and important), 2 (Not Urgent but important), and 3 (Urgent but not important) of the matrix. Always avoid quadrant 4 (Not urgent and not important).
Give more room to important tasks (quadrants 1 and 2), leaving just one or two slots for urgent but unimportant tasks (quadrant 3).

An Approach to Career Development

Eduardo Klein — Thu, 27 Jun 2024 17:02:54 +0000

Career development is essential to reaching our potential. Committing to self-improvement not only enhances our current roles but also equips us for future advancements and challenges. As the owners of our professional journeys, we have the responsibility to improve our capabilities continually.

Our careers are not just defined by what we work on but mainly by what we aspire to become. This pursuit is an ongoing endeavor that shapes our career aspirations and enhances learning, contributing to personal growth and collective success in companies.

To empower individuals and facilitate career advancement, I've documented a structured approach to guide the process. It consists of:

Resources: A collection of guides and templates that help you understand how to pursue career development;
Tools: The tools that help you navigate the journey, leveraging your relationship with your manager and peers;
Approach: A structured approach to go from envisioning your desired future to realizing tangible growth.

Resources

Individual Development Plan (IDP) template: A straightforward template to help you create your development plan;
Your company's career track: This is something your company should provide. It is essential to understand the career track laid out by your organization. Learn how to progress in your career by discussing with your manager. Learn more about software engineering career ladders and progression frameworks here;
Your company's performance review process: This information should also be provided by your company or manager. Most organizations have a documented schedule and process for performance reviews. It is beneficial to align your development plan with it to ensure your goals are in sync with the company's expectations;
Your company's and team's strategy and vision: This information should also be provided by your company or manager. Understanding your company's and team's strategy and vision is crucial. It helps you identify relevant projects and opportunities that align with your objectives and contribute to organizational goals.

Tools

The following is a collection of tools that you can leverage, together with your manager, to communicate your goals, commit to them, and progress in your career.

One-on-one meetings

A one-on-one is a recurring, individual meeting that managers schedule with each team member. Its primary goal is to support your career development, providing a platform for discussing professional growth, addressing tactical issues, and receiving guidance and feedback. They are also an opportunity for you to share feedback, raise concerns, and discuss your aspirations.

Ideally, this meeting should occur regularly, preferably weekly, to ensure consistent communication and support. If you're not currently having these meetings, I recommend you talk to your manager to establish a schedule.

Some advice for your one-on-ones:

Connect with your manager. Let them know about yourself, your desired future, and your dreams and goals. Your manager should be the person to help you maximize your development inside the company.
To make the most of this relationship, own the one-on-one agenda. It is about you, not about them, so be proactive in bringing topics to the table. Don't expect your manager to guide your development; do it yourself.

Feedback

Feedback is a powerful tool for personal and professional growth. It involves both giving and receiving constructive comments about performance, behavior, or learning strategies. Regular feedback can help you understand your strengths, identify areas for improvement, and align your efforts with your team's and organization's objectives.

Some advice on feedback:

Seek feedback often: Don't wait for formal reviews. Ask for feedback regularly from your manager, peers, etc;
Be specific in your requests: Instead of asking for general feedback, focus on specific areas or recent projects;
Create a feedback-friendly culture: Encourage open and honest communication within your team. Show appreciation for the feedback you receive, and be respectful and constructive when giving feedback to others.
Act on the feedback: Demonstrating that you value and act upon feedback is crucial. Reflect on it, make necessary adjustments, and use it as a stepping stone for growth.

Remember, effective use of feedback is a key component in driving your personal development and achieving your career goals.

Individual Development Plan

An Individual Development Plan (IDP) is a document you create, preferably in collaboration with your manager. It serves as a roadmap for career growth and skill development, outlining specific, achievable objectives aligned with both your career aspirations and your team's and the organization's goals.

The creation of an IDP is a proactive process. Reflect on your strengths, feedback received, areas for improvement, and long-term career goals when writing it. Regular reviews and updates to the IDP are crucial, as they allow for adjustments based on progress, changing circumstances, or evolving career objectives.

An effective IDP not only guides an individual's professional development but also fosters a culture of continuous learning and growth within the organization. If you haven't developed your IDP yet, consider scheduling time with your manager to start this valuable process.

Taking the driver's seat

As we have established, owning our personal development is crucial. I strongly encourage you to take the driver's seat on this journey. Commit to your self-improvement and intentionally chart the course of your career.

If you're uncertain about where to begin, the following is a structured approach to navigating your personal development.

Leverage your one-on-ones

You should count on your manager to support you in every aspect of your personal development plan. Ensuring that your goals are aligned with the team's objectives and the organization's vision is key to success.

One-on-one meetings with your manager are invaluable opportunities to drive your personal development forward. Use these sessions to discuss your goals and your development plan, celebrate your wins, navigate through challenges, and adjust your goals as needed.

Be proactive in seeking guidance, clarifying expectations, and securing the support you need. These interactions can give you the insights and motivation to propel your career development.

Clarify your desired future

Consider what success looks like for you in the long term: the roles you aspire to fill, the skills you wish to master, and the impact you want to make. Reflect on your interests and passions and how they align with your career aspirations.

This clarity of vision is the compass that will guide all subsequent steps in your career journey.

Consider the following in this step:

While your vision of the desired future provides direction, remember it's equally important to remain adaptable. As you grow personally and professionally, your aspirations evolve. Make it a practice to reflect on and revise your vision at least annually.
In case of a shift in your desired future, you must communicate these changes to your manager. Together, you can discuss the implications of this change on your current role and explore a transition plan that aligns with your new objectives.

Define your development objectives

Once you have a clear picture of your desired future, it's time to set specific development objectives. These are the milestones that will mark your progress along the path to your ultimate career goals.

Consider the following in this step:

Regularly review and update your objectives to stay aligned with both your personal growth and the organization's evolving landscape. A quarterly review, synchronized with the company's performance or planning cycles, can ensure your goals remain relevant and achievable.
Less is more. Aim for a manageable number of objectives that allow for focused effort and significant impact.
Stay agile in your career planning. If there are shifts in your team’s vision or organizational structure, view them as opportunities to realign your objectives. Adapting your goals to new circumstances can open up unexpected avenues for growth and learning.

Build your Individual Development Plan (IDP)

With your objectives set, you can now craft your Individual Development Plan (IDP). This personalized plan is your strategy for achieving your career goals. It should outline the resources you'll need, the skills you'll develop, and the steps you'll take. Your IDP is a living document that will evolve as you progress, so it's essential to revisit and revise it regularly.

Tracking Progress

Once your IDP is established, the next critical phase is implementation and tracking. This is where you put your plan into motion, actively engaging with the outlined activities and learning opportunities.

Establish a routine for regularly reviewing your progress against your objectives. This could be a monthly self-assessment or a tracking spreadsheet. Such vigilant monitoring will help you stay accountable, make necessary adjustments, and maintain momentum toward achieving your goals.

Ask for feedback

Feedback is the fuel for growth and improvement. Regularly seek out constructive feedback from a variety of sources: managers, peers, mentors, and other people. Embrace both positive and constructive criticism as opportunities to learn and refine your skills.

Remember, feedback is not just about hearing what you're doing well but also about identifying areas where you can improve. By actively asking for and acting on feedback, you demonstrate your commitment to continuous learning and self-improvement.

Managing Priorities with the Eisenhower Matrix

Eduardo Klein — Thu, 27 Jun 2024 15:10:25 +0000

The Eisenhower Matrix is a straightforward and popular time management tool that I was first introduced to in The 7 Habits of Highly Effective People¹, written by Stephen Covey, many years ago. It can help you get organized and execute around priorities.

When you categorize your activities into four quadrants, with the help of the matrix, you can quickly identify what you should prioritize first. Let's take a look at the matrix:

As you can see, the two factors that define an activity are urgent and important. Urgent means that the activity requires immediate attention. They are usually visible and press on us. Importance has to do with results; if the activity is important to you, it contributes to your mission, values, and high-priority goals.

We react to urgent matters, but important matters require initiative and proactivity!

The quadrants can be read as follows:

Urgent and important: This quadrant deals with significant results that require immediate attention;
Important but not urgent: This quadrant is the heart of effective personal management. It deals with important, but not urgent, activities;
Urgent but not important: This quadrant deals with urgent activities that are usually a priority for someone else, not for you;
Not urgent and not important: It is usually stuff that is pleasant to do but has no significance.

It is important to take into consideration that:

People who spend most of their time in quadrant I live by crisis. This quadrant dominates them. If you are there, you should consider how to shrink quadrant I and move to quadrant II, where you are more effective;
Effective people avoid quadrants III and IV. You should consider delegating quadrant III activities when possible. Avoid quadrant IV activities altogether; this should be your "do not do" list.

As far as I understand, the matrix was created by Stephen Covey. He refers to it as The Time Management Matrix, however. The matrix is widely known as the Eisenhower Matrix, in honor of USA 34º president Dwight D. Eisenhower, but I don't know by whom and when the matrix was named the Eisenhower Matrix. ↩

Software Engineering Team Size

Eduardo Klein — Wed, 04 Jan 2023 12:00:00 +0000

The right size of a software engineering team and the number of engineers an Engineering Manager (EM) can properly support is at the core of organizational design in tech companies.

The Scrum Guide states that "The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people". The Two-Pizza Teams, coined by Jeff Bezos at Amazon, also says that "We try to create teams that are no larger than can be fed by two pizzas", which I guess can't feed more than 8 or 9 people.

A more accurate answer depends on how the team operates. Teams at big tech, for example, are responsible for innovation, keeping the lights on, on-call processes, among other responsibilities. By the way, those teams are usually not running the Scrum framework to manage projects anyway.

The truth is, this question has been puzzling me for a while. I feel I've been in both extremes of this dilemma: Small teams that lack skills and are highly impacted by vacation, on-call, sick leave, etc.; and big teams that get too complex to manage, loose focus easier, and don't adapt fast. Both usually don't perform as expected.

Being in the EM's seat, having a small team impels you to act hands on with your engineers, whereas with a big team you can't properly support all engineers the way you wish. Neither helps your career development as an Engineering Manager.

In his book An Elegant Puzzle, Will Larson offers, from his experience, a playbook on sizing teams at big tech, which I feel is well aligned with my perceptions.

From his playbook we can get valuable insights:

Managers should support 6 to 8 engineers
- Those who supports fewer than 4 engineers are hands on Tech Lead Mangers (TLMs)
- Those who supports more than 8 engineers, typically act as coaches and safety nets for problems
Managers of managers should support 4 to 6 managers
- Managers supporting fewer than 4 managers should be in a period of active learning (Ramp up)
- Coaches: Supporting more than 6 managers leaves you functioning purely as a problem-solving coach
On-call rotations want 8 engineers
Small teams (fewer than four members) are not considered teams

This is a simple and straightforward set of principles that can guide the way we organize teams effectively.

Different Types of Schedules

Eduardo Klein — Tue, 03 Jan 2023 12:00:00 +0000

There is this great article, "Maker's schedule, manager's schedule", written by Paul Graham, that covers the differences between the schedules of makers (which I refer to as individual contributors from here on) and managers.

Managers typically schedule their activities in hourly blocks to make their schedules more efficient, whereas individual contributors are more productive in their tasks by using bigger blocks of focus time, such as half a day or a whole day.

As a software engineering manager, I think it is important to take both into account, from different perspectives.

Firstly, I have my schedule organized into blocks of an hour or even less, so that I can handle leadership sync meetings, one-on-one meetings, team rituals, demos, etc. That's typically a manager's schedule. But I also need to block out bigger chunks of time, to get more complex activities done. I usually allocate two or three chunks of time (at least 2-hours long) in my schedule to focus on such activities. By the way, I also like the concept of batching, as explained by Tim Ferriss.

Secondly, to help my teams perform better, I have to consider the individual contributor's schedule, trying my best to protect their schedule time. Two key considerations I always take into account are

Plan recurring meetings and one-on-ones in times that allow them to be focused and productive during the rest of their day
Empower them to manage their own schedules, and to negotiate (with me and peers) adjustments that may improve their focus

For an individual contributor, a short but unexpected meeting may drain their energy for a whole day, potentially preventing them from starting something complex.

Taking care of their schedule can boost their productivity.

Taking Notes of One-on-ones

Eduardo Klein — Mon, 02 Jan 2023 12:00:00 +0000

Taking notes of one-on-one meetings is an important step to support the growth of your direct reports and help you keep track of it.

I've been in situations where I had more than 10 direct reports, and without writing things down I would certainly fail miserably; disorganization and mismanagement would follow.

Some benefits include:

To prepare the agenda of your next one-on-ones. Both parties should have a document to write down something they don't want to miss the next time they meet;
Keep track of decisions you made and assigned actions;
Keep a record of deliveries and achievements;
Provide your direct reports a source of information that will help them write their self review during performance review cycles;

Another important aspect about this practice is to have a lightweight process. No one wants to waste time on management stuff, no matter how important it is. If it is not simple and easy, chances are it will fall into disuse.

In order to keep track of one-on-ones I use two simple documents: A shared online document to collaborate with each direct report and a private document for my personal notes.

A shared online document to keep track of one-on-ones

First, I create a shared online document (platforms such as Google Docs or Microsoft Word work well) with each direct report, where we can prepare our agenda and collaboratively register our meetings. It is important that you use an online solution so you can both collaborate on the document at the same time.

This document is a timeline, where the most recent entry is on the top, and it consists of:

A new entry in the timeline for each one-on-one;
Two sections for each entry, the agenda and the meeting notes;
For each topic discussed, a series of bullet points with notes and action items.

It is quite straightforward to fill it in. It looks like this:

You can get this template here.

A private document to keep personal notes

Second, I keep a private document for each of my direct reports, where I save my personal notes about our relationship. In this document I register thoughts that I do not want to share with them.

I personally use Obsidian as my note-taking app, so I keep an entry for each direct report in it. But if you want to keep it simple, just open another document in the same platform you chose before. Just make sure you keep it private.

This document consists of:

A section to save personal information about your direct report. This is important to build an understanding about them and their life that will help me connect with them easier;
Another section to save information about their jobs; That's where I save unstructured information about work, links to documents, etc.;
The last section is a timeline of events, where I take personal notes.

This is an example of how it looks like.

You can get this template here.

And that's it! These two documents are what I use to keep track of one-on-ones with my teams.