Stop saying “technical debt”
Everyone who says, “tech debt” assumes they know what we’re all talking about, but their individual definitions differ quite a bit.
💡 Tech debt is often associated with a feeling of frustration, but different individuals have varying definitions of it.
📉 Equating tech debt only to bad code can be misleading, as it overlooks constraints and other factors contributing to technical debt.
📌 To minimize maintenance load growth, good code stewardship practices such as documenting systems and designing for future changes are essential.
🔄 Negative maintenance load growth can make code more maintainable over time, requiring addressing individual maintenance tasks and source problems.
📈 By focusing on specific elements causing delays in feature development, addressing them as individual tasks, and framing them as investments in future capacity, conversations about tech debt can become less disheartening.
DevEx Principles: Minimize switching contexts
💡 Minimize switching contexts: Interruptions matter, even when it’s your tools that are doing it.
🧠 Remember, you are a chef cooking for chefs: Respect the craft and the high bar for building products for people who build products.
🤖 Automate anything that can be automated: Automation is key for productivity.
🕒 Optimize for TTC (time to code): Developers need to see code running to test, get feedback, and ship efficiently.
🤝 Be dependable: Mind breaking changes and consider the impact on people’s services.
🚀 Don’t bury the lede: Show the possibilities clearly without hiding pricing or using convoluted marketing language.
Three-Bucket Framework for Engineering Metrics
💡 One of the common challenges for engineering leaders is deciding what metrics to track and report to stakeholders
📊 CEO's are interested in metrics that demonstrate accountability for engineering spending
🛠️ Metrics should be categorized into three buckets: Business impact, System performance, and Developer effectiveness
🔍 Reframing the problem can make choosing metrics easier
📉 Avoid using ineffective metrics like lines of code or lead time
🔄 Regularly iterate on your approach to showing intention and effort in reporting metrics.
Why Hierarchies in Organisations Aren’t All Bad
💡 Hierarchical structures can be useful even for teams that need to be agile.
🌐 Multi-layered hierarchies can lead to transmission losses such as control and information.
🌀 Flat organizations may explore too many options, while hierarchical organizations may miss out on the best alternatives.
🤝 Hierarchies can be most useful when making a coordinated decision quickly outweighs finding the absolute best solution.
🌟 Hierarchy and authority figures can create agility even if the boss is not wiser than subordinates.
🔍 Hierarchies persist due to structural benefits even with leaders lacking knowledge or authority.
Getting More from Your Team Health Checks
📊 Regular team health checks play a vital role in upholding and enhancing team performance and dynamics by evaluating various aspects such as teamwork, morale, and efficiency, sparking curiosity in team members to delve deeper into areas of improvement.
🔄 The continuous tracking of team progress through these health checks allows for the early identification and prompt resolution of any issues or areas requiring improvement within the team structure, encouraging follow-up actions for sustained growth.
📉 Prioritizing actionable items and achievable goals during these check-ins can result in measurable enhancements to team health and overall productivity, fostering a culture of continuous improvement and innovation.
💬 Maintaining open and effective communication channels during health checks is imperative for promoting transparency, collaboration, and a positive team culture that values feedback and shared accountability for success, ensuring that concerns and achievements are addressed promptly.
Writing an engineering strategy.
💡 An engineering strategy is important for engineering executives, as it guides how the engineering organization functions and addresses challenges.
✏️ An engineering strategy should include components like diagnosis, guiding policies, and coherent actions.
🔄 Strategies should be applicable, enforced, and create leverage to be effective.
📋 The process for writing an engineering strategy involves commitment, identifying stakeholders, writing diagnosis and guiding policies, and sharing and finalizing the strategy.
🛡️ Guiding policies should cover resource allocation, fundamental rules for teams, and decision-making processes within engineering.
🔄 Coherent actions in the strategy should focus on enforcements, escalations, and transitions to maintain and implement the guiding policies.
🚀 Top-down leadership is necessary for enforcing engineering strategy and ensuring consistency in approach.
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 👋