Unlocking Productivity; Data-Driven Engineering; Tech-Debt Economics; Resource Allocation; Tech Leadership Pillars
Issue #37 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
📺 Unlocking Engineering Productivity ft. Ariel, Head Product & Tech @Tinybird & Cesar, VPE @StackGen
In the latest "Unlocking Engineering Productivity" webinar powered by Typo, engineering leaders Cesar Rodriguez, VPE at StackGen, and Ariel Pérez, Head of Product & Technology at Tinybird shared valuable insights on building high-performing teams. Key takeaways included fostering curiosity, leveraging AI, and implementing effective metrics to drive team performance. Check out this quick highlight and link to the full session👇
What are your tricks to drive engineering productivity? Share your learnings in the comments! 💬
Article of the Week ⭐
“Qualitative metrics should assist and enrich the manager’s understanding of performance in conjunction with expert analysis and other data sources like qualitative feedback. It should not replace or supersede the manager’s judgement.”
📊 How to Use Engineering Metrics
With a new wave of KPIs coming in to confuse everyone with acronyms like DORA, SPACE, DevEx, TT, and Flow. Here’s a practical approach to engineering metrics from Luca (& Nicola):
🎯 Goal of metrics — Set clear expectations to avoid chasing your tail.
🚦 Types of metrics — The most important part, we prepared a summary below
🏁 How to get started — Put it into practice gently with your team
👑 Advice from the best — Luca connected with CEOs and Founders of software engineering and intelligence tools 👋
It’s genuinely hard to point at many things that all software teams do, which in turn makes it hard to build products to improve them.
That said, I believe we are at a tipping point now, where there is finally more consolidation, many workflows have been figured out, and we have a better idea of what an elite engineering team looks like.
Like all models, metrics are imperfect. They only capture a part of the real thing, Luca emphasizes, “They gives you clues, but never the whole picture.“ Many managers get frustrated by this as the temptation to silo the department and measure it with local KPIs is a lucrative illusion for anyone seeking certainty in the business.
Luca helps us clue together the various metrics frameworks by focusing on what he calls the WIP model, that stands for:
❤️ Wellbeing—How the team is doing
⚖️ Investment—What the team is doing
📈 Productivity—How the team is doing it
The full article has more detail on this, but here’s the general overview:
Things moving too slow → Lead time or Cycle time
Struggling with how to allocate your time → Investment balance
Slow/unreliable release process → DORA metrics
Building the wrong things → Feature adoption metrics
It’s a lot of work and the amount of potential data is enormous. Do not take it lightly.
Here’s what Luca (and Nicola) recommend as a starting point:
Start with ❤️ wellbeing conversations
Pick one metric and figure out how to measure
Rotate stick with the metric or pick a new one after a while
The conversations with engineering intelligence founders covers a few common topics: connect measurements with business outcomes, combine measurements, and look for trends rather than targets.
Other highlights 👇
Demystifying Technical Debt: A Strategic and Economic Perspective
Emmanuel reminds us of the original definition of technical debt, before its meaning was diffused and mixed with other concerns that impact legacy code and productivity.
Over the years there were several attempts to clarify and enunciate the term by writers and technologists Feathers, Cunningham, Fowler, Beck et al.
What they all share with common understanding is capturing a measure of investment necessary into existing code (opposed to new features, changes). It can be thought of as both budget and debt, depending on the strategic context.
Emmanuel leans onto M. Fowler’s Technical Debt Quadrant to differentiate accruing Technical Debt caused by negligence or recklessness or as a strategic advantage and awareness.
Causes of Technical Debt
Several factors contribute to the accumulation of technical debt:
Business Pressures: The urgency to release features promptly can lead to compromised code quality.
Lack of Process or Understanding: Without a clear development process or awareness of technical debt, teams may make uninformed decisions.
Tightly Coupled Components: When system components are overly dependent on each other, flexibility diminishes, making future changes more challenging.
Lack of a Test Suite: Absence of comprehensive testing can result in quick fixes that aren't thoroughly vetted, increasing the risk of future issues.
Lack of Software Documentation: Neglecting documentation can make future maintenance and onboarding more difficult.
Mastering Resource Allocation for Engineering Success
In theory, everyone knows that resource allocation acts as the anchor for project success — be it engineering or any business function. Investing in employee development through training programs, workshops, and certifications can enhance their skills and improve their efficiency. Dive into this article by Typo to learn some practical tips on managing tech resources & leading successfully.
The Three Faces of Technical Leadership: Which One Are You?
Matt Watson brings us the three distinct faces of technical leadership: The strategic CTO, The operational manager, and the technical architect. Does that ring a bell?Understanding your own bias may be helpful for scaling your organization effectively.
The strategic CTO
This is your typical board member CTO. Translating tech-speak to execs while maintaining a firm grip on keeping business and engineering aligned in the same general direction. ROI, investments and opportunity costs are top of agenda for strategic CTOs.
A strategic leader must see beyond the code to understand market dynamics, customer needs, and competitive advantages.
The operational manager
The operational manager builds teams and process. This is as close as you get to a coach, agile coach or delivery manager while also remaining fairly technical. This breed of leaders focuses on aligning personal growth, removing blockers and team cohesion to the overarching goals of the business and the success of the team’s work.
The technical architect
The architect has “I want to stick with devs” written all over it. Problem-solvers, technical founders and engineering-savvy leaders fit into this category. Be wary of centralising “the brain” into only one person. By hogging all the fun complex problems, you deprive your teams of challenges and opportunities to learn, creating a codependent and subservient culture with you as the main bottleneck.
Your role isn’t to be a hero.
Your role is to be aware (and self-aware) of these three pillars being present in your organisation and working those areas that are underserved.
Find Yourself 🌻
That’s it for Today!
Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week(end), Ciao 👋
Credits 🙏
Curators - Diligently curated by our community members Denis & Kovid
Featured Authors -
, , Matt WatsonSponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.
2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.