Before enlightenment; chop wood, carry water. After enlightenment; chop wood, carry water.

Zen Kōan

Software Engineer Titles Have (Almost) Lost All Their Meaning

• 🏷️ Software engineer titles have become increasingly devalued, with the “senior” designation being given to developers with just 3–4 years of experience — far less than traditionally required.

• 💼 A true senior engineer should be a “battle-tested problem solver” with diverse project experience, architectural vision, crisis management skills, mentorship abilities, and continuous learning habits.

• 💰 Key causes of title inflation include:

  • Companies using fancy titles as compensation when they can't match bigger salaries

  • The “LinkedIn Effect” turning titles into personal branding tools

  • HR departments creating a proliferation of niche titles

  • Organizations using promotions as retention strategies

• ⚠️ This inflation creates dangerous mismatches between expectations and capabilities, putting people in roles they aren't prepared for and eroding industry integrity.

• 🛠️ Potential solutions include: — Creating meaningful career progression frameworks tied to concrete skills — Implementing level systems (L3, L4, L5) similar to larger tech companies — Standardizing title structures with transparent expectations — Developing skill matrices for more objective evaluation

• 🌟 Companies that resist title inflation gain competitive advantages — attracting talent who value authentic growth, improving hiring accuracy, fostering trust, and building stronger teams.

SPACE Framework: 5 Metrics That Actually Work

• 🔍 The SPACE framework provides a multidimensional approach to measuring engineering effectiveness, developed by researchers from GitHub, Microsoft, and the University of Victoria in 2021.

• 📊 Five key dimensions determine engineering productivity — all more meaningful than traditional “vanity metrics” like ticket counts:

  • Satisfaction and Well-being — tracking work-life balance, team satisfaction

  • Performance — measuring outcomes like feature adoption, not just output

  • Activity — understanding time distribution across various development tasks

  • Communication — monitoring review times, knowledge sharing effectiveness

  • Efficiency — tracking flow state disruptions, context switching, and dependencies

• 🔥 Most companies make the mistake of tracking what's easy to measure (lines of code, PR counts) rather than what actually matters — “outcome over output.”

• ⚠️ Implementation advice: start with just 3–4 metrics that matter now, include one current strength, share data transparently, and let teams own their solutions.

• ⏱️ The optimal timeframe for measuring is 6–9 months — changing metrics quarterly is too frequent for meaningful behavioral change.

• 🤝 Different levels of leadership should align on core metrics while maintaining flexibility at the team level where the work happens.

• 💡 The author learned this framework changed their perspective after seeing teams optimize for vanity metrics while actual product development crawled to a halt.

Design Your Organization for the Conflicts You Want to Hear About

• 🏢 When designing an organization, the primary goal should NOT be reducing the span of control, but rather “designing for conflict” — specifically for the conflicts you want to hear about.

• ⚔️ Key insight: When you combine departments under one leader, you silence conflicts between them as the leader resolves issues internally — preventing important tensions from reaching executive leadership.

• ❓ The fundamental question in org design: “Which conflicts do you want to hear about?” since these represent strategic issues where leadership can add the most value.

• 🧠 Examples of important conflicts that get silenced through reorganization:

  • Combining PM and Engineering hides conflicts about specs, resources, and timelines

  • Putting Marketing under Sales silences conflicts about targeting and lead follow-up

  • Merging Customer Success into Sales conceals issues about overselling

• 💡 The second key principle is “ensure value-add” — never put department B under leader A unless that leader can genuinely add value to both areas (not just for empire-building).

• 🛠️ Three strategies to mitigate signal loss as organizations grow:

  • Build a culture of transparency where frank discussion is rewarded

  • Run extended quarterly business reviews that include direct reports to executives

  • Use strong reporting and metrics to see through organizational layers

• 🌟 The value-add principle creates positive effects: it defeats empire building, encourages executive learning and development, and helps attract stronger department heads.

Engineering Managers' Guide to Effective Annual Feedback

• 📝 Annual feedback cycles serve multiple important purposes: • Recognition and support for self-reflection and growth • Alignment with team and company needs • Documentation of performance for future decisions • Relationship building and organizational understanding

• ⏱️ Preparation is essential and should include: • Reviewing company requirements, career ladders, and values • Scheduling calls to gather additional feedback • Blocking 4+ hours per person for thorough review • Preparing specific examples to support feedback points

• 💪 The author recommends a “Strength-Based Feedback” approach — acknowledging that weaknesses can only be managed, not fixed, and focusing on helping people excel at what they do best.

• 📄 For organizing feedback materials, the author uses this structure: • Kickoff thoughts (unbiased initial assessment) • Others' feedback (peer, 360°, self-review) • 1:1 notes review and previous year's review • The actual feedback document • Delivery notes

• 🗣️ For delivery, the most effective approach is having a live high-level discussion first, then sending the written feedback afterward — avoiding on-the-spot negotiations or compensation discussions.

• 🤖 On using AI tools: the author takes a pragmatic approach, using LLMs to help kickstart ideas, summarize, structure, and validate drafts — but not to extend text or make it sound more official.

• 🔄 Important follow-up steps include:

  • Being open to minor adjustments based on feedback

  • Using the feedback as foundation for next year's goals

  • Supporting those with performance warnings

  • Preparing promotion packages when appropriate

  • Reflecting on the process to improve for next year

Frustrated by rejection? How to plan before you ask

• 🤔 “It doesn't hurt to ask” is a myth — asking can actually have significant costs:

  • Using your social capital

  • Making others question your judgment

  • Creating awkwardness • Straining relationships

  • Changing relationship dynamics in ways that are hard to undo

• 📊 Strategic approach to making requests:

  • Plan before you ask

  • Give people compelling reasons to say yes

  • Show them why they'll be glad to help you

  • Frame how it benefits them, not just you

• 🔄 Rethink your “funnel” approach:

  • Traditional approach: ask many people, expecting 99% rejection

  • Better approach: ask fewer people who have reason to say yes

  • Focus quality effort on more promising opportunities

• 👥 Make it less about you:

  • Ask, “How can I make this more about the other person?”

  • Question if you need to share all those details

  • Consider what you expect the person to do with the information

  • Frame your request with the other person in mind

• 💡 Key insight: The responsibility is on you to stack the odds in your favor by thinking strategically about how, when, why, who, and what you ask for.

Dealing with teams with competing priorities and needs

An organizational challenge explained

🏦 The business context:

• A fintech company helping businesses consolidate client money from multiple banks
• Each new client requires creating specific integrations with their bank
• USA has 4000+ banks without a unified integration standard

🚨 The original problem:

• Account Team faced multiple competing responsibilities
• Technical debt increasing with each new integration
• Maintaining past integrations becoming more costly
• Onboarding new clients becoming a bottleneck

🔄 The first attempted solution - splitting into two teams:

• Account Opening Team - responsible for client onboarding
• Account Integration Team - responsible for technical implementation

⚠️ Why this solution created new problems:

• Teams remained co-dependent despite the split
• Competing success metrics created conflict
• Account Opening Team gained business visibility without autonomy
• Account Integration Team became a “feature factory”
• Technical debt continued to grow
• No time for learning or improvement
• Developers became demoralized

💡 The proposed alternative solution:

• Create an isolated Account Integration Platform Team
• Build a self-service integration platform for internal use first
• Start small (4 people) to prevent falling back into old patterns
• Maintain existing operations while developing the new approach
• Collaborate with Account Integration Team to understand their pain points
• Eventually merge the platform team back into Account Integration Team

🔑 Key principles of the solution:

• Enhance team autonomy by reducing dependencies
• Address Account Opening Team needs first, but also Integration Team needs
• Create an internal product before attempting client-facing solutions
• Use isolation to overcome organizational inertia
• Target early adopters to build ownership
• Avoid creating an “us vs. them” culture

That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up and share this issue with your friends and network.

See y’all next week 👋