Hybrid LLMs; Independent Service Heuristics; Scalability Cheat Sheet; Founder Mode
Issue #21 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
🎙️Engineering Director from Oracle, Venkat on How AI is Revolutionizing Software Engineering
In our latest episode of the groCTO podcast, we discuss how AI is reshaping the engineering landscape. Venkat shares his journey from a humble background to leading at Oracle, diving into his passion for mentorship and the revolutionary impact of AI on the Software Development Life Cycle (SDLC).
Article of the Week ⭐
ISH is an intermediate approach that can help to introduce the principles of Domain-Driven Design without some of the abstract terminology that can often be a barrier to the adoption of it.
Finding good stream boundaries with Independent Service Heuristics
Domain Driven Design (DDD) is a tricky nut to crack. Independent Service Heuristics are one of the answers to making DDD practical for most any organization. (the other options being Event Modeling and Value-stream mapping)
Independent Service Heuristics (ISH) is a technique invented by the authors of Team Topologies, Matthew Skelton and Manuel Pais. Not to be confused with the DDD Crew who have a similar value-stream mapping concept.
On one hand DDD is one of the only formal methodologies that has managed to captivate our industry for two decades, bringing together engineers with product designers, analysts and sales people.
At the same time it is quite a broad concept, ranging from team building, value stream mampping, organization design, language, architecture, all the way to coding concepts and patterns.
Like microservices, it’s hard to pinpoint just exactly what “it” is that makes it complete. Looking at company job posts you may find mention of DDD knowledge being appreciated, but will struggle to find evidence of DDD being applied in those same companies!
Why Stream Boundaries Matter
First of all, the Team Topologies team refers to Streams in the context of streams of change. Think of it as the various pieces of your roadmap that move in parallel. These are fundamentally what your teams are formed around or—at least—shaping towards.
Defining these boundaries well can reduce team interdependencies, allowing teams to focus on their areas without being blocked by others. For VPEs and CTOs, this is critical in improving delivery speed and organizational agility.
Independent Service Heuristics is a rapid results approach that will give you clues on where your boundaries and challenges are. But enough of that, let’s get into it!
High-level Checklist
🔗 P.S.: In case you are from the future, you can find a more-up-to date version of this checklist on the Independent Service Heuristics Github repo.
Sense-check: Could it make any logical sense to offer this thing "as a service"?
Brand: Could you imagine this thing branded as a public cloud service (like AvocadoOnline.com 🥑)?
Revenue/Customers: Could this thing be managed as a viable cloud service in terms of revenue and customers?
Cost tracking: Could the organisation currently track costs and investment in this thing separately from similar things?
Data: Is it possible to clearly define the input data (from other sources) that this thing’s needs?
User Persona: Could this thing have a small/well-defined set of user types or customers (user personas)?
Teams: Could a team or set of teams effectively build and operate a service based on this thing?
Dependencies: Would this team be able to act independently of other teams for the majority of the time to achieve their objectives?
Impact/value: Would the scope of this thing provide a team with an impactful and engaging challenge?
Product Decisions: Would the team working on this thing be able to "own" their own product roadmap and the product direction?
Other highlights 👇
Scalability Cheat Sheet #1 - From Basics to Replication
Mirco at Verbosemode has provided a spectacular cheat sheet for Scalability concepts.
Part #1 is a high-level overview of 🚀 Scalability Terminology, ✅ Pros and ❌ Cons
🏗️ Vertical vs. Horizontal Scaling
👑 Leader-Based Replication
🤷♂️ Leaderless Replication
🔄 Replication Methods
Executive Summary
🏗️ Vertical Scaling: Simple and effective, but costs rise disproportionately with gains
🌐 Horizontal Scaling: Add hosts to distribute load. Cheapest option, but complex.
👑 Single-Leader Replication: Writes handled by one node, many read nodes.
🤝 Multi-Leader Replication: Great geo distribution, but complex conflict resolution
🤷♂️ Leaderless Replication: “Ask-around-style” verification to maintain sense-of-truth
Founder Mode
If you’ve spent any time this week on social media you’ve no doubt found the buzz surrounding Founder Mode. An essay by Paul Graham detailing a talk given by Airbnb CEO Brian Chesky got the attention of popular tech giants like All-in Podcast, The Pragmatic Engineer and hackernews.
Founder Mode is a bit murky in a wider sense of meaning, but it tries to capture the sense of Founder-managed behavior in contrast to typical MBA-style management where Founders get replaced as CXOs once companies go public or reach certain stage of maturity.
Founder Mode: Very involved, tactical, to the extreme of over-managing. Stressful, but situational awareness is maintained, feedback is extremely quick.
Manager Mode: Scaling a startup, org is modularised and delegation telephone ensues, centering on a spine of managers. Scalable in theory, but errors happen in communication and context is lost, producing less than ideal outcomes, hampering learning (and skill).
The burning pain that sparked the discussion is the idea that Founders, especially in the tech industry, are given plain, well-intentioned management advice that doesn’t seem to live up to its efficacy or potential in most situations.
💬 Is your org’s C-suite in Founder Mode or Manager Mode?-Tell us in the comments.
Laugh it off 😄😄
Want more? Check out Work Chronicles & thank us later :)
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
Writers of the week - Team Topologies Team, Mirco, Paul Graham
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.
Hey, thanks for mentioning me!