Matt Lathrop

As Fred Brooks wrote decades ago: “Adding manpower to a late software project makes it later.” Coordination isn’t free. New devs mean onboarding, syncing, and re-aligning. The fastest teams aren’t the biggest, they’re the ones that communicate best.

668

30 Comments

Six months ago, Spotnana engineering committed fully to Claude Code and Cursor. Adoption happened quickly and naturally. What surprised us most was a feature released last July in that many developers still haven't discovered: custom sub-agents. When you use ClaudeCode in its default form, you're working with a capable generalist. Custom sub-agents let you create specialists instead. You define them by placing a markdown file in the .claude/agents/ directory with simple YAML frontmatter that sets the agent's name, persona, and allowed tools. Claude then automatically delegates tasks to the appropriate specialist based on context and no manual prompting required. Each sub-agent runs in its own isolated context window, so your main conversation stays clean. The agents are also shareable across projects, which lets institutional knowledge build over time. The biggest challenge we faced was getting routing reliable. When agent descriptions overlap even slightly, Claude struggles to choose the right one. We've learned to make each persona description extremely precise and distinct. Another lesson came the hard way: sub-agents inherit your permission settings by default. I once gave a research-focused agent write access, and it began refactoring code while trying to investigate a bug. One improvement I would love to see is a clear post-session audit log that shows which agent handled which actions and when. Right now, tracing responsibility requires digging through long transcripts, which slows down debugging and makes accountability harder. If you're already using Claude Code (or Cursor with Claude) and haven't tried the /agents feature yet, you're missing out on significant capability. What sub-agents has your team built, and how have they changed your workflow? #ClaudeCode #AICoding #AgenticAI #CursorAI #DeveloperTools

58

3 Comments

Today I wired a Slack bot into our codebase so the GTM team can ask, “What actually happens when ___?” and get a plain-English answer right in the thread. No IDE, no code links—just a clear explanation. What helped: I set up a small meta-repo that pulls in all our services and made it the our internal #ask-gtm channel. That stopped the “it only saw one repo” problem. I pinned a short question template (“surface, scenario, env, question”) so the bot has just enough context to find the right code. If the bot isn’t confident, it tags the owner instead of guessing. Early takeaway: the win isn’t fancy prompts—it’s putting reliable answers where people already ask and keeping the handoff simple when the bot isn’t sure. Bringing the code’s ground truth to GTM cuts back-and-forth and gets people answers quickly!

37

3 Comments

Surprisingly, EMR pricing is still wildly misunderstood. 🤯💰 And a common belief goes like this: EC2 is the real cost. 💻 EMR is just a thin, cheap management layer on top. 🪶 That’s… not how the math works. ➗❌ If you run 10 × r8g.4xlarge nodes on EMR, here’s what happens: • On-Demand → ~80% of your bill is EC2, ~20% is EMR • Reserved (50% EC2 discount) → EMR becomes ~33% of total • Spot (70% EC2 discount) → EMR becomes ~45% of total Notice the pattern? With on-demand instances, EMR markup looks ~20%. Reasonable. 👍 But once teams move to Spot (which many do), the markup overhead grows close to 50%, with no real extra value. 💸📈 Why? 🤔 Spot can be up to 90% cheaper than on-demand. It drops EC2 line item fast. 📉 But EMR pricing doesn’t. 🚫 On-demand EC2 is the cost base. 🧮 So as you optimize compute with Spot, “managed Spark” quietly becomes the largest tax on your cloud bill. 🧾💵 I spend 10s of hours on calls with teams running large Spark installs. 🔥This is exactly why most customers I talk to want to at least explore running Spark themselves on Kubernetes instead of EMR. 🚢 Not because they love undifferentiated ops work — but because they want control over the economics. ⚙️📊 #spark #aws #cloudcost #kubernetes

270

11 Comments

When I deliver a project, I follow a 48-hour decision rule with my team. Every decision has an owner, options, and a deadline. If it doesn’t change the architecture or budget, it’s decided quickly. Forbes Technology Council recently featured this approach to reducing decision latency.

28

9 Comments

What is agentic delivery? Imagine a world where every software implementation starts aligned— and stays that way. Where discovery isn’t buried in notes, where scope changes don’t break everything, where tribal knowledge isn’t lost between teams. Imagine if: 🧠 Requirements were structured as they were spoken 📄 Artifacts were generated in real-time 🔁 Context followed every decision, across every tool ⚙️ Change was handled with traceability, not fire drills That’s what agentic delivery unlocks. It’s not just AI stitched onto old workflows. It’s a new operating system for how delivery gets done— powered by agents that structure, generate, and evolve work with you. Not to replace people. But to give your best people the leverage they’ve never had before. → Fewer handoffs. → Less rework. → Stronger knowledge reuse. → Faster, more confident go-lives. This is the future of services. And it’s already being built. Welcome to the era of agentic delivery.

34

4 Comments

Today we released Rootly's largest open-source project to date: On-Call Health. It helps engineering teams spot risk early by pulling signals from tools responders are using: Rootly, PagerDuty, GitHub, Slack, Linear and Jira. These signals feed into a risk score that tracks trends over time, relative to each person's own baseline. We built this alongside engineering teams at Brex and Weights & Biases - their feedback shaped everything from the scoring to the integrations we prioritized. Try it now at https://oncallhealth.ai/ – fully open source and free to use.

89

2 Comments

What if coding agents could reliably implement your software? Not just for a single session... but for an entire project 🤩 I kept hitting the same wall: the agent would start strong, then drift, then hallucinate requirements I never mentioned. By session three, we'd lost the orientation completely. The problem wasn't the AI. It was me. I was "vibe coding"—prompting on instinct without structured constraints. So I explored a different approach: Spec-Driven Development. The idea: make specifications—not code—the primary artifact. You define what and why before the agent writes a single line of code. The specs become a "memory bank" of your intent. The agent references the memory bank and implements your intent. I tested three open-source frameworks (Spec-Kit, OpenSpec, AgentOS) to explore how Spec-Driven Development works. My takeaway? The specific tool matters less than the approach. Full breakdown of my learnings and experiences on my blog: https://lnkd.in/ek93HPnn #AICoding #AgenticAI #SoftwareEngineering #ClaudeCode #SpecDrivenDevelopment

27

22 Comments

Renovating a house feels a lot like building custom software. Earlier this year, I decided to take on a home renovation project, solo. No general contractor.  Just me managing every sub, timeline, and task. After 15+ years building software and leading dev teams, I saw too many parallels to ignore the challenge. Here’s what I learned about how home renos/rehabs and software dev are basically the same beast: 1. Pre-planning: Just like you don’t write a line of code before understanding your user needs, I didn’t swing a hammer before walking the property with inspectors, measuring walls, and mapping out what success looked like. Same as building product: you don’t write a line of code before understanding the user. 2. Schedules = Sprints: Plumbing before drywall. Paint last. A full Gantt chart was built out just like I do with all my software execution plans. I built my reno like a roadmap, with dependencies, buffers, and milestones. Delays and scope creep aren’t exclusive to one or the other, but are manageable if you plan. I ordered my cabinets the day my house closed because I knew there was a 5 week lead time on getting them delivered.  Sound familiar? 3. Frameworks vs. Finishes: LVP or tile? Quartz or quartzite? React or Flutter? Every choice has tradeoffs. It's important to research and know the pros and cons of each and make the right decision accordingly.  Don’t just pick what looks good or is trendy at the moment. 4. People over plans: A flaky tile guy is the same as a low-accountability dev: they’ll slow down the whole build. Execution lives and dies by who’s on the team. 5. Know when to stop: Not everything needs a redesign. I passed on upgrading the pool with pebble-tec and left a few “good enough” finishes as-is. Same goes for product development—some features have low ROI and won’t move the needle. Not every 1.0 needs to be a masterpiece. – Was it stressful? Yes. Would I do it again? Also yes. Because just like shipping v1 of a product… Seeing your vision come to life is worth it. And whether you’re building code or cabinets, it all starts with the same thing: A solid Blueprint ;)

23

5 Comments

Whenever you're writing something at work (whether it's a pull request, a document, a system design, a bug report, a feature request, etc.), make sure to give it a meaningful title and a TL;DR. Make it easy for folks to get a grasp of what it is you're doing.

52

5 Comments

Lately I’ve been thinking about what great technical management looks like. The best analogy I’ve found isn’t from tech. It’s from a Michelin kitchen. A chef de cuisine doesn’t just "manage". They set the menu, **taste every plate**, lead service, train the brigade, run inventory, negotiate with suppliers, and jump on the line when the heat’s on. They’re administrative and **deeply culinary**. People follow them BECAUSE they can cook, not because they are great with people. tl;dr: This is the blueprint for EMs! Make sure every manager in your company thinks like a chef! The customer must have a great, standardized, rewarding experience EVERY SINGLE TIME! # What great chefs do → what great tech managers do ## Menu & vision - Chefs design the menu end-to-end. - Managers work with the team on a clear technical vision and roadmap: architecture, quality bar, tradeoffs. ## Taste everything - Chefs calibrate the palate of the team. - Managers calibrate "engineering taste": design reviews, code reviews, help reach or make tech decisions. ## Mise en place - Chefs enforce standards so service flows. - Managers enforce engineering standards such as testing, CI, on-call hygiene, observability. This is key to make delivery flow. ## Train the brigade - Chefs teach technique and judgment. - Managers mentor with activities like pairing, helping with postmortems or creating growth plans. ## Run the pass - Chefs expedite during service under pressure. - Managers lead incidents, make crisp calls, keep outcomes and morale high. ## Suppliers & costs - Chefs handle vendors, budgets, margins. - Managers handle vendors, capacity, budgets, and the “efficiency of taste”, while making decisions such as build vs. buy or scope vs. value. ## Jump on the line - Chefs still cook. They are responsible for R&D, new dishes and covering gaps. - Managers stay hands-on enough to be credible by creating prototypes, doing spikes, pairing on hairy PRs, reading code or shipping small fixes when it truly helps. # Disclaimer I'm not saying the Engineering Manager as a Chef is the only possible way or even the best way for your scenario. Just sharing that in my experience it has provided the best results. # Conclusion If you want to follow this path, here’s the uncomfortable bit: in both worlds, staying technical isn’t optional. BEING TECHNICAL IS NOT OPTIONAL for a chef! So it is also not be optional for an engineering manager with this mindset. The team needs to see that your judgment comes from lived technical depth and not just from management discipline. Let me be 100% clear: you don’t have to out-code your senior ICs. But you do need current, working knowledge of your stack, constraints, and craft so your decisions land and your standards stick. If you want a team that aspires to excellence, be the kind of manager whose “food” they want to taste! Lead with vision. Set the bar. Teach the craft. And keep your hands close enough to the stove to feel the heat.

46

4 Comments

I once worked with a junior dev who was silent for weeks - just nodding along and trying to figure everything out alone. When we finally sat down, they were three weeks behind. All because they didn’t want to “look stupid.” Here’s what I tell every new hire now: Ask questions early. Often. Loudly. No one expects you to know everything. What matters is how quickly you learn. And honestly? Asking thoughtful questions is one of the fastest ways to earn respect.

69

8 Comments