This is the Peter Principle, and it’s one of the most persistent traps in performance management.

What is the Peter Principle?

Formulated by Laurence J. Peter in his 1969 book The Peter Principle, the idea is deceptively simple:

In a hierarchy, every employee tends to rise to their level of incompetence.

The logic is straightforward. If promotions are granted based on performance in the current role, then people keep being promoted as long as they perform well. The moment they reach a role where they no longer perform well, the promotions stop — and they stay there.

Over enough time, the argument goes, every position ends up occupied by someone who is not competent at it. It is of course an exaggeration, but the mechanism behind it is very real, and I’ve seen it play out in tech many times.

Why It Hits Software Engineering So Hard?

The Peter Principle is particularly damaging in software engineering because the skills that make someone excellent at one level are often not the skills required at the next one.

An excellent Senior Software Engineer is deeply technical, delivers complex projects, and is a trusted authority within their team. Promote them to Staff and the job changes: influence without authority, technical direction across teams, and the ability to pick the right problems rather than solve the assigned ones.

Promote a Senior Engineer to Engineering Manager and the change is even more radical. The craft that earned the promotion — writing code, designing systems, solving hard technical problems — is no longer the job. The new job is people management, delegation, feedback, hiring, and team management. It’s a career change, not a promotion.

The same happens one level up. Going from managing a team to managing managers means you no longer lead the work — you lead the people who lead the work. My own experience taking on a full product vertical taught me that lesson: the levers you have as a leader of leaders are strategy, organizational design, and developing other leaders, not the day-to-day execution you used to control.

I explored some of these transitions in The traits and pitfalls in Software Engineering careers. The pitfalls listed there are, in a sense, a catalog of what happens when someone lands at a level they were not prepared for.

The cost is real, and it’s paid by everyone:

• The person: They lose the sense of mastery they had, their confidence erodes, and they may be pushed into a performance improvement plan for a role they never really chose;
• The team: They get a leader who is struggling to learn the basics of a role instead of one who can support them;
• The organization: It loses a great performer at one level and gains a struggling one at the next.

And there’s a second-order effect that’s often ignored: the person who is not promoted because there was no room left. Levels occupied by people who plateaued block progression for everyone below them.

The Fix: Promote for the Next Level, Not the Current One

The antidote to the Peter Principle is straightforward to state and hard to execute: promote people who are already performing at the next level, not people who are performing well at their current one.

This is the principle the Tech Org career track at VTEX follows. Promotion is not a reward for a great cycle in your current role — it is the formal recognition of a reality that is already visible. By the time someone is promoted, they have been consistently demonstrating the expectations of the next level, and the promotion simply makes the title match the behavior.

This changes the nature of the whole conversation:

• Promotion becomes evidence-based. The question a leader has to answer in a calibration committee is not “do they deserve it?” but “where is the evidence that they are already operating at that level?” Evidence is concrete: scope owned, decisions made, impact delivered, autonomy demonstrated;
• Development comes before promotion, not after. If someone needs to perform at the next level to be promoted, then the leader’s job is to create the opportunities where that performance can happen. This is what an Individual Development Plan is for;
• Nobody is set up to fail. A person promoted for behaviors they already demonstrate does not fall off a cliff on day one. The role gets bigger, but it is not foreign to them;
• The bar is explicit. Since expectations are defined per level in the career ladder, both the engineer and the manager can point at the same document. There is much less room for surprise or perceived unfairness.

It also has an uncomfortable but healthy consequence: excellent performance at your current level is not, by itself, a case for promotion. It is a case for recognition, for compensation adjustments, for scope and for trust — but the promotion conversation requires something different. Being clear about this early, in one-on-ones, avoids frustration much later.

The Compensation Caveat

There is a fair objection to this model: if someone has to perform at the next level before being promoted, they can spend a long time delivering next-level scope while being paid for the previous one.

The objection is legitimate, but the problem is not the promotion criteria — it’s treating title and compensation as the same lever. They should move on different cadences. A promotion recognizes a level that has been consistently demonstrated; compensation should follow the value being delivered along the way. This is why salary bands are tipically broad and overlap between adjacent levels in the industry: so that someone operating above their level can be moved toward the top of their band, without waiting for the title to catch up.

If a person is delivering next-level scope and their compensation hasn’t moved at all, the failure isn’t in the promotion model. It’s in not using a tool the company already has.

Two things make this work in practice: a defined horizon, so the person knows roughly how long the demonstration period is expected to last, and explicit criteria, so they know exactly what is still missing. Without those, “perform at the next level first” stops being a development path and becomes an open-ended request.

What This Looked Like For Me

I took on the senior engineering leadership of the Omnichannel Experiences vertical at VTEX in November 2024 — four teams, 35 engineers and engineering managers across Brazil and Colombia. I was promoted to Senior Engineering Manager in August 2026.

Almost two years separate those two dates. That gap is the point.

I did not get the scope because I was promoted. I got promoted because I had been operating at that scope, consistently, across several performance review cycles — leading managers, owning the technical direction and organizational health of a vertical, and contributing to hiring and engineering leadership beyond my own teams. The promotion did not hand me a new job to figure out. It recognized the job I had already been doing.

That interval was not a formality either. It was where the actual development happened, and the gaps were not the ones I expected. Leading through other managers was something I had already practiced in previous roles. What my development plan actually targeted was different:

• Multiple problem spaces: going from a single domain to holding several distinct problem spaces at once — marketplace integrations, in-store and remote sales, live shopping — each with its own technical challenges, and none of which I could afford to go deep on the way I used to;
• Strategic vision: shifting from planning execution to shaping where the vertical should be in a year, and being able to defend that direction with a rationale that connects technical decisions to business outcomes;
• Stakeholder management: operating with product, business, and leadership peers across the company, where influence and alignment replace the direct authority you have inside your own teams.

Those three are precisely the skills you cannot acquire from a title. They come from sitting in the chair, adjusting your leadership style to a much wider range of situations, and getting comfortable with the fact that at that level you influence outcomes far more than you control them. Had I been promoted first and asked to grow into them afterwards, that learning would have happened under pressure, with much higher stakes, and with a real chance of becoming a textbook Peter Principle case.

It requires patience, from both the individual and the organization. Waiting is uncomfortable when you feel ready. But the alternative — being promoted into a role you have never actually practiced — is far worse.

The Leader’s Responsibility

If you lead engineers, this principle puts a specific obligation on you. Promoting for the next level only works if people are actually given the chance to perform at the next level before the promotion. Otherwise it becomes a circular trap: you can’t be promoted without demonstrating the behaviors, and you never get the chance to demonstrate them.

Concretely, this means:

• Delegate scope that stretches. Delegation is not only about your own bandwidth — it’s the primary mechanism for creating next-level opportunities;
• Be explicit about the gap. Tell people exactly which expectations they are already meeting and which ones they are not. Vague encouragement is not feedback;
• Make the ladder visible. People cannot aim at a target they can’t see;
• Validate the aspiration. Not everyone wants the next level, and moving to management in particular should be a deliberate choice, not a default reward. Assuming that everyone wants to climb is its own version of the trap.

Conclusion

The Peter Principle is not a law of nature. It is the predictable outcome of a specific design choice: rewarding past performance with a different job.

Change the criteria and the outcome changes with it. When promotion recognizes performance that is already happening at the next level, you stop converting great performers into struggling ones. People arrive at new levels prepared, teams get leaders who can actually lead them, and career progression becomes a process people can understand and plan for, rather than a lottery.

The question to ask in a promotion discussion is not “have they earned it?”. It’s “are they already doing it?”

Situational leadership is the ability to adapt your leadership style to the context you find, which involves three skills:

• Diagnosis: Assessing the development level of the person for a given task or goal;
• Flexibility: Being comfortable using different leadership styles;
• Matching: Applying the leadership style that fits the situation.

The Four Development Levels

The Situational Leadership II model, by Ken Blanchard, describes development as a combination of two factors: competence and commitment.

Competence is a function of knowledge and skills, which can be gained from learning and experience. Commitment is a combination of confidence (the ability to perform a task well without much supervision) and motivation (the interest and enthusiasm to do it well).

When someone doesn’t perform well without direction, it may be a problem of competence, commitment, or both. The combinations of these two factors form four development levels:

• D1 — Enthusiastic beginner: Low competence, high commitment;
• D2 — Disillusioned learner: Low to some competence, low commitment;
• D3 — Capable but cautious performer: Moderate to high competence, variable commitment;
• D4 — Self-reliant achiever: High competence, high commitment.

The Four Leadership Styles

To match the four development levels, the model describes four leadership styles, characterized by different degrees of directive and supportive behavior:

• S1 — Directing: Indicated for enthusiastic beginners (D1). They are motivated, but need direction and frequent feedback to build their skills. This style also fits situations where a quick decision must be made and the stakes are high;
• S2 — Coaching: Indicated for disillusioned learners (D2). They still need direction and feedback due to their limited experience, but they also need support and recognition to build confidence, and involvement in decision-making to restore commitment;
• S3 — Supporting: Indicated for capable but cautious performers (D3). They don’t need much direction because they already have the skills, but they need support to reinforce confidence and motivation;
• S4 — Delegating: Indicated for self-reliant achievers (D4). They are high performers, willing to work on their own with little direction and support. This is where delegation shines.

Matching Style and Situation

The key insight of the model is that development levels are task-specific, not people-specific. The same person can be a self-reliant achiever (D4) in one activity and an enthusiastic beginner (D1) in another. A senior engineer joining your team may have great technical skills, but may not know the priorities, policies, or processes of the company yet, and will benefit from some direction at first.

As a leader, your job is to diagnose the development level for the task at hand and provide the corresponding balance of direction and support. Over-supervising a high performer is as harmful as abandoning a beginner.

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.

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:

1. Framework and Tool Proficiency: Masters a variety of frameworks, tools, and libraries commonly used to solve engineering problems, enabling efficient and effective solutions.
2. 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.
3. Architectural Understanding: Develops architectural solutions that address complex system requirements and integration challenges, ensuring scalability, reliability, and maintainability.
4. Analytical Thinking: Breaks down complex problems into smaller, manageable parts and systematically approaches their resolution using appropriate strategies.
5. 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.

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.

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:

1. Empathy and Perspective-Taking: Understands and appreciates others’ feelings and viewpoints. Empathizes with others to better understand and address their concerns.
2. Active Listening: Fully concentrates on and understands what is being said. Acknowledges the speaker and gives feedback to show understanding.
3. Clarity: Expresses ideas in a straightforward and clear way. Uses precise words and logical sentences. Avoids jargon to minimize misunderstandings.
4. 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.

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:

1. At the end of each day, write down the six most important tasks you need to accomplish the next day.
2. Prioritize those tasks in order of importance.
3. When you arrive the next day, concentrate only on the first task. Work on it until finished before moving on to the second task.
4. 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.
5. 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).

My first introduction to this topic was through the excellent book An Elegant Puzzle by Will Larson (CTO at Carta).

In essence, a software engineering strategy consists of the following components:

1. Diagnosis: The theory describing the challenge at hand, including its factors and constraints, along with a problem statement;
2. Guiding Policies: These are the policies that will be applied to address the challenge. They describe the general approach taken to tackle the problem;
3. Actions: These are the specific steps implemented to address the challenge.

From my experience, I have found software engineering strategies useful in two contexts:

1. Writing guides to help teams tackle specific operational challenges: I have explored this in Writing Guides to Support Your Teams. The diagnosis usually identifies one specific challenge, and the guiding policies and actions are tailored to address that challenge;
2. Developing mid or long-term software engineering strategies for my team or business unit: In this context, the strategy explores multiple challenges, identifies the guiding policies and actions to tackle them, and aims to inspire and guide leaders and individual contributors in their work towards common goals.

I have also been writing a dedicated page called Software Engineering Strategy on this website, where I document the key learnings, insights, and resources that I find useful in my journey to deeply understand this topic.

I hope you find it helpful as well. Please feel free to reach out if you have any questions or comments about software engineering strategies.

Today, I came across an insightful article on HBR.org titled 5 Reasons People Get Laid Off by Marlo Lyons. This article offers valuable insights, and I highly recommend you read it.

Understanding why layoffs occur can empower us to proactively safeguard our careers and mitigate some of the associated stress. With this in mind, I’d like to share and summarize some key insights from the article.

Here are a few reasons why people get laid off:

Lack of skills advancement

Employees are 100% responsible for continually upskilling and reskilling. While companies may offer resources to learn new skills, they tend to teach to the entire employee population, so most talent development programs focus on management skills […]

But employees need to continue to advance their hard skills, such as becoming technically proficient in AI applications or new programming languages. Those who don’t continue to evolve their skills to keep up with rapidly changing business needs may be targeted for layoffs.

In most tech companies, particularly in software engineering roles, the job inherently involves continuous learning. It is crucial to demonstrate a commitment to reskilling and to develop personal growth plans that align with your team’s or company’s objectives.

You’re an “overseer,” not a “doer”

The most straightforward method to meet the assigned cut percentage is to eliminate the positions of individuals with the highest salaries, particularly if they’re not actively involved in accomplishing the work. Managers who lack hands-on involvement may be seen as less valuable to the organization, as there is a perception that they’re not directly contributing to task and project execution.

Managers who are invaluable to an organization find a balance between strategic leadership and hands-on involvement without micromanaging their teams.

Lack of visibility

Being the quiet worker bee won’t protect you from being laid off. In fact, being invisible could be your downfall. When determining which roles to cut, if senior leadership doesn’t know who you are, what you do, or the impact you make, your job could be an easy choice for elimination.

Lack of performance

When companies need to cut their budgets, they’ll likely try to eliminate those who are considered non-performers. Where more than one person is doing a particular job, layoffs provide managers a ripe opportunity to cut low performers without having to do the hard work of giving them more feedback or putting them on a performance improvement plan.

Employees must realize their manager’s perception means everything. So even if you think you’re doing a great job, if your manager doesn’t agree, you could be deemed a poor performer and be on the chopping block.

This one is particularly relevant for software engineering roles, as it accounts for many terminations I’ve observed in the tech industry’s post-pandemic layoffs. It appears to be the primary criterion used by senior leadership.

I’ve witnessed competent engineers who had one performance cycle rated ‘below expectations’ being selected for layoffs. Under normal circumstances, these individuals might have been placed on a Performance Improvement Plan (PIP) and given a chance to improve.

Maintain constant vigilance regarding your performance. Proactively seek feedback on your work, learn from it, and ensure alignment with your manager and peers.

Our careers are not just defined by what we work on but mainly by what we aspire to become. This pursuit is a continuous effort 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.