How to Lead Agentic Development Teams, The Best Pair Programming Guide, 13 Questions that Shape Elite CTOs
Issue #82 Bytes
đ± Dive into Learning-Rich Sundays with groCTO —ïž
Article of the Week â
âThe difference is that [old skills] skills now pay compound interest. If you donât have them yet, thatâs the first thing to learn. Not prompt engineering. Not which model is best. Learn how to make sure a team has what it needs to deliver. The agents are ready when you are.â âBryan Finster
Leading an Agentic Development Team
Bryan Finster is a veteran when it comes to DevOps, continuous delivery and elite engineering practices. He was at the forefront of AI-scepticism spearheaded by vibe coding and similar non-engineering practices until the tools became good enough to accelerate the mainstream engineering fields.
Models had improved enough to make him pause. He joined a hackathon, worked in languages heâd never touched, and shipped a working RAG application in a few hours. That was surprising. For him and many of us it changed how we think about AI tools in our pipeline when leading engineering teams.
Leading an agentic team is the same skill set that separates good engineering leaders from bad ones:
making sure the right information reaches the team at the right time
clear mission
defined outcomes
quality processes that catch problems before they grow
The difference now is that those fundamentals pay compound interest: Strong discipline produces dramatic acceleration. Weak discipline produces the same mess you always had, just faster. And the empirical research backs up those findings.
Hereâs his advice for running agentic teams today:
Set the mission. Three to five sentences. What youâre building and why, not how.
AI Plan with the team. Have the agent generate a plan, give it feedback, and agree on the approach.
Define âdoneâ first. Gherkin features. Prune anything that doesnât belong.
Build focused specialists with an orchestrator. Agents from review and architecture to tests, naming, and domain patterns. Coordinated by another agent with context.
Let the team code. Define what the code should do and let them deliver it.
Validate outcomes, not activity. Ship it when it passes the planned tests.
Run your pipeline. Pre-commit checks, all agents, all analysis. Every time.
Other highlights đ
A complete guide to Pair Programming
Most teams think theyâre collaborating. But most forms of collaboration in the industry are various forms of scatter-gather and command and control processes to ease project management. Handing work down a chain (backend to frontend to QA) is an assembly line, not a team.
Pair programming is what the Extreme Programming (XP) community defines as real collaboration for the purpose of software engineering: two people, one goal, no handoffs.
Emmanuel Valverde Ramos has spent years practicing and teaching pair programming. The biggest misconception isnât about the cost of having two employees sitting at one computer, but rather raising the awareness of where cost actually lives.
The time developers spend typing is a rounding error. The real spend is in debugging, rework, waiting for reviews, and context-switching back into code you forgot you wrote. Pair programming attacks all of that directly by turning hand-offs into a continuous form of peer-review, mentoring and refinement in short focus blocks.
His guide covers the full picture:
the four pairing styles (Driver/Navigator, Ping-Pong, Tour Guide, Backseat Navigator) and when to use each
how to manage tempo mismatches between fast and slow thinkers
the Pairing Matrix for rotating knowledge across the whole team
and the anti-patterns that quietly kill sessions (e.g. silent partner,dictator, âŠ)
Still, done properly, pair programming can be exhausting. Our brains fatigue differently than our bodies, and some teams cap pairing hours for exactly that reason.
If you lead a team â or want to â this is the clearest practical breakdown of pair programming available.
13 Provocative Questions CTOs Donât Ask
Most leadership dysfunction that CTO have to solve is self-inflicted, and Yaniv Preiss has thirteen questions designed to make such problems impossible to ignore:
Who benefits from the way we work today? And who always pays the price? A simple, non-judgemental way to challenge and improve processes.
What did we normalize that would have shocked us two years ago? If youâre calling it âthe new reality,â thatâs your answer.
Which value do we drop first when things get tight? Values only exist when they cost something. Everything else is a poster on the wall.
If this problem disappeared overnight, what would I stop doing? If nothing, the problem might be serving you more than you admit.
What part of me is keeping this problem alive? The need for certainty, avoiding conflict, wanting to be needed, hating to be wrong.
What if this resistance is actually competence? Your best engineers may be pushing back because they see risks you donât want to face.
On a scale of 1â10, where are we really? Not the board version. Then ask: what would move us just half a point?
Where does this problem not happen? Somewhere in your org the desired state already exists. Why are you treating it as an exception?
What obstacle inside us will block this change? Not the market or tech debt; inside us, collectively.
If this year were a chapter in a book about your org, what would it be called? Metaphors to bypass politics.
Whatâs the smallest experiment we could run and stop? If nothing would make you stop it, itâs not an experiment. Surface beliefs your org is afraid to test.
Who do we need to be, not just what do we need to do? You may not need more tools or frameworks. You need a clear identity.
If nothing changes, how long until your best people leave, emotionally or literally? If you can see the timeline then itâs already happening.
Why Measuring Engineering Productivity Still Feels Hard
Teams talk about productivity all the time, but most measurements miss the point. Counting tickets closed, lines of code, or velocity doesnât show whether work flowed well, quality improved, or value actually landed. The piece argues that good measurement starts with the questions youâre trying to answer â not the data you happen to have. It lays out meaningful signals like wait times, review load, defect movement and rework patterns, and shows how they connect back to real outcomes engineering leaders care about.
The upshot: better signals make better decisions, not just prettier dashboards. If you want to rethink how you track productivity, this is worth reading.
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, Ciao đ
Credits đ
Curators - Diligently curated by our community members Denis & Varun
Featured Authors - Bryan Finster, Emmanuel Valverde Ramos, Yaniv Preiss
Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.
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.
