In the last 30 days, you’ve dedicated roughly one hour each day to refining your leadership skills across three critical areas: people, technology, and product. Now it’s time to bring it all together.

Remember: Bad leaders execute, Good leaders improve, Great leaders compound.

First-level people managers have the most direct impact on an organization’s success. They juggle hands-on tasks with strategic vision, blending knowledge of products, business, and technology. They are the closest to the customer and have the power to deliver real value. Your growth as a leader amplifies the growth of your entire organization.

Key Takeaways

Great engineering managers master six key areas:

1. Manage Talent: Develop your team. Challenge your engineers, help them grow, and fill gaps through strategic hiring.

2. Manage Expectations: Align your team’s efforts with outcomes, not just tasks. Create clarity and set the bar for success.

3. Manage People: Motivate your team. Make each person feel valued and empowered to contribute their best.

4. Manage Impact: Prioritize effectively. Allocate your team's energy to the initiatives that matter most.

5. Manage Product: Deeply understand the problems your team is solving. Build solutions that deliver the most value to customers.

6. Manage Technology: Keep the technical debt in check, improve developer experience, and ensure the tech stack supports product goals.

Action Points

1. Self-Assessment:

   • Take a moment to evaluate yourself in each of the six areas:

     • Talent: Are you effectively growing your team?

     • Expectations: Do your team members clearly understand what success looks like?

     • People: Is your team motivated and productive?

     • Impact: Are you focusing on the most valuable initiatives?

     • Product: Do you truly understand the problems your product solves?

     • Technology: Is your tech aligned with your strategic vision?

   Score yourself on a scale from 1 to 5 in each category. Identify areas for improvement.

2. Set Personal Development Goals:

   • Based on your self-assessment, define one actionable goal for each area.

   • Example: If you scored low in “Manage People,” set a goal to schedule regular 1:1s with your team members and actively seek feedback on how you can better support them.

3. Create a 90-Day Plan:

   • Outline specific actions you’ll take over the next three months to improve in each area. Break it down into weekly milestones to track your progress.

4. Commit to Continuous Improvement:

   • Leadership is a journey. Commit to revisiting your self-assessment and development plan every 90 days. Use the insights to refine your approach and continue compounding your growth as a leader.

Extra Resources

To continue your journey, here are some resources that expand on the topics we’ve covered:

• Do companies need fewer engineering managers or better engineering managers?

• How to Be a Better Software Engineering Leader

Books to Deepen Your Knowledge

• Wiring the Winning Organization by Gene Kim

• DevOps Handbook by Gene Kim

• Empowered by Marty Cagan

• Transformed by Marty Cagan

• Radical Candor by Kim Scott

• Principles: Life and Work by Ray Dalio

• Are Your Lights On? by Don Gause and Gerald Weinberg

• Measure What Matters by John Doerr

• Working Backwards book by Bill Carr and Colin Bryar

• Thinking, Fast and Slow by Daniel Kahneman

• Good Strategy / Bad Strategy by Richard Rumelt

Thank you for joining this journey to becoming a better engineering leader. Remember, your impact compounds. Keep learning, keep improving, and most importantly, keep leading with purpose.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

As an engineering leader, your role is to not only solve problems but also transform your organization.

Today, we'll focus on three strategic approaches: Slowification, Simplification, and Amplification. Each of these provides a distinct path for leading impactful changes in your team and technology stack.

1. Slowification: Create Space for Thoughtful Problem-Solving

Slowification involves moving away from reactive and impulsive decision-making to a more deliberate and measured approach. This isn’t about slowing down productivity; it’s about creating the mental space needed for thoughtful problem-solving.

Action Points:

• Audit Fast-Paced Processes: Identify areas where your team is making decisions under pressure. Are there places where mistakes are frequent, or stress levels are high?

• Introduce Decision-Making Buffers: Implement buffers like “cooling periods” before making significant technical decisions. For instance, after receiving a feature request, schedule a mandatory review session the next day.

• Encourage Mindful Reviews: Prioritize in-depth code reviews or architectural discussions without the urgency of delivery deadlines. Create a routine “thinking day” for strategic planning and reflection.

2. Simplification: Break Down Complexity

Simplification is all about making complex problems easier to handle by breaking them down into manageable chunks. This can be achieved through strategies like Incrementalization, Modularization, and Linearization.

Simplification through Incrementalization:

• Apply MVCs, PoCs, Prototypes: Start new projects with Minimum Viable Components, Proof of Concepts, or Prototypes. This reduces the risk and allows for learning without heavy investments.

• Incremental Builds: Break down feature development into small, continuous builds. Implement a system where every change goes through a pipeline that includes testing, review, and validation.

• Distributed Architecture: Assess whether large systems can be broken down into smaller, independently testable components.

Simplification through Modularization:

• Define Clear Interfaces: Ensure each module or service has clear, well-documented interfaces. This minimizes interdependencies and enhances team autonomy.

• Adopt Microservices or Modular Monoliths: Reassess your current architecture. Can some monolithic parts be modularized to improve scalability and maintainability?

Simplification through Linearization:

• Streamline Workflows: Map out your team’s workflows. Are there bottlenecks or unnecessary hierarchies that can be removed?

• Create Direct Connections: For teams working closely on interdependent components, create direct communication channels to bypass unnecessary escalations.

3. Amplification: Make Problems Impossible to Ignore

Amplification is about making existing issues visible and ensuring they get the attention they deserve. This approach prevents small issues from snowballing into major setbacks.

Action Points:

• Set Up a Problem Board: Create a visible board (digital or physical) where all incidents, test failures, and feedback are logged and tracked. Make it a team ritual to review this board during standups or retrospectives.

• Establish Clear Reporting Channels: Define clear, direct channels for reporting issues. Ensure that the person responsible for addressing them is immediately notified.

• Celebrate Problem Reporting: Encourage your team to report problems. Make it clear that the focus is on solving issues, not assigning blame.

Transform Your Team Today

Take a few minutes to reflect on your current practices. How can you apply Slowification, Simplification, or Amplification to your team, processes, or tech stack today? Pick one area and make a plan to implement these strategies.

Extra Resources

• Premium Articles for a Deep Dive:

  • Slowification

  • Simplification through Incrementalization

  • Simplification through Modularization

  • Simplification through Linearization

  • Amplification

• Book Recommendation:

  • Wiring the Winning Organization by Gene Kim

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Today’s Focus: Safety Leadership & Neuroception

Creating a sense of safety within your team isn’t just about ensuring physical safety; it’s about nurturing an environment where people feel secure, understood, and supported. This state of safety, known as neuroception, is your team’s subconscious radar, constantly assessing safety through internal, interpersonal, and environmental cues.

Your role as a leader is to provide as many safety cues as possible to support your team’s well-being and productivity. Here’s how you can practically apply this:

Six Strategies to Enhance Safety in Your Team

1. Clarity
   Lack of clarity disrupts trust and creates anxiety. Clearly communicate job responsibilities, salary expectations, benefits, and promotion criteria.

   Action Point: Schedule a 1:1 meeting with each team member to address any ambiguities in their role, career progression, or workplace expectations.

2. Predictability
   Unpredictable behavior from leaders can create a sense of threat. Consistency in your demeanor and communication builds trust.

   Action Point: Reflect on your interactions over the past month. Identify any instances of unpredictable behavior. Commit to maintaining a steady and transparent approach and communicate this to your team.

3. Belonging
   People need to feel they belong to a team. Recognize and value contributions that foster a sense of community.

   Action Point: Identify a team member who naturally builds connections and facilitates a positive atmosphere. Acknowledge their efforts publicly and encourage others to share similar initiatives.

4. Flexibility and Sensitivity
   Support team members through personal challenges without making them feel judged. This shows your unconditional support and reinforces their sense of safety.

   Action Point: Offer flexible working hours or additional support to a team member going through a personal hardship. Make sure they know that your support is unconditional and focused on their well-being.

5. Co-regulation
   Encourage mutual support within the team. A leader’s calm demeanor can regulate the team’s emotional state.

   Action Point: Implement a short daily or weekly check-in ritual where team members can share their current state—whether it's a challenge they’re facing or a recent success—without fear of judgment.

6. Sensory-Friendly Environment
   A workspace filled with distractions hampers productivity. Strive to create an environment conducive to deep work.

   Action Point: Identify a common distraction in your team’s workspace (e.g., noise, interruptions) and take concrete steps to minimize it, like setting up quiet hours or a designated focus zone.

Extra Resources

• Premium Article: Safety Leadership and Neuroception
  A detailed exploration of how to foster a neuroception of safety within your team, based on the Polyvagal Theory.

• PDF Cheat Sheet: Safety Leadership
  A quick reference guide summarizing the strategies discussed.

• Blog Post: Different Styles of Engineering Leadership
  Explore various leadership styles and find the one that best fits your team’s needs.

By focusing on these practical strategies, you can cultivate a safer and more productive environment for your team. Take a few minutes today to plan and act on these points.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Today's lesson focuses on evolving your leadership approach from top-down to center-out.

Top-down leadership, while efficient and clear in its directives, often limits creativity and can lead to disengagement. Center-out leadership, on the other hand, promotes autonomy, innovation, and collaboration.

This shift will help you reduce your cognitive load and empower your team to take ownership of their work, driving better product and technology outcomes.

Action Points

1. Identify Missing Context:

   • Reflect on the critical product context your team needs to operate autonomously. Consider customer pain points, business goals, and the impact of your product features.

   • You can take more insights from the lesson of Day 21.

2. Empower Decision-Making with Clear Boundaries:

   • Establish a framework of expectations and principles. For instance, set guidelines for quality standards, performance metrics, or architectural decisions, while leaving the implementation details to the team.

   • You can take more insights from the lesson of a Day 10.

3. Foster a Culture of Candid Feedback and Knowledge Sharing:

   • Encourage team members to openly share their thoughts and ideas on ongoing projects, even if they challenge the status quo.

   • You can take more insights from the lesson of a Day 4.

4. Encourage Product Understanding Among Engineers:

   • It’s crucial that engineers understand the product’s business context. This will allow them to make better decisions independently.

   • You can take more insights from the lesson of a Day 6.

5. Delegate and Follow Up:

   • Empower your team to make decisions but ensure there's a follow-up mechanism to learn from the outcomes.

   • You can take more insights from the lesson of a Day 15.

Transitioning to a center-out approach is not about giving up control but about establishing clear boundaries within which your team can innovate. This reduces your own decision fatigue and builds a more engaged and capable team.

Extra Resources

• Premium Article: Top-down Leadership vs Center-out Leadership

• PDF Cheat Sheet: Center-Out Leadership PDF

• Blog Post: Different Styles of Engineering Leadership

By adopting a center-out leadership style, you’ll foster a more dynamic and resilient team that can better respond to product and technology challenges, freeing you to focus on strategic leadership.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Welcome to Day 26! Today, we’re taking a deep dive into defining the strategic blocks of your engineering strategy.

The Goal for Today

We will translate the input collected (Day 23) into specific strategic blocks, guiding policy and coherent actions. This will provide a clear roadmap for your team to tackle challenges effectively and leverage opportunities.

Steps to Define Strategic Blocks

1. Review Your Input

Start by revisiting the data you’ve gathered about your team’s strengths, challenges, opportunities, bottlenecks, and distractions (Day 23).

2. Identify Strategic Blocks

Strategic blocks are specific focus areas that translate your input into guiding policy and actionable steps. Here’s how to define them using Engineering Strategy Template (link in the bottom):

• Leverage Objective: Focus on what will have the most significant impact with the least effort. For instance, if your team is struggling with frequent build failures or production issues, investing in automated testing and CI/CD can dramatically improve productivity and confidence.

• Proximate Objective: Set achievable, near-term goals that act as stepping stones toward your larger strategy. These should be clear, actionable, and aligned with your long-term vision. Example: For a team aiming for continuous delivery, start with implementing automated testing for a specific service before expanding to the entire system.

• Weakest Link in the Chain: Identify the primary bottleneck that limits your team’s overall performance. Focus on resolving this issue first, as it will unlock more significant improvements. Example: If cross-team communication is a bottleneck, establish engineering guilds or regular cross-functional meetings to improve knowledge sharing and collaboration.

• Power of Design: Decide how you’ll allocate resources—should teams work closely together on a single project for rapid progress, or is it better to decouple them for flexibility and parallel development?

• Using Advantage: Leverage your team’s strengths to tackle high-impact projects. If you have a strong data science team, prioritize initiatives that make use of advanced analytics to drive business decisions. If you have engineers passionate in UI/UX, pair them with Product Designers.

• Riding the Wave of Change: Align your strategy with emerging industry trends. This could mean adopting new technologies like AI or preparing for shifts such as increased remote work. Example: Early adoption of cloud infrastructure allowed Netflix to scale globally and adapt quickly to changing customer demands.

3. Prioritize and Sequence

Rank the strategic blocks by impact and feasibility. Begin with the ones that offer the highest leverage with the least resistance.

4. Develop Action Plans

For each strategic block, outline a high-level action plan. Assign an owner, set milestones, and define success criteria.

For example:

• Leverage Objective: Implement CI/CD for the core service.

  • Action Plan:

    • Automate build processes

    • Implement feature toggles for safer releases

    • Train the team on new deployment tools

• Weakest Link: Improve cross-team collaboration.

  • Action Plan:

    • Set up bi-weekly engineering guilds

    • Create a shared documentation hub

Defining strategic blocks is about making your strategy actionable. Use today’s insights to create a clear path for your team to follow.

Extra Resources

• Premium Article: Example Strategic Blocks for Engineering Strategy

• Framework & Templates: Engineering Strategy Framework

• Blog Post: How to Build Engineering Strategy

• Book Recommendation: Good Strategy / Bad Strategy by Richard Rumelt

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

As an engineering leader, your biggest challenge isn't solving technical problems—it's dealing with human nature.

Cognitive biases are mental shortcuts that can skew our judgment, leading to suboptimal decisions. While you can’t eliminate them, you can learn to recognize and manage them, both in yourself and your team.

Key Cognitive Biases to Watch Out For

1. System 1 and System 2 Thinking (After book “Thinking Fast And Slow” by D. Kahneman):

   • System 1: Fast, intuitive, and emotional thinking.

   • System 2: Slow, deliberate, and logical thinking.

   • Action: Identify situations where you or your team default to System 1 (quick decisions). Create “thinking time” during critical decision-making to allow for System 2 engagement. For instance, during sprint planning, encourage the team to take a few minutes of quiet reflection before voting on story points.

2. Snap Judgments

   • Quickly forming opinions based on incomplete information.

   • Action: Before making decisions in high-pressure situations, pause and ask yourself, “What additional information would I want if I had more time?” This simple question can prompt you to seek more data or perspectives.

3. Confirmation Bias

   • Seeking information that confirms pre-existing beliefs.

   • Action: During your next technical review, assign someone to play the role of “devil’s advocate.” This person’s job is to challenge assumptions and suggest alternative perspectives, fostering a more balanced discussion.

4. Halo Effect

   • Allowing one positive trait to overshadow all other qualities.

   • Action: When evaluating team members, use a structured evaluation framework. Separate personal opinions from performance metrics. For example, during performance reviews, focus on key deliverables, problem-solving skills, and collaborative behaviors, rather than how likeable or charismatic someone is.

5. Exaggerated Emotional Coherence

   • Letting strong emotions influence your judgment about specific projects or people.

   • Action: Use a structured framework like the PR/FAQ document to evaluate initiatives objectively. Separate the emotional appeal of an idea from its strategic value and ROI.

6. Availability Heuristic

   • Overestimating the importance of recent events or vivid examples.

   • Action: Keep a log of decisions and incidents. Review it periodically to ensure you’re basing decisions on a comprehensive view of the situation, not just recent memory. This is particularly useful during post-mortems or performance reviews.

7. Denominator Neglect

   • Ignoring the context of statistics (e.g., 100 errors may seem high, but is it really, compared to total transactions?).

   • Action: Always normalize data when presenting metrics. For example, if reporting bugs, include the number of user sessions or API calls to provide a complete picture.

Task: Identify and Mitigate Biases

Take 30 minutes today to reflect on a recent decision where things didn’t go as planned. Identify at least two cognitive biases that may have influenced the outcome. Write down how you will address these biases in the future.

Use the following questions as a guide:

1. Which biases were at play?

2. How did they influence your decision or the team’s behavior?

3. What steps can you take to minimize their impact next time?

Extra Resources

• Premium Article: Cognitive Biases for Engineering Leaders

• Visualization: Cognitive Bias Codex

• Book Recommendation: Thinking, Fast and Slow by Daniel Kahneman.

Final Thoughts

Awareness of cognitive biases is a powerful tool for any leader. By recognizing and addressing these biases, you can make more balanced, effective decisions for yourself and your team. Remember, the goal isn’t to eliminate biases, but to mitigate their influence on your decision-making.

Stay conscious and keep leading effectively!

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

You've got "20% time" from your manager to focus on technical work. Now what?

Having dedicated time for tech debt and maintenance is a great opportunity, but it can easily go to waste without a clear strategy. Today, we’ll discuss how to avoid common pitfalls and make the most out of your "20% time" by translating technical work into meaningful product outcomes.

Common Mistakes and How to Avoid Them

1. Separate Backlogs for Product and Tech

   • Problem: Isolating tech debt in a separate backlog can lead to misalignment between product and engineering teams, making technical work undervalued and deprioritized.

   • Solution: Integrate technical work into the main product backlog. Use a PR/FAQ document to articulate the value of each technical task in terms that resonate with business stakeholders. For instance, instead of listing “refactoring code,” present it as “reducing onboarding time for new developers” or “improving system reliability to minimize downtime.”

2. Lack of Understanding of Tech Work Value

   • Problem: If the business doesn’t understand the value of tech work, it’s likely to be the first thing to be deprioritized when resource constraints hit.

   • Solution: Regularly communicate the benefits of technical work to non-technical stakeholders. Use metrics and case studies, like the example of migrating from Objective-C to Swift to improve developer hiring and reduce compilation time, to make the impact clear.

3. “We’ll Fix It Later” Mentality

   • Problem: Relying solely on your "20% time" to handle all tech debt can lead to a growing backlog of issues and reduced overall product quality.

   • Solution: Maintain a baseline level of quality in every release. Use your "20% time" for strategic improvements, not for fixing issues caused by cutting corners. Always meet Non-Functional Requirements (NFRs) and SLAs/SLIs/SLOs to avoid accumulating debt.

4. Diluted Focus

   • Problem: Tackling too many initiatives at once without a clear strategy can result in minimal progress on any front.

   • Solution: Prioritize and focus on one or two high-impact initiatives at a time. Create a technology roadmap that aligns with product goals and stick to it. Use regular check-ins to assess progress and adjust priorities.

5. Ineffectiveness of One Day a Week

   • Problem: Working on big projects one day a week makes it difficult to maintain momentum and context, delaying delivery and increasing the likelihood of failure.

   • Solution: For larger initiatives, consider dedicating continuous blocks of time (e.g., a full week each quarter) to make significant progress. Alternatively, break down large projects into smaller, manageable tasks that can be completed incrementally.

Action Points

1. Translate Tech Work into Product Goals

   • List your top technical initiatives and frame each one in terms of its impact on product and business goals. You can use PR / FAQ document described on Day 18th.

2. Align with Product Objectives

   • Work with your product manager to integrate these initiatives into the product roadmap. Ensure each technical task has a clear business outcome and is prioritized accordingly.

3. Create a Unified Tech Roadmap

   • Develop a tech roadmap that outlines how each initiative will contribute to product success. Include specific, measurable goals.

4. Communicate and Review Regularly

   • Share this roadmap with key stakeholders and schedule regular check-ins to review progress. Adjust your plans based on feedback and evolving business needs.

5. Measure and Adapt

   • Use simple metrics and dashboards to track the progress of your initiatives as discussed on Day 17th. Make adjustments based on data and team feedback to ensure you’re moving in the right direction.

By following these steps, you’ll ensure that your "20% time" is a powerful tool for advancing both technical and product goals.

Further Reading

• Optimizing Your "20% Time for Technical Debt"

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Crafting a robust engineering strategy is essential to transforming from a good leader into a great one. While execution and improvement are important, strategic compounding—designing actions that build upon each other—is what truly drives long-term success.

A well-formulated strategy addresses the real challenges and opportunities your team faces, aligning actions with a clear vision.

What a Strategy Is (and Is Not)

• A Strategy Is:

  • Designed Response: A thoughtful approach to navigating your team's unique challenges.

  • Problem-Solving Oriented: It goes beyond day-to-day execution to tackle fundamental issues.

  • Coherent Plan: It includes a clear diagnosis, guiding policy, and coordinated actions.

• A Strategy Is Not:

  • Fluff Words: Avoid using trendy jargon that lacks substance.

  • A Set of Goals: Goals alone are not a strategy—they need a cohesive action plan.

  • Vision Without Execution: A dream without actionable steps or resources to achieve it.

  • A List of Problems: Trying to solve everything dilutes focus and impact.

Crafting Your Strategy: The Framework

1. Collecting Input:

   • Gather comprehensive information from your team and stakeholders on:

     • Bottlenecks & Challenges: Identify obstacles that hinder progress.

     • Strengths & Opportunities: Determine where your team excels and areas for growth.

     • Distractions: Pinpoint activities that divert focus from core objectives.

     • Current Initiatives & KPIs: Assess existing efforts and metrics for alignment.

2. Strategic Blocks Grouping:

   • Classify your findings into the following strategic blocks:

     • Leverage Points: Areas where small changes can have a significant impact.

     • Proximate Objectives: Clear, actionable goals that provide immediate value.

     • Weakest Links: Identify and address the most critical limitations first.

     • Using Advantages: Leverage team strengths and unique opportunities.

     • Riding the Wave of Change: Adapt to industry shifts and emerging trends.

3. Build the Strategy Kernel:

   • Create a Strategy Kernel using the insights gathered:

     • Diagnosis: Identify the biggest problem to solve in the next 12-18 months.

     • Guiding Policy: Outline a high-level approach for addressing the diagnosis.

     • Coherent Actions: Define specific steps aligned with the guiding policy.

4. Iterate and Refine:

   • Share your draft strategy with your team and gather feedback.

   • Adjust based on new insights and evolving challenges. Treat the strategy as a living document that evolves with time and experience.

Action Point

Leverage Your Signals of Information. Refer to the insights you collected on Day 20. Group this data into strategic blocks. Identify key bottlenecks, strengths, opportunities, and distractions that need to be addressed.

Focus just on collecting information. It'll already take much of your time. You will define your strategic kernel later (Day 26).

Extra Resources

• Premium Article and Strategy Templates: Access the Engineering Strategy Framework in FigJam for a step-by-step guide.

• Blog Post: How to Build Engineering Strategy.

• Book Recommendation: Good Strategy / Bad Strategy by Richard Rumelt.

By building a strategic framework that is diagnostic, actionable, and coherent, you empower your team to tackle the real challenges ahead. A well-thought-out strategy not only guides your team but also amplifies your impact as a leader.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Transforming an engineering organization is a multi-stage process. The marketing concept of “Crossing the Chasm” can help you navigate the gap between early adopters and the early majority, a critical point at which many transformations fail due to a lack of widespread buy-in.

Today, we’ll explore how to apply these principles to ensure your change efforts gain traction and achieve success.

Applying "Crossing the Chasm" to Engineering Teams

1. Identify Your Enthusiasts and Visionaries:
   Start by finding the champions for your new practice or technology. Look for three types of people in your organization:

   • Solution/Practice Enthusiasts: Team members who are passionate about the technology or practice you're introducing. Engage them in early pilots to test and refine your approach.

   • Visionaries: Individuals interested in strategic improvements like faster delivery or better quality. They can help you articulate the broader value of the transformation.

   • People with a Problem to Solve: Those who face specific challenges that your transformation can address. They may not be early adopters, but they are highly motivated to find solutions.

2. Build a Whole Product Offering:
   Early adopters need more than just the core change. Here are example transformations and what a complete solution may llook like:

   • QA Shift-Left: Provide clear testing principles, documentation, working examples, and infrastructure setup.

   • DevOps Culture: Offer standardized CI/CD solutions, clear responsibility splits, and team topologies that promote self-sufficiency.

   • Monolith to Microservices: Deliver microservice templates, observability setup, and unified CI/CD processes.
     Ensure that every team involved has the tools, training, and support they need to succeed.

3. Cross the Chasm:
   Move from early adopters to the early majority by demonstrating the reliability and support of new practices:

   • Share internal success stories to show tangible benefits.

   • Be available to provide hands-on support and gather continuous feedback to address any concerns or issues.

4. Establish a Beachhead:
   Choose a small, manageable project or team where you can fully implement the new practices. Focus on this niche to become the de facto standard in this area before expanding. For example, when transitioning to micro frontends, ensure one team gets the full experience: working templates, unified CI/CD processes, and dedicated support. Use this as a model for other teams.

5. Position the Change:
   Communicate the benefits and uniqueness of the new practices clearly. Use data, feedback, and success stories from the early adopters and early majority to show how the transformation is improving the organization.

   
   Highlight measurable outcomes, such as reduced deployment times, improved product quality, or faster feedback cycles. Make it clear that these are not just hypotheses but proven results.

6. Post-Chasm Focus, Distribution, and Support Channels:
   After crossing the chasm, focus on optimizing and standardizing the new practices. Establish clear channels for ongoing training and support:

   • Regular workshops, internal support teams, detailed documentation, and tutorials are essential to maintaining momentum.

   • Update team roles and responsibilities as needed to reflect the new practices, and reassign champions to new projects to drive further adoption.

Action Points

1. Identify the transformation you want to lead (e.g., introducing DevOps, adopting microservices, implementing QA Shift-Left).

2. Write down concrete action steps for each of the six points:

   • Who are your early adopters and visionaries?

   • What does your whole product plan include?

   • How will you cross the chasm and support the early majority?

   • Where will you establish your beachhead?

   • How will you position and communicate the benefits?

   • What are your post-chasm support plans?

3. Share these action steps with a trusted colleague or mentor for feedback and refinement.

Successfully leading change is about guiding your team across the chasm. With a strategic approach and focused actions, you can ensure that your transformation efforts reach their full potential.

Extra Resources

• Premium Article: Crossing the Chasm in Engineering Transformation

• PDF Cheat Sheet

• Book Recommendation: Crossing The Chasm by Geoffrey A. Moore

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Engineering leaders are not just executors of technical tasks; they play a crucial role in shaping the product vision and strategy.

Your team isn’t a cost center but a profit center, driving value through technology. This means understanding customer needs and aligning your tech strategy with the product goals.

Today, we’ll focus on how to effectively influence product decisions and ensure that your team is part of the product leadership.

Key Concepts

1. You Are a Product Leader Too
   You don’t work for product leaders; as an engineering leader, you’re part of the product leadership. Shift your team mindset from delivering tasks to contributing to strategic decisions. Use your unique perspective on technology and its capabilities to guide product strategy, not just execute it.

2. Align Engineering with Product Vision
   Your company's product vision is the reason for its existence, and it’s your job to ensure that your team understands this vision. Make it clear how their technical work contributes to achieving these high-level goals. Regularly communicate how current projects and tech initiatives align with the product vision.

3. Influence Product Decisions with Technical Insights
   Engineers are often the first to know which technical solutions can address customer pain points effectively. Leverage this knowledge to influence which problems get prioritized. Structure your tech strategy to translate technical challenges into business outcomes and present them in a way that resonates with non-technical stakeholders.

4. Focus on Outcomes, Not Just Features
   Encourage your team to think beyond delivering features and focus on the outcomes those features should achieve. Implement telemetry and success metrics to validate that your work is delivering the expected results. This shift helps the team stay focused on solving real customer problems, not just building features.

5. Increase Customer Awareness
   Ensure your team is connected to customer needs. Use customer feedback and product analytics to understand what users value most and where they struggle. Involve engineers in shadowing sessions, user interviews, or even support calls to give them a first-hand view of customer pain points and potential areas for improvement.

Action Points

1. Reflect on Product Outcomes You Contribute To
   Write down the specific product outcomes you and your team contribute to. For each recent feature or project, note how it impacts the product vision. Does it improve user satisfaction, reduce friction, or enable a new capability?

2. Connect Tech Initiatives to Product Vision
   Review your current tech initiatives. For each initiative, ask yourself: How does this support our product vision? Use this opportunity to reprioritize tasks or reframe them in a way that directly supports the product goals. Present this connection in your next team meeting.

3. Create a Proposal to Influence Product Decisions
   Choose one technical area where your team’s expertise could shape product decisions. Prepare a brief proposal on how your insights can help prioritize this area. You can use PR / FAQ document discussed on the Day 18.

4. Engage with Customer Feedback and Analytics
   Review recent customer feedback or product analytics. Discuss these insights with your team and identify one area where you could make a tangible improvement. Implement this change and monitor the impact, using it as a case study for aligning engineering work with customer value.

Implement these steps to strengthen your role in product leadership. By aligning technical work with product goals, you’ll not only enhance your team’s impact but also contribute significantly to your company’s success.

Extra Resources

• Premium Article: The Role of Engineering in Product Model Transformation - Part 3 Changing the Way Decisions Are Made About Which Problems To Solve

• PDF Cheat Sheet: Download Cheat Sheet

• Blog Post: The Role of Engineering in Product Transformation

• Book Recommendation: Empowered by Marty Cagan

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

In the ever-changing landscape of engineering leadership, making informed decisions requires more than just experience—it demands a robust system for gathering, analyzing, and acting on various signals. Today, we’ll focus on building and balancing your feedback system using internal, external, and possessed knowledge to steer your team effectively.

Understanding Your Signals

1. Possessed Knowledge: This is the collective expertise within you, your team, and your organization. While it’s instantly accessible, it can be limited by personal biases and past experiences.

2. External Sources: Insights gained from outside your organization. These include industry reports, competitor analysis, books, and conferences. They introduce new perspectives and ideas.

3. Internal Signals: Real-time data from within your organization, such as feedback from your team, observability metrics, and product analytics. These are the most direct indicators of your organization’s health.

Action Points

1. Audit Your Information Sources

   • List out your main sources of information for decision-making, categorizing them into Possessed Knowledge, External Sources, and Internal Signals.

   • Reflect on a recent key decision. Which type of signal dominates? Identify if there’s an imbalance.

2. Analyze and Adjust Your Signal Balance

   • Estimate how much time you spend on each category. For example, are you relying 70% on internal signals and only 10% on external sources?

   • Determine if this balance aligns with your current challenges. Adjust your focus as needed.

3. Implement One Improvement

   • Possessed Knowledge: Host a quick knowledge-sharing session with your team. Ask each member to share one key learning from a recent project.

   • External Sources: Schedule a 30-minute research slot to explore a new technology trend. Share your findings with the team.

   • Internal Signals: Improve your feedback system. For example, refine your one-on-one questions to probe deeper into team health and project challenges.

4. Democratize Access to Information

   • Review how your team accesses information. Is it siloed or widely shared? Pick one signal—like observability dashboards or strategic context—and ensure your team has equal access.

Extra Resources: For a deeper dive into explore my premium article: Signals of Information For Engineering Leaders - Your Sources of Data and Feedback.

By effectively balancing internal, external, and possessed knowledge, and making these signals accessible to your team, you’ll foster a more informed and agile organization. Take time today to audit and adjust your feedback system to stay aligned with your leadership goals.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Change in technology is often easier than change in people. As leaders, we need to recognize that reluctance to adopt new methods, processes, or cultural shifts is a natural response. Using the Problem Solving Framework (discussed on the Day 12), we can break down this resistance and address it methodically.

One frequent scenario in growing organizations is the tension between the Old Guards—those who thrived in a start-up environment—and the New Guards, who are focused on scaling and formalizing processes. This friction needs careful management to avoid disruption and achieve a smooth transformation.

Identify a People Problem

Today let's try to apply Problem Solving Framework to one of the peoples' problems. Select a current situation where you’re facing resistance to change. It could be an individual or a group showing signs of reluctance, such as cynicism, passive sabotage, or clinging to old tools and processes.

How to Apply the Problem Solving Framework

1. Recognize the Problem:

   • What specific resistance are you facing? Be clear about the symptoms—whether it’s passive resistance, vocal pushback, or avoidance of new processes.

   • Example: “Anna resists the shift to DevOps practices, preferring her established routines.”

2. Define the Problem:

   • State the facts without judgment. Why is this resistance a problem for your team’s progress?

   • Example: “Anna’s resistance is slowing the team’s adoption of automated testing, impacting our deployment speed and quality.”

3. Explore the Problem’s Depths:

   • Dig deeper during 1:1 sessions to understand the root causes. Use this time to listen to their concerns and fears without pushing your agenda.

   • Example questions:

     • “What’s your biggest concern with the new process?”

     • “What past experiences make you hesitant about this change?”

4. Identify Stakeholders:

   • Who else is impacted by this resistance? Consider other team members, project timelines, and transformation leaders.

   • Example: “The frontend team is relying on automated testing to meet their sprint goals, but Anna’s reluctance is causing delays.”

5. Assess the Willingness to Solve:

   • Evaluate whether it’s worth pushing for immediate change or if it can be addressed later. Can you achieve success with your current change agents?

   • Example: “There are enough supporters of the transformation in other teams. We can proceed and revisit Anna’s concerns later if needed.”

6. Develop Solution Strategies:

   • Choose a few strategies based on your insights. Possible options:

     • Leading by Example: Have enthusiastic team members share their success stories.

     • Small Wins: Implement smaller changes first to build confidence.

     • Training: Provide tailored training sessions to bridge knowledge gaps.

7. Implement the Solution:

   • Roll out the selected strategy and monitor closely. Set clear expectations and timelines.

   • Example: “Introduce automated testing for non-critical features first, and offer support sessions for those hesitant to adopt.”

8. Monitor and Review:

   • Regularly check in on progress and be open to adapting your approach. Celebrate small wins and share these successes to build momentum.

   • Example: “After three sprints, measure the adoption rate and gather feedback from Anna and her peers.”

Document and Share

Keep a record of your findings, strategies, and outcomes. Share them with your peers to help them tackle similar challenges in their teams. For better structure, you can you Problem Solving Framework template, available as Notion or FigJam. Check links below for more.

Extra Resources:

• Premium Article: How to Work with Teammates Resistant to Change

• The Problem Solving Framework

• Individual Contributors - From Holdouts to Holdups from IT Revolution.

Resistance is just another problem to solve. By systematically applying the Problem Solving Framework, you can transform resistance into engagement, paving the way for successful change.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

A critical skill for engineering leaders is the ability to translate technical work into clear business and product value.

One of the effective ways to do this is through Amazon’s “Working Backwards” approach, using a PR/FAQ document. This method helps bridge the gap between engineering and product teams by framing technical initiatives in a way that is accessible and compelling to all stakeholders.

What is the PR/FAQ?

The PR/FAQ (Press Release / Frequently Asked Questions) is a concise, customer-focused document that describes the future state of a product as if it were already launched. This storytelling technique helps align all stakeholders around a clear vision and the expected outcomes, making it easier to communicate the value of technical work.

Why Use PR/FAQ?

For engineering leaders, PR/FAQ documents are a powerful tool to justify technical projects that might not have obvious product value at first glance. They provide a structured way to answer critical questions such as:

• What problem does this technical initiative solve?

• How does it benefit customers or the organization?

• What are the measurable outcomes we aim to achieve?

This exercise not only clarifies the purpose of the project for non-technical stakeholders but also helps you, as the leader, to critically evaluate and refine the initiative before seeking broader support.

Example Projects

If you need inspiration for what project you could use PR/FAQ document, here are the examples:

• Moving CI/CD solutions from local servers to the cloud.

• Migrating a web app to micro frontends architecture.

• Building an in-house Design System solution.

• Implementing the foundation for observability practices (SLI/SLO definition, monitoring, and alerting).

• Migrating an app from one language to another.

• Introducing QA-Shift Left to the organization.

Action Point: Write Your Own PR/FAQ

1. Select a Project:

   • Choose one technical project from your current backlog or tech debt list. Follow the steps below to create a PR/FAQ document that clearly articulates its value:

2. Use the PR/FAQ Template (link to the template in Extra Resources below):

   • Heading: Create a headline that succinctly describes the project in customer-focused language.

   • Subheading: A one-liner summarizing the benefit to customers or stakeholders.

   • Summary Paragraph: Briefly describe the project, its purpose, and its benefits.

   • Problem Paragraph: Define the problem this project solves from a customer or business perspective.

   • Solution Paragraph: Explain how your project addresses the problem and what the final outcome will be.

   • Getting Started: Outline how customers or teams will begin using or benefiting from the project.

   • Quotes: Include at least two quotes (one internal, one external) that reflect the value of the project.

   • FAQ: Address potential questions stakeholders might have about the project.

3. Hold a Review Meeting:

   • Present the PR/FAQ to your team and key stakeholders.

   • Collect feedback, refine the document, and ensure everyone is aligned on the project's goals and value.

Extra Resources

• Amazon’s Original “Working Backward” Materials.

• Premium article with templates and example PR/FAQ document: Working Backwards: Creating Effective PR/FAQ Documents.

• Working Backwards book by Bill Carr and Colin Bryar.

• PR/FAQ template as:

  • Google Doc

  • Notion Template

Writing a PR/FAQ is a practical way to translate complex technical efforts into clear product value. It can transform the way you communicate with stakeholders and lead your team. Take the time to craft these documents, and you'll find the process itself is invaluable for refining and validating your ideas.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

As an engineering leader, effectively tracking your goals and key performance indicators (KPIs) is crucial for ensuring progress and making informed decisions. While some organizations have mature data stacks with comprehensive dashboards, many need simpler, quicker solutions that can be set up in less than a day and updated in minutes.

This lesson provides practical guidance on setting up easy-to-maintain tracking systems using accessible tools like Google Sheets, Looker Studio, and BigQuery. The focus is on starting small, iterating, and automating gradually to suit your needs.

Step-by-Step Guide

1. Define Your Objectives:

   • Identify Key Metrics: Begin by listing the KPIs, SLOs, and other metrics that are most relevant to your team’s success. Prioritize those that are actionable and aligned with your goals.

   • Set Clear Targets: For each metric, establish clear, measurable targets. Use the SMART framework to ensure your goals are Specific, Measurable, Achievable, Relevant, and Time-bound.

2. Example Tools and Solutions:

   • Basic Tracking with Google Sheets:

     • Create a Google Sheet with columns for each metric, target values, current status, and a progress bar.

     • Utilize conditional formatting to highlight deviations from your targets.

     • For manual data entry, update the sheet regularly—ideally, at the same time each week.

   • Automated Reporting with Looker Studio:

     • Connect your Google Sheets to Looker Studio for a visual dashboard.

     • Use various visualizations like time series, column charts, or scorecards to make your data easy to interpret.

     • If you prefer automated data integration, you can connect Looker Studio directly to a BigQuery table or CSV files.

   • Automating with BigQuery and Cloud Functions:

     • Set up a scheduled query in BigQuery to fetch and aggregate data from your cloud databases.

     • Use a simplified table in BigQuery to make the data easily accessible for Looker Studio, reducing the cost and complexity of frequent queries.

3. Review and Adapt:

   • Weekly Team Review: Dedicate 30 minutes each week to review progress, discuss any issues, and refine your tracking approach as needed.

   • Monthly Summary for Stakeholders: Prepare a monthly report summarizing key insights and actions to share with external stakeholders. Focus on transparency and continuous improvement.

Further Reading

• Blog post with example solutions: Simple Data Tracking Solutions for Engineering Leaders

• Premium article with example implementations: Practical Solutions to Track Your Goals

• Measure What Matters by John Doerr

By implementing these solutions, you'll have a reliable system to monitor your team's progress and make data-driven decisions. Start with a simple setup and build on it as your needs evolve.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Managing the growth and expectations of your team is a critical responsibility that goes beyond performance reviews and salary discussions. Especially in early or growth-stage companies where structured processes may be lacking, clear communication and a proactive approach are essential.

Misalignment in expectations can lead to an illusion of high performance, which hinders personal development and team success.

Leaders often shy away from giving honest feedback, creating a culture where employees believe they are performing well based on incomplete or inaccurate feedback.

Define and Communicate Clear Expectations

• Use a Framework: If your company has a career ladder or progression framework, use it to define what meeting, exceeding, or falling short of expectations looks like. If not, create a simple guideline based on skills, attitudes, and impact relevant to your team.

• Discuss Regularly: During your next 1:1, clearly articulate these expectations and ensure your team members understand them. Repeat this conversation regularly to reinforce clarity.

Proactive Expectation Management

• Set Baseline Expectations: Make sure your team knows what is expected of them versus what would be considered going above and beyond. Use your career ladder or create a simple document outlining these expectations.

• Ongoing Feedback: Don’t wait for formal review periods to discuss performance. Address gaps and achievements as they arise to keep everyone aligned.

Make Performance Reviews a Continuous Process

• Reflect on the Past: Use 1:1 notes to look back on the progress made and challenges faced. Evaluate performance against the set expectations, and identify areas of improvement and achievement.

• Plan for the Future: Use the SMART framework to set actionable goals for the next 3-6 months. Align these goals with the individual’s career aspirations and the company’s strategy. Encourage team members to contribute their goals as well to ensure ownership and alignment.

Homework

Write down the list of expectations for each role in your team, using your company’s career ladder if available, or create one if not. Share and discuss this list during the next 1:1 meeting with each team member. This sets a clear foundation for future discussions and growth.

Extra Resources

• Premium Article: Managing Growth and Expectations in Engineering Teams

• Cheat Sheet PDF: Download Here

• Template for Paid Subscribers: How to Build Career Progression Framework

Effective people management requires ongoing commitment, transparency, and empathy. By setting clear expectations and providing continuous feedback, you build a strong foundation for your team’s growth and success.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

A successful engineering team is not just about achieving technical excellence with on-demand releases, test automation, and feature flags.

While continuous delivery is critical, it’s not the end goal. It defines the throughput of our software production line but doesn’t determine how effectively we’re solving customer problems.

Once we’ve mastered efficient delivery, it's time to shift focus to transforming the way we solve problems. As highlighted in Marty Cagan’s book “Transformed”, this involves moving beyond feature factory thinking to a more customer-centric approach. Here are practical ways to drive this transformation:

1. Understand Requirements as Hypotheses
   Every "requirement" you receive is likely an assumption. Treat it as a hypothesis to be validated, not a fixed mandate. Focus on collecting data post-launch to assess its real value. Adjust your mindset: a product roadmap is just a prioritized list of bets.

2. Build Credibility with Stakeholders
   Establish trust by demonstrating that your team is not merely a delivery engine. Share valuable insights and propose innovative solutions. Encourage stakeholders to bring you problems to solve rather than just tasks to complete.

3. Partner with the Product Organization
   Instead of pointing out flaws in the product roadmap or technical constraints, collaborate actively to find better solutions. Discuss potential approaches using your technical expertise and align on shared goals.

4. Reframe Tasks to Discover Root Causes
   Dig deeper into the intent behind each task. Use frameworks like the "Five Whys" or the Problem-Solving Framework to uncover the real issues, identify the true stakeholders, and assess their willingness to address these problems.

5. Translate Technical Issues into Business Value
   When faced with technical debt or infrastructure challenges, frame them in terms of business impact. How do they affect customer experience, delivery speed, or scalability? Present these issues alongside feature work, emphasizing their relevance to business outcomes.

6. Engage in the Discovery Process
   Participate actively in product discovery. Use your technical knowledge to validate ideas quickly and efficiently, reducing time to market. Employ techniques like MVPs, Proof of Concepts, or Prototypes to test ideas at a fraction of the cost and time required for full-scale implementations.

By embracing these practices, your team can help shift the organization towards a more effective Product Operating Model.

Action Points

1. Evaluate Your Role in Product Discovery
   Reflect on your involvement in product discovery. Schedule a meeting with your product counterparts this week to discuss how you can contribute earlier in the process, influencing the way problems are framed and solved.

2. Reframe Your Current Tasks
   Look at your backlog and treat each task as a hypothesis. Reframe these tasks using your engineering insights. Engage your team and stakeholders in a discussion about potential underlying issues or better approaches to solving the identified problems.

3. Showcase Technical Problems as Business Challenges
   Use your existing telemetry and monitoring tools to highlight technical issues that impact business outcomes. Create a brief report that connects these problems to customer experience, delivery efficiency, or costs. Present it to the product team to help prioritize technical work effectively.

Additional Resources:

• Premium Article: The Role of Engineering in Product Model Transformation - Part 2 Changing the Way Problems Are Solved

• Cheat Sheet PDF: Download Here

• Book: Transformed by Marty Cagan

• Blog Post: The Role of Engineering in Product Transformation

Transform the way your team contributes to solving customer problems today!

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

In software engineering, waste is any activity that does not contribute to delivering value to the customer. Identifying and eliminating these inefficiencies can significantly enhance your team's productivity and delivery speed. Today, we’ll briefly discuss the ten types of software engineering waste and how you can start addressing them.

Why This Matters:
Much like Toyota's Production System revolutionized manufacturing by reducing waste, software engineering can benefit from similar principles. By recognizing and eliminating waste, you can streamline your processes, improve product quality, and respond to customer needs more effectively.

Ten Types of Software Engineering Waste

1. Partially Done Work and Backlog Mismanagement:
   Unfinished features and an overgrown backlog drain resources and cause delays.

2. Extra / Wrong Features:
   Building unnecessary or incorrect features leads to wasted effort and complicates the product.

3. Defects / Rework:
   Defects caught late are costly to fix and disrupt planned work.

4. Unnecessarily Complex Solutions:
   Over-engineering increases maintenance costs and complicates the tech stack.

5. Task Switching and Cognitive Load:
   Frequent context switching reduces productivity and increases the chance of errors.

6. Handoffs and Knowledge Loss:
   Each handoff can lead to a loss of information and disrupts flow.

7. Heroics and Rush Mode:
   Relying on heroics for last-minute fixes or changes is unsustainable and risky.

8. Non-utilized Talent:
   Underutilizing your team’s skills stifles creativity and innovation.

9. Waiting:
   Delays due to dependencies or approvals stall progress and waste time.

10. Extra, Nonstandard, or Manual Work:
    Manual and non-standard processes are error-prone and inefficient.

For detailed actions on how to address each type of waste, refer to the original article linked in Extra Resources below.

Action Point: Classify Waste in Your Team

1. Identify Wastes:
   Gather your team and use the ten types of waste as a framework to identify inefficiencies in your processes.

2. Prioritize:
   Use a value/effort matrix to decide which types of waste to tackle first.

3. Create Actionable Tasks:
   Assign specific tasks to team members to address the most impactful wastes. Review progress in your next sprint planning.

Extra Resources:

• Ten Types of Software Engineering Waste (Premium Article)

• Cheat Sheet PDF

• The research paper "Software Development Waste"

• DevOps Culture for Engineering Leaders (Blog Post)

• Book: The DevOps Handbook

Understanding and reducing waste in your engineering processes is key to delivering value more efficiently. Start by identifying the biggest sources of waste in your team and take steps to address them today!

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Boosting productivity in software development teams is not just about improving tools or processes; it's about creating a supportive environment where developers can thrive. Research highlights the top ten factors that correlate most with productivity. As a leader, your role is to assess these factors within your team and take targeted actions to enhance them.

Top Ten Productivity Factors

1. Enthusiasm for the Job
   Developers who are passionate about their work tend to be more engaged and productive.

2. Support for New Ideas
   A team that welcomes innovation and experimentation is more likely to find creative solutions to complex problems.

3. Decision-Making Autonomy
   Empowering developers to choose their own methods fosters ownership and accountability.

4. Time Management Autonomy
   Flexibility in managing their schedules allows developers to work more effectively.

5. Efficient Project Management
   Skilled and communicative project managers significantly impact the team's ability to meet goals.

6. Accurate Information
   Clear and precise information, such as user stories and bug reports, prevents misunderstandings and rework.

7. Positive Team Relationships
   Good relationships within the team contribute to a supportive and collaborative environment.

8. Personal Judgment
   Allowing developers to use their judgment in problem-solving boosts confidence and efficiency.

9. Quick Conflict Resolution
   Addressing conflicts promptly prevents disruptions and maintains team harmony.

10. Highly Capable Engineers
    A team of skilled and cooperative engineers is essential for high productivity.

Action Points

1. Evaluate Your Team

   • Review your team against these factors. Identify strengths and areas needing improvement. Use a simple rating scale (e.g., 1-5) for each factor.

   • Focus on the top 2-3 areas that could have the most impact if improved.

2. Conduct an Anonymous Survey

   • Design a survey that measures these productivity factors across the organization (you can collaborate with the HR team). Use the results to identify broader trends and areas of focus.

3. Create a Plan for Improvement

   • Develop a clear action plan for the areas identified in your evaluation. Set specific, measurable goals and involve your team in the process.

Additional Resources

For detailed practical steps and more insights on how to implement these factors in your team, refer to the following resources:

• Premium Article: Top Ten Factors of Developers' Productivity

• Article's PDF Cheat Sheet

• Research Paper: What Predicts Software Developers' Productivity?

Understanding and optimizing these factors will improve your team's productivity and create a more positive and engaging work environment.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

Today's focus is on transforming how you and your team approach challenges using a structured Problem Solving Framework. By working through this process, you ensure your team tackles the right problems in the right way, leading to better product outcomes and stronger alignment with your organization’s goals.

Problem Solving Framework

Effective problem-solving isn't about jumping quickly into solutions; it's about solving the right problems in the right way.

This 8-step framework will help you define, decompose, plan, and execute solutions to most challenges, ensuring a structured and thoughtful approach.

1. Recognizing the Problem (What’s the problem?)

   • Start by acknowledging the issue. A problem might be a gap between what is desired and what is perceived. Resist the urge to jump into solutions; instead, take a step back and ask, “What’s the actual problem we need to solve?”

2. Defining the Problem (What are the facts behind the problem?)

   • Clearly articulate and define what the problem is. Gather and analyze relevant data, separating facts from opinions. An example definition might be: “Customers are experiencing a high number of errors when completing transactions.”

3. Exploring the Problem's Depths (What are the root causes of the problem?)

   • Look beyond the surface to understand the complexity of the problem. Use techniques like the 5 Whys or Fishbone Diagrams. Investigate root causes by interviewing stakeholders or analyzing historical data.

4. Identifying Stakeholders (Who has the problem?)

   • Identify all parties impacted by the problem, such as end-users, customer support, and your engineering team. Understand their perspectives, pain points, and needs. This step ensures that all voices are considered in the solution.

5. Assessing the Willingness to Solve (Is it worth solving the problem?)

   • Evaluate if the problem aligns with broader goals and strategy. Consider the impact, feasibility, and resources required. Decide whether solving this problem is the best use of time and effort.

6. Developing Solution Strategies (What are the options for solving the problem?)

   • Brainstorm and list potential solutions. Encourage creative thinking and consider various approaches. Evaluate each option based on feasibility, impact, and alignment with goals. Select the optimal solution, ensuring it addresses root causes.

7. Implementing the Solution

   • Plan and execute the chosen solution. Define clear steps, assign responsibilities, and set timelines. Keep stakeholders informed throughout the process. Make adjustments as needed to stay on track.

8. Monitoring and Reviewing (Are success metrics defined and achieved through the solution?)

   • Establish metrics to measure success. Regularly review progress against these metrics. For example, track a decrease in error reports or an increase in customer satisfaction. Be prepared to pivot if necessary.

Why This Framework Matters

Engineering teams often fall into two traps: jumping to immediate solutions without understanding the problem or overthinking it to the point of analysis paralysis. This framework helps balance both perspectives, encouraging thoughtful consideration while maintaining momentum.

Action Points

1. Select a Current Project: Choose an ongoing product project, task, or epic that your team is currently working on.

2. Apply the Framework: Reframe the chosen project using each step of the Problem Solving Framework outlined above. For example, if customers are reporting errors in a feature, go through each step to find the optimal solution.

3. Document Findings: Summarize your findings for each step in a concise document. This will not only clarify the problem but also provide a clear action plan for your team.

4. Discuss with Your Team: Share your document with the team and discuss how this reframing affects your current approach. Encourage input and collaborative refinement of the proposed solution.

Extra Resources

• Article for Subscribers: The Problem Solving Framework. The content includes templates in FigJam and Notion which you can use to run a brainstorming session to reframe your problem.

• Cheat Sheet (PDF): Download here

• Recommended Book: Are Your Lights On? by Don Gause and Gerald Weinberg

By taking a structured approach to problem-solving, you'll not only develop better solutions but also foster a culture of thoughtful and effective problem management within your team. Start reframing your challenges today!

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.

As an engineering leader, it's not enough to ensure your team delivers product features; you must also ensure these features are built to last. This is where Non-Functional Requirements (NFRs) come in.

NFRs define the technical standards your software must meet to be performant, reliable, secure, and scalable. They complement the functional requirements set by Product Managers and ensure your tech stack maintains quality while scaling effectively.

Define Your NFRs

1. Define Essential NFRs for Your Tech Stack

   • Start Simple: Focus on 3-5 key NFRs that are most critical to your product’s success. Consider performance, scalability, reliability, usability, and security as starting points.

   • Customize for Context: Tailor NFRs to your product and tech stack. For example, a backend service might prioritize response times and uptime, while a mobile app might focus on performance or UX crashes.

   • Action Step: Use the Markdown or Notion template to document your initial NFRs. Make them specific and measurable. For example, “API response time should not exceed 2 seconds under normal load.”

   

2. Integrate NFRs into Your Development Process

   • Incorporate into 'Definition of Done': A feature is not complete until it meets its associated NFRs. This ensures quality is baked into the product from the start.

   • Sprint Planning and Reviews: Include NFRs in sprint planning and review meetings. Discuss potential impacts on performance, security, and scalability for upcoming features.

   • Action Step: Organize a team meeting to integrate NFRs into your Definition of Done and sprint planning. Use examples from the AWS Well-Architected Framework or Twelve-Factor App Methodology to guide the discussion.

3. Establish Measurement and Monitoring

   • Tools and Metrics: Select appropriate tools to monitor each NFR. For performance, consider using tools like Grafana or New Relic. For security, implement automated vulnerability scans.

   • Set Benchmarks: Define acceptable thresholds for each NFR. For example, backend uptime should be 99.9%, and the frontend should comply with Core Web Vitals for at least 90% of users.

   • Action Step: Set up a basic monitoring dashboard for one critical NFR. Start small, such as tracking backend API response times, and review this metric weekly with the team.

4. Iterate and Evolve Your NFRs

   • Feedback Loops: Regularly review NFRs in retrospectives or quarterly reviews. Adjust them as needed based on team feedback and changing product needs.

   • Stakeholder Input: Align NFRs with stakeholder priorities and business goals. For instance, if the product roadmap shows a major user growth target, focus more on scalability.

   • Action Step: Schedule a quarterly review session to assess the effectiveness of current NFRs and incorporate feedback from stakeholders and team members.

Extra Resources

• Article For Paid Subscribers: Non-Functional Requirements

• Blog Post: How to Build Collective Intelligence and Empower Decision-Making

• Templates to Define Your First NFRs:

  • Markdown Template

  • Notion Template

• Examples of Inspiration:

  • Core Web Vitals - Essential metrics for web performance.

  • The Twelve-Factor App Methodology - Guidelines for building scalable and maintainable applications.

  • AWS Well-Architected Framework - Best practices for cloud systems.

  • Google's Site Reliability Engineering - Balancing reliability and feature development.

NFRs are not just technical details—they are strategic tools that ensure your product is functional, reliable, scalable, and user-friendly. Integrating NFRs into your development process bridges the gap between product features and long-term quality, creating a tech stack that is built to last.

Share Your Feedback

How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.

Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.

Do you know anyone who can benefit from the content I share? If so, please forward this email to them.