Acquired Tech Teams; AI Assisted Coding; Cost of No Non-Technical Leadership; Actionable Roadmaps
Issue #33 Bytes
🌱 Dive into Learning-Rich Sundays with groCTO ⤵️
🎙️Integrating Acquired Tech Teams | David Archer, Director of Engineering @ Imagine Learning
Check out Ep57 of the groCTO Originals Podcast, where we uncover leadership strategies to bring teams together with David Archer, Director of Software Engineering at Imagine Learning & ex-Amazon. Discover how he tackled high attrition, built trust, and created a no-blame culture to unite teams.
How do you bring new teams together? Share your thoughts! 💬
Article of the Week ⭐
“AI isn't making our software dramatically better because software quality was (perhaps) never primarily limited by coding speed. The hard parts […] still require human judgment.” —Addy Osmani
The 70% problem: Hard Truths About AI-Assisted Coding
Developers use AI two ways
Addy Osmani explores two common patterns of AI coding assistance. In one camp you find the bootstrappers, focusing on quick-starting ideation from a blank canvas, board or file. And then there’s the iterators, micro-optimisations in the form of autocomplete, quick text generation, suggestions or quick tweaks of repetitive tasks.
But don’t be fooled, regardless of the camp and vaguely optimistic self-reported claims of productivity, most AI users still experience frequent slowdowns and distractions:
AI output can be messy, requiring the human to clean up
Adding edge cases, or perhaps too tedious to prompt for
Getting the right context for type definitions and intent of public APIs and interfaces
Leveraging the human’s experience with regards to appropriate architecture
Error handling
Skip these cleanups and you get a junior human talking to a junior AI. Don’t fall into the trap of this treadmill.
Knowledge Paradox
This means using AI to skip doing menial tasks requires a lot of experience doing said menial tasks. Hm… so anyone inexperienced will have the AI do these tasks badly without knowing they have to double-check. So now the senior people have to double-check AI-assisted code written by juniors even more thoroughly.
What’s worse than using code hallucinated into existence by an AI? Using code written by a naïve developer who had no reservations accepting these hallucinations at a very rapid pace. Velocity through the roof! 🙈
Debugging hell ensues. It’s common to take a an AI model’s code as a quick starting point due to the sheer confidence and speed it was produced with, optimistically continuing down this path and fixing any small issues that come up.
The problem? Unlike a human, the AI models have no intuition for going through all issues. You always run the risk of an endless stream of new small issues popping up, benign prompts creating issues out of seemingly nowhere.
What Actually Works
Addy has observed these patterns time and again. That is why he compiled a list of practical methodologies to reign in the risk. You can read the details through the button bellow. Here are the highlights:
AI First Draft. Use AI to generate a skeleton or template, take over control quickly and early, ironing out the necessary quality aspects.
The Constant conversation. Rather than purely coding, use the AI as a rubber duck. Maintain context and explore ideas through tight feedback loops, giving the illusion of support and having a buddy along.
Trust but verify. Start with an audit tool or testing automation and have the AI generate code into a sandbox that you can quickly verify for outliers, security issues or behavioral acceptance. You could also ask the AI (or another model) to verify the output—but remember the paradox, don’t get stuck!
Arguably, the code generation is the least effective leverage point for AI. Multi-modal agents like cline and Claude may win over coder’s hearts by taking over part of their manual labor, be it from launching tools, making visual verifications on UI output or connecting ideas between code, architecture diagrams and planning software.
Other highlights 👇
The Hidden Cost of Not Having Technical Leadership
Matt Watson flying by with another case study in an organization that didn’t take its technical leadership seriously enough:
“I don’t need a CTO (*yet)”
“Agency can take care of my tech until we’re big enough.”
“Can optimise costs by renting devs from LCOL countries. What could go wrong?”
The result? A year spent building something that didn't work.
Every business that relies on technology for their core offering needs:
Clear development processes
Transparent project management
Efficient team communication
Technical oversight
Product thinking
Beyond just agile project management, many of these practices align with extreme programming values and principles: by engineers, for engineers. This is doubly important when it comes to picking the right level of architecture and quality investments early on.
Here are some warning signs to look out for from Matt’s story: No product feedback, Slow or no adjustment in product direction, no way to ascertain technical quality, early strategic decisions made with limited technical understanding, gatekeepers and SPOCs with business partners, rigid communication, lack of ownership.
Looking for a no-BS Engineering leadership community?
Join Sergio Visinoni’s community, exclusively crafted for passionate engineering leaders like you to get peer support, expert guidance, and insightful resources to tackle your toughest challenges & level up as CTO.
Make it to the early members list for a 30% discount and a free 1-1 mentoring session.
An Example of an Actionable Roadmap
Mike from Planned Attention highlights a brilliant example of a roadmap. Mike Veerman is an expert in software delivery. He shares with us his battle-tested insights on what makes a great roadmap.
Roadmaps should be…
Timelined. There’s nothing worse than communicating with stakeholders in points, pizzas and gummy bears. Short-term decisions sorted for the right order of priorities, long-term decisions should carry key milestones or due dates.
Outcome-based. Get the UML diagrams and technical comments out of the way. The roadmap is the last line of defence to maintain a semblance of bureaucracy to connect engineering with product strategy. Outcomes should capture actual deliveries not just deliverables, giving the tech side opportunity to scope-last and work within the timeframe.
Unified. Keep your entire org in one chart. Separate roadmaps only produce more meetings and split-brain effects on who’s roadmap is more up to date or better.
Centralized. Transparency is key. It’s not enough to discuss the roadmap as a form of “you-know-who” metaphor. Everyone needs access to the actual document. Why waste their time translating?
Hierarchical. The drilling down to actual work items and team tickets should be possible from the roadmap itself. Keep interpretation for dance and music. Roadmaps need clarity and detail-on-demand.
Focused. Don’t sequence individuals’ work items to reverse-engineer deliverables for a roadmap. When zooming out to the roadmap level, it should be clear what one thing each team is working on and moving forward.
Operational. All the activities that belong to software teams should be on the roadmap. Support, KTLO, training, operations. Don’t be the kind of leader that crams a roadmap full of new features with no end in sight.
Versioned. It’s 2024, we have the tools to version control (and check what changed!) in newer revisions of the roadmap. The roadmap should constantly be changing to adapt to reality and just life happening as the priorities shift.
There’s an example document in the original article, check below 👇
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 Watson,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.