Fostering Productive Dev Culture, Intro to SLA, SLO, and SLI
Newsletter - Issue #10
🙏 We’re at Issue Number TEN already. Huge thank you to all of our supporters, your feedback and trust help us bring better weekly content to you.
Let’s dive into the best handpicked stories, starting with ⤵️
CTO Diaries #3 - Fostering Productive Dev Culture
This week on CTO Diaries, we're thrilled to welcome Gaurav Batra, CTO at Semaai! Gaurav boasts a stellar track record leading product and dev teams at top Asian startups. He's a technical whiz with hands-on expertise, having overhauled systems for high throughput and been an early adopter of Kubernetes across multiple companies (Semaai, Reo.dev, Growthschool, Convin, Limetray, and more). But his talents go beyond the code – Gaurav also brings a keen business mind to the table, fueling growth wherever he goes.
Our talk dives into the concept of developer productivity, which is essentially how efficiently and effectively software developers can contribute to a company's goals. It goes beyond just writing code quickly and explores various aspects like code quality, collaboration, innovation, and even work-life balance.
We'll explore the factors that can hinder developer productivity, such as inefficient tools, poor workflows, and lack of collaboration. But fear not! We'll also delve into the solutions we implemented to overcome these challenges, including investing in better tools, adopting agile methodologies, fostering a culture of learning & more.
Loving our content? Must share it with your fellow tech readers ❤️
Article of the Week ⭐
“I could be bad enough as an engineer to make sure that projects failed, but I couldn't be good enough as an engineer to make sure that projects succeeded.”
—Kent Beck
🏎 Increasing Team Velocity While Improving Quality
interviewed recently on the social nature of software and how velocity and quality do not need to be opposing forces. Kent Beck is one of the original signers of the Agile Manifesto and has contributed to the emergence of the Extreme Programming implementation of agile. Many know it simply as XP.No doubt you know it most by its core principles: Iterations, Test-driven Development and Pair Programming. But his goal was not coming up with another framework. Instead he focused on establishing that the mysterious common thread between these principles and disciplines is to help geeks feels safe in the world of software.
Extreme Programming is a social style of software development built on the foundational principle that the more people interact and the more diverse those interactions are the more successful the projects go.
Katerina asked a curious question—now after multiple decades after XP’s first glance at the software world, how would Kent convince traditional organisations to adopt Extreme Programming.
His answer was surprising. Drawing on inspiration from the technique Appreciative Inquiry. In the context of XP it would go along these steps:
Focus on positives and spread them around
Ask executives about their best development experience
Usually it’s something along the lines of…
… high pressure and imminent project failure
… put everyone in one room
… sitting next to the user
… and deploy working software every hour
I know what you are thinking. This can fail very easily. So what makes it work so well in XP companies, hackatons, C3, Sabre Airline Solutions (link: case study)? Extreme Programming is criticised for being very interconnected: the organization has to go all-in on the methods, at least in the scope of a few teams (cca. 25 people). The foundation of XP is a set of core values: communication, feedback, courage and respect.
Kent explains that in his experience many companies that value the opposite of all of those factors.
Are you curious about implementing pair programming or unsure how to integrate test-driven development into your workflow? groCTO connect connects you with seasoned tech leaders who can share their XP expertise and help you lead such initiatives with confidence.
Advance your tech leadership career with 1:1 mentorship from top CTOs, VPEs & other leaders.
The ideal partnership for adoption
an executive who wants the benefits of XP
engineers who want the experience of XP
Get these in sync and it’s a recipe for success. But you cannot bubble it up or down from either side. It needs to be a voluntary partnership. Sorry folks, no silver bullet transformations.
What stands out from the conversation is the release-focused and customer-focused nature of planning the week.
On Monday, you want to sit down together and see what's the most important thing for us to work on this week?
On Friday, you want to be able to lean back and go, “okay, here's what we did.”
Here are the the interruptions that came in, here's how we handled those.
How'd we prioritize this? How'd that go? What were the friction points?For the interruptions that we got, are there, are there bigger lessons that should shift our priorities in the future?
But every week you should have this feeling of “what am I doing with my family, with my hobbies?”
And then about Sunday, maybe about two o'clock, you're like, hey, I get to go to work, you know, and the juices start flowing.[…]
Pair programming—Worth it?
Kent outlines how his most recent team work.
🗓 Blocked out “team time” 2 hours at the beginning and end of each day
👥 After a short check-in the team time groups split off into pairs or solo to work
🥛 Keep everyone’s guaranteed commitments to about 50% of their capacity
But does all this require Pair Programming—is it a key ingredient? Surprisingly Kent said No.
You can skip on Pair Programming. What a team should not skip is 2-3 hours of conversation every day. It just so happens that after an hour or so it’s much easier to keep everyone stimulated if there’s coding being done during the conversations.
Other highlights 👇
I am not a fan of heroism in the engineering industry
Certainty and the feeling of significance are core drivers of human behaviour. But put it to the extreme and it will devolve into a culture of burnout and heroics. In his essay
explores his experience with managing teams that one way or another ended up doing heroics—and worse, optimising for them.Gregor critiques the "heroism" mindset in engineering, where individuals push themselves to solve problems quickly or work excessively to meet deadlines. This approach is unsustainable leads to burnout time and again. Instead, the focus should be on long-term success through consistent, reliable, and predictable work.
After many failures, I learned that it's not the end of the world if something takes more time than it's actually estimated. As long as there are valid reasons for it and the overall project is still on track.
Some tasks may take longer, some tasks may take less time than estimated. You get better at it, but you'll never be perfect.
What’s wrong with heroism?
Heroism can lead to burnout
Doing good work long-term is a HUGE competitive advantage
Managers value long-term good work instead of short spikes of great work
Gregor reached out to engineering managers in the industry and shared their thoughts, comments and quotes at the end of his article. Go check it out! 👇
Laugh it Off 🤡
Eh. It's all good.
Now if you happened to be typing something like git push -d origin develop in the chat, then you may be asked to return your company equipment :P
P.S. Sounds like a normal Monday? Share your first experiences as a software engineer in the comment section and let's keep the laughs going!
Intro to SLA, SLO, and SLI
emphasises the importance of service reliability, particularly highlighted by Stripe's achievement of 99.999% uptime during peak transaction periods.Is Stripe’s success part of their DNA or can others benefit from their example? Let’s find out!
Site Reliability Engineering (SRE) is a specialized field focused on ensuring system reliability through three key metric groups:
Service Level Indicators—atomic metrics for a system’s services; e.g. latency
Service Level Objectives—indicator targets and time windows; e.g. 25ms p99
Service Level Agreements—the external contract for objectives, notably consequences for not meeting them
In his article he explains these concepts and the importance of setting realistic reliability targets to balance the high costs of achieving near-perfect uptime, especially combined with CloudOps expenses from the big three vendors.
His secret sauce centres on three pillars:
Reliability Definition: Start with your existing system and set key indicators
Error Budget: the allowance for system failures, e.g. amount of downtime minutes or seconds in a year for a 99.9999% system.
SRE Practices: Monitoring, Observability, setting SLIs and SLOs, and involving the entire organisation in reliability goals (especially the non-technical crew)
The overarching message is to start small, prioritise customer-impacting services, and involve the whole organisation in the reliability journey.
That’s for Today!
Whether you're hustling with your side projects, catching up with the latest technologies, or simply relaxing & recharging, wish you all a lovely day ahead.
See you next week, Ciao 👋
Credits 🙏
Curators- Diligently curated by our community members Denis & Kovid
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.