Dev Effectiveness; EM Feedback Guide; Your Last Mile; Breaking Walls
Issue #27 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
📕CTO Diaries Throwback| Measuring Dev Effectiveness with ex-Superhuman CTO
Let's dive deep into Chris Bee’s framework and approach to evaluating effective dev teams. Chris is a great tech leader & an ex-CTO at multiple startups like Superhuman & Lessen. Let's hear from him about how to benchmark and lead dev teams with fair evaluation in this edition ⬇
What strategies have worked for you? -Let us know!
Article of the Week ⭐
“If you only take away one thing from this article, it should be the concept of Strength-Based Feedback. Unlike traditional approaches that attempt to "fix" weaknesses, strength-based feedback acknowledges that, realistically, weaknesses can only be managed, not fixed.”
Engineering Managers' Guide to Effective Annual Feedback
Péter Szász has created a wonderful checklist to help you and your engineering managers ease the frustrations and bureaucracy dealing with annual reviews.
Annual feedback cycles are more than just a formality—they allow for meaningful recognition of individual contributions. Recognize achievements and areas for growth to boosts morale and strengthen your team’s self-awareness.
Get familiar with company requirements: the timeline, format
Calibrate your feedback to the individual’s level and expectations
Focus on actionable links to achievement or representation with expectations
Schedule time for any extra feedback or research
Split the workload to write the document, it can be very draining
Prepare for the call
Align Performance with Company Goals
Strategic interests of the business are a key accelerator to backing and support. Performance goals are best set to find a sweet spot of overlaps between the individual’s ambitions and interests with the broader objective’s of the business.
Iron out disagreements and misalignments early to save yourself plenty of headache and broken promises (both ways).
Structure The Document
A well-documented feedback process creates a detailed record that can be referenced for decisions on promotions, role assignments, or even performance improvement plans. This formal documentation also provides legal protection and continuity in case of management changes.
By keeping track of an individual’s achievements and areas for improvement, managers can offer clearer direction and support over time.
Péter recommends keeping a separate, personal context of all feedback and the actual written one for brevity to help maintain situational awareness in case of further review while also keeping the 1 on 1 focused on actionable items.
Strength-based feedback
Be concise, don’t waste anyone's time
Be specific and provide examples
Avoid recency bias, focus on the whole year not just the last few months
Don’t extrapolate from a big event (successful release or failure, promotion or performance problems, etc.), make sure you cover the whole year equally
Avoid taking good performance for granted
Don't overlook long-lasting questionable behavior
Be compassionate.
How to Deliver the feedback?
Here are two approaches that I tried but didn’t work for me:
❌ Sharing the written feedback in advance, then discussing it live
❌ Sharing the written feedback during a live discussionWhat worked for me was
✅ A live high-level discussion and then sending over the written feedback
Balance the live conversation on the key points and present factual, actionable insights in order to discuss and share further. Challenges and ironing out of details, along with the compensation questions can then be safely and calmly be handled in a scheduled follow-up.
This regimented approach and attention to detail will be a great foundation for their growth, be it requiring continued support or being a cornerstone for the promotion package.
Other highlights 👇
You're getting your last mile wrong
The Last Mile in engineering teams is the phenomenon where the continuous iteration style of progress gets thrown out the window and the team starts tunnel visioning into build-it-until-its-doneor the deadline
There is one part you cannot skip no matter how early your product is: shipping your software to production.
The problem with the last mile
Isolation has its merits. The closer you bring a piece of production-like environments to a dev machine the faster they get feedback—and safe, risk-free feedback at that. But if the project is in its infancy and there is little operational design or oversight, then this is a precarious limbo that gets worse over time.
Sergio has a nice checklist for you, reminiscent of the shift-left movement to keep your product engineering efforts in line with your ability to continuous deploy from the get-go. Here’s how.
Make it your first mile
Step 1: Create the required repositories with a Hello World implemented using whatever stack you plan to use, with unit tests.
Step 2: Set up CI to ensure it's triggered with every PR and push to the main branch.
Step 3: Set up at least two environments, one for Test/Staging and one for Production. Production at the beginning is key.
Step 4: Set up CD across the environments following the approach you consider reasonable. Focus on automating deployments from day 0 and making the deployment to Production part of your definition of done.
This keeps each increment actionable and very close to release, opposed to merely feature complete or showing feature progress in isolated demos or testing environments reminiscent of laboratories.
Breaking the wall between teams
Leading Developers hosted Samuel Kollát, Snr. Staff Engineer at Outreach to provide his insights on how to overcome the four most common root causes for silos and how to fix them.
1. No Horizontal Flow of Information
Fix: Establish guilds and Slack channels for cross-team collaboration.
Silo’d organizations suffer from vertical-only information flow. Managers and key leaders have to play telephone with their ICs and other collaborators, creating an inefficient network of codependence.
Samuel recommends setting up guilds that host a horizontal overlap of people as an independent entity that fits into overall business strategy with a broader scoap than a team, but limited to the focus of the guild (ie. Frontend Architecture, Mobile Delivery, etc.)
2. Ineffective Knowledge-Sharing
Fix: Implement Minimum Viable Documentation and standardized templates like ADRs.
Most documentation becomes obsolete quickly. Minimum Viable Documentation and ADRs help capture key context and key decisions respectively. This eliminates needless documentation-updates and rewrites while providing a reasonable cookie-trail for already-explored issues.
Of course these documents need to be close to the source of changes, be it source code, tests or delivery mechanisms like release notes.
3. Sh***y Onboarding
Fix: Use buddy systems, pair programming, and product overviews.
Assigning new hires a buddy is the fastest way to make them productive. It also facilitates knowledge sharing and networking opportunity to the new individual and existing team members alike.
Product overviews unrelated teams is also a unique opportunity to learn more breadth before the new individual commits to first large project.
4. “Us vs. Them” Thinking
Fix: Foster transparency through architecture reviews and in house meet-ups to socialise
Isolation and specialisation are two crutches that hyper-individuated organizations rely upon for cheap productivity gains, but come at the cost of having dysfunctional or no team awareness.
The antidote is an approach for radical transparency, frequently requesting comments, advice and feedback on key decisions to involve isolated team members. This provides them with opportunities to learn, share and build trust.
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 -
, ,Sponsors - 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.