The Manager's Guide – #86
Weekly Hand-Picked Collection Edition
"Achieving a goal only changes your life for the moment. That's the counterintuitive thing about improvement. We think we need to change our results, but the results are not the problem. What we really need to change are the systems that cause those results. When you solve problems at the results level, you only solve them temporarily. In order to improve for good, you need to solve problems at the systems level. Fix the inputs and the outputs will fix themselves. You do not rise to the level of your goals. You fall to the level of your systems." - James Clear
The Best Process Might Be No Process 🔪
Want to boost productivity? Instead of adding another process, try killing one.
Pick your most painful process and ask:
Would anyone notice if it disappeared?
Does anyone actually use the output?
Could a Slack message do the job?
Pro tip: “Forget” to run that process for 2 weeks. No complaints = safe to kill.
💡Your challenge this week: Find one zombie process and end it. Trust me, it won't bite back.
Making engineering strategies more readable
📄 The traditional sequence for creating strategy (explore, diagnose, refine, policy, operation) is effective for writing but problematic for reading and implementation
🎯 Most strategy readers want quick answers to specific questions rather than understanding the complete reasoning behind decisions—they “muddle through” rather than deeply analyze
🔄 Recommended structure for readable strategies:
Policy (what's required/allowed)
Operation (how it's enforced)
Refine (key details)
Diagnose (trends/observations)
Explore (context)
⚠️ Common pitfalls of poorly structured strategies:
Readers give up before reaching important conclusions (“too long, didn't read”)
Approval meetings get derailed by discussion of research rather than focusing on policy
New team members challenge decisions without understanding historical context
🛠️ Key recommendations for effective strategy documents:
Get feedback from someone uninvolved in the strategy development
Include explicit commenting periods and office hours during rollout
Maintain consistent metadata (creation date, approval status, where to ask questions)
Disable in-document commenting after release to keep the document clean
Be willing to refactor and merge sections to improve readability
Use company-specific strategy templates
💡 Most important takeaway: The success of a strategy often depends more on how effectively it can be consumed and implemented by readers than on the quality of thinking behind it
Three Laws of Software Complexity
or: why software engineers are always grumpy
🔄 The First Law — Well-designed systems inevitably degrade into badly designed ones over time, as each modification either maintains or worsens the design quality, creating a one-way path toward complexity
🏰 The Second Law — Complex APIs and implementations serve as competitive moats for successful software systems, as they're deliberately made difficult to replicate or replace (e.g., ZooKeeper, Kafka)
🌋 The Third Law — There is no ceiling to how complex software can become, as it's shaped by human factors like office politics, personal preferences, and historical decisions that create “booby-trapped palaces of ticking complexity time-bombs”
👨💻 Core Insight — Software engineers often seem grumpy because they're destined to work with badly designed systems, as these three laws ensure that most systems either start complex or become complex
Getting buy-in to get things done
👥 True buy-in goes beyond mere agreement — it's about getting people to actively work toward the goal, not just nod along. As the author notes: “it's much easier for someone to agree something should happen than to actually do it themselves”.
🎯 Strong signals of real buy-in include: people making concrete suggestions, willing to make trade-offs, creating detailed plans, and comfortable pushing back on specific aspects — “There's always a no of some form, to some detail”
🗣️ Effective strategies for building buy-in: start by listening and understanding perspectives, clearly explain the “why” behind initiatives, help clarify and navigate trade-offs, and work collaboratively on concrete implementation plans
⏳ Long-term trust is foundational — it makes everything easier and can be built through transparency, owning mistakes, public praise (with consent), and informal connections like coffee chats
Managing a bottleneck team
A bottleneck team is one that others depend on to complete their work, like platform teams, infrastructure teams, or teams with unique technical expertise.
📊 Mathematical Challenge — These teams typically don't scale with company growth, creating an ever-widening gap between capacity and demand. As one manager noted: “If there is a certain probability of a project needing work from your team... over time, your team will have an ever-growing backlog”.
🛡️ Management Strategies — Several effective approaches emerged: implementing “Hero” rotations to handle interruptions, creating “Cones of Silence” for focused work, and establishing strong alignment with management to protect against “stakeholder bullying”
🔧 Architectural Solutions — Many bottleneck issues stem from architectural decisions, suggesting that structural changes might be more effective than process improvements
🤝 Contribution Models — Two successful patterns for reducing bottlenecks: moving to a self-service model where possible, and adopting an “open source” approach where other teams can contribute under supervision
📝 Organizational Tactics — Simple but effective strategies include renaming teams to narrow their perceived scope and thoughtfully redistributing responsibilities — like the example of moving scheduled jobs ownership to more appropriate teams while retaining infrastructure oversight
What do GenZ software engineers really think?
Young software engineers discuss values, what frustrates them about working in tech, and what they really think of older colleagues.
🔍 Key Demographics & Context
Survey focused on GenZ engineers (born 1997-2012), mostly aged 24-27
Majority have CS degrees (80%) and are based in US/Europe
GenZ was 4x more active in responding vs. other generations
Most are in entry-level positions, with some seniors/managers
💡 GenZ's Self-Perception & Values
More informal and open in communication
Feel underestimated and capable of more responsibility
Value work-life balance and flexibility strongly
Prefer modern tech stacks and are quick to adopt new technologies
Work is not their core identity — maintain clear boundaries
🏢 Workplace Preferences
Appreciate flat hierarchies and transparent cultures
Value good documentation and developer experience
Want meaningful work with clear purpose
Expect good onboarding and mentorship opportunities
Care about career progression and growth opportunities
⚠️ Main Frustrations
Lack of career progression opportunities
Poor onboarding and documentation
Process extremes (either too much or too little)
Can accurately identify when businesses are struggling
Insufficient learning and development support
👥 Views on Older Colleagues
Notice a “bimodal split” — either too invested in work or completely detached
Find older colleagues surprisingly knowledgeable in unexpected areas
Observe weaker written communication skills in older generations
Note resistance to AI adoption and new technologies
Appreciate their experience and calm during crises
🤝 Generation Dynamics
Better rapport with younger Millennials vs. GenX
10-year age gap seems manageable
Communication style differences are notable
Value supportive managers regardless of age
Notice generational differences in work approach and values
The survey reveals that while generational labels can be useful reference points, individual attitudes and workplace culture matter more than age in determining successful professional relationships.
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 👋