As an engineering leader, you face constant pressure to step away from the keyboard. Meetings multiply. Strategic planning demands attention. Stakeholder management becomes a full-time job. Before you know it, code becomes something “other people do.”
This is a mistake.
When you stop coding, several things happen:
You lose credibility. Engineers can smell a manager who’s lost touch. Your architectural decisions become theoretical rather than practical. Your technology choices lack the nuance that comes from implementation experience.
You miss the details. The friction points in your systems—the ones that slow down your team daily—become invisible. You can’t feel the pain of poorly designed APIs or awkward development workflows.
You disconnect from reality. Your estimates become wishful thinking. Your technical roadmap drifts from what’s actually feasible. The gap between vision and execution widens.
I’m not suggesting CTOs should be on the critical path for features. That’s a different failure mode. Instead, writing code as a CTO means:
My rule: I ship code at least once a week. Not heroic features. Not critical path work. But real code that runs in production.
As a technical leader, you have a superpower: the ability to validate ideas quickly without the pressure of production quality. Use it.
When we considered moving to a new AI pipeline architecture, I didn’t write a spec document and delegate. I spent three days building a proof of concept. The learnings from that week informed months of team work and saved us from several dead ends.
PoCs are where CTOs should code most. They’re high-leverage, low-risk, and give you the credibility to make informed technical bets.
Yes, your primary job is leadership. But leadership in engineering requires technical credibility, and credibility requires practice. The goal isn’t to be the best coder on your team—it’s to maintain enough context to make good decisions and command respect.
Write enough code to stay dangerous. Ship enough to stay humble. Build enough to stay credible.
Here’s how I make this work:
The strongest technical leaders I know haven’t stopped coding. They’ve just changed what they code and why.
What’s your take? I’m @yaroslav_nasonov on Telegram.
]]>I’ve watched teams spend months building “AI infrastructure” before shipping a single AI feature. Vector databases, embedding pipelines, fine-tuning frameworks, evaluation harnesses—all before validating that users want what they’re building.
This is backwards.
Here’s what a minimal AI pipeline actually needs:
import openai
def process_user_query(query: str) -> str:
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[{"role": "user", "content": query}]
)
return response.choices[0].message.content
That’s it. Ship that. Learn from it. Then iterate.
At this stage, your “AI pipeline” is a function. That’s fine. Most products should stay here longer than they do.
Once you’ve proven the concept, add:
class PromptTemplate:
def __init__(self, template: str, version: str):
self.template = template
self.version = version
def render(self, **kwargs) -> str:
return self.template.format(**kwargs)
# prompts/analyze_code.txt (v1.2)
ANALYZE_CODE = PromptTemplate(
template="""
Analyze this code for issues:
{code}
Focus on: {focus_areas}
""",
version="1.2"
)
Only when you have real usage and real problems:
Notice what’s missing: vector databases, fine-tuning, custom models. You probably don’t need them.
Add infrastructure only when you feel specific pain:
Vector databases → When search quality matters and you have >10k documents
Fine-tuning → When prompting fails after serious iteration and you have quality training data
Self-hosting → When API costs exceed $10k/month or you have strict data requirements
Custom models → Probably never for your use case
RAG (Retrieval-Augmented Generation) has become the default “solution” for any AI product. Most implementations are overengineered.
Simple RAG that works:
def answer_question(question: str, docs: list[str]) -> str:
# Find relevant docs (simple embedding similarity)
relevant = find_top_k_docs(question, docs, k=3)
# Stuff them in the prompt
context = "\n\n".join(relevant)
prompt = f"Context:\n{context}\n\nQuestion: {question}\nAnswer:"
return call_llm(prompt)
Do you need a vector database? Only if docs is so large that in-memory search is slow. For most applications, that’s >100k documents.
Do you need sophisticated retrieval? Only if simple similarity search fails. Try it first.
Skip the MLOps complexity. Track:
These four metrics tell you everything. Fancy evaluation frameworks can come later.
Every AI feature should start as a proof of concept:
Ship this to 5 users. Get feedback. Only then architect a “real” solution.
We’ve launched three AI features this way. Two are still running essentially as PoCs (with better error handling). One evolved into a proper service after we saw 10x usage growth. The architecture emerged from need, not anticipation.
Mistake 1: Building an “AI platform” before building AI features
Fix: Build one feature. Extract common patterns. Then build infrastructure.
Mistake 2: Optimizing for problems you don’t have yet
Fix: Start with the slowest, dumbest solution that works.
Mistake 3: Treating LLMs like traditional ML
Fix: LLMs are more like databases than models. Query them, don’t train them (yet).
This isn’t anti-engineering. It’s pro-engineering. Good engineering means:
The best AI pipeline is the one that ships features users love. Start simple. Stay simple as long as you can. Add complexity only when simplicity breaks.
Most teams never reach that point. And that’s fine.
Building AI products? I’m interested in your architecture decisions. Reach out: @yaroslav_nasonov
]]>In the beginning, chaos is appropriate. You’re searching for product-market fit. Everything is an experiment. Process would be premature optimization.
Signs you’re in healthy chaos:
This is the golden age of startups. Savor it. But recognize it doesn’t scale.
Chaos breaks predictably. The symptoms:
Repeated work. Teams building the same thing in parallel because there’s no visibility.
Tribal knowledge. Only 1-2 people understand critical systems. They become bottlenecks.
Unclear priorities. Everyone is busy, but no one knows what matters most.
Quality decay. Technical debt compounds. Incidents increase. Velocity drops.
Frustrated engineers. The best people leave because “nothing works here.”
If you’re seeing 3+ of these, you need process. But be careful—most teams add the wrong process.
Bad process cargo-cults big company practices:
This is process theater. It feels productive but adds friction without adding clarity.
Good process has three properties:
Start with these fundamentals:
Every project, system, and decision needs an owner. Not a committee. One person who’s accountable.
Use a simple RACI-like model:
Most paralysis comes from unclear ownership. Fix this first.
Replace meetings with documents. Before starting anything:
This is the minimum viable spec. Takes 15 minutes to write. Saves hours of confusion.
We use Confluence. Notion works. Google Docs works. The tool doesn’t matter. The habit does.
Everyone should be able to answer: “What are the top 3 priorities right now?”
Keep a single source of truth. We use Jira with a simple rule:
The magic is in the constraints. Only 3 P1 items forces real prioritization.
Every 2 weeks, ask:
Pick one change. Try it for two weeks. Repeat.
This is how process evolves. Small adjustments compound.
One of the best lightweight processes we adopted: Architecture Decision Records (ADRs).
For any significant technical decision, write a markdown file:
# ADR-012: Switch to PostgreSQL for Primary Database
## Context
Current MongoDB setup causing scaling issues...
## Decision
Migrate to PostgreSQL...
## Consequences
Positive:
- Better query capabilities
- Stronger consistency guarantees
Negative:
- Migration effort ~3 weeks
- Team needs PostgreSQL training
## Status
Accepted (2025-02-01)
Store these in the repo. They become living documentation of why things are the way they are.
Process isn’t just about tracking work—it’s about communication rhythm.
Daily: Quick async updates (we use Slack threads)
Weekly: Sync alignment (30 min meeting)
Monthly: Strategic review (1 hour)
Quarterly: Planning (half day)
Notice: Only one daily meeting. Everything else is async or low-frequency.
How do you know if your process is working?
Track these:
Lead time: Time from “we should do this” to “it’s in production”
Decision velocity: Time from question to answer
Context sharing: Can new engineers understand why things exist?
Team satisfaction: Do engineers feel productive?
These matter more than velocity or story points.
Moving from chaos to process is tricky. Too fast and you kill momentum. Too slow and you burn out.
Our approach:
Month 1: Add ownership and visibility
Month 2: Add documentation
Month 3: Refine and optimize
Go slow. Add one piece at a time. Get buy-in. Don’t force it.
The most important process is the process for changing process.
Make it explicit:
This creates a culture of experimentation rather than cargo-culting.
Resist adding these until you feel real pain:
You might never need them. We haven’t.
Good process is invisible. Engineers should feel like:
That’s it. If process feels heavy, you’ve added too much. If things feel chaotic, you’ve added too little.
The goal isn’t process for its own sake. It’s clarity that enables velocity. Structure that enables autonomy. Process that gets out of the way.
Leading engineering teams through this transition? I’d love to hear about your approach: @yaroslav_nasonov
]]>