Hey!

Chris here. Welcome to Blueprint—the newsletter to help you build a winning engineering team.

Today we're tackling something I've spent 20 years figuring out: why some engineers need complete silence to work, while others thrive in chaos—and why you need both.

Every engineering leader gets this wrong at first. I did too.

But once you understand it, everything changes.

Shall we?

📒 DEEP DIVE

Heads Up vs. Heads Down Engineers

The 2 types of engineers every startup needs

Not all engineers are cut from the same cloth and trying to make them fit the same mold is killing your productivity.

There are 2 distinct types of engineers:

1. Heads-up Engineers

2. Heads-down Engineers

Once you understand this it changes everything about how you should build your team.

Most engineering teams fail because they try to make everyone good at both. Let me show you why that's a mistake, and what actually works.

Heads-Down Engineers

These are your deep technical problem solvers. When they say they need 3 hours to get into the right headspace, they're not exaggerating—here's why:

➝ Their work requires loading complex systems into working memory 

➝ Each interruption doesn't just pause their work—it resets their entire mental model

➝ They process problems by diving deep into technical details and examining edge cases

➝ Their best solutions come from uninterrupted analysis and systematic thinking

The key insight here? Even if you gave these engineers unlimited time for client communication, they wouldn't excel at it. 

Not because they're antisocial, but because their brain is optimized for deep, focused problem-solving.

Heads-Up Engineers

These engineers specialize in rapid problem resolution and client interaction. Here's what makes them different:

➝ Their brain excels at quick context switching without performance degradation 

➝ They can hold multiple concurrent problems in their working memory 

➝ They naturally translate technical concepts into business terms 

➝ They thrive on the variety of handling multiple issues simultaneously

This isn't about being "better" at communication—it's about how their brain naturally processes information and switches contexts.

Building an Effective System

You need both types of engineers to build a killer team. One isn't better than the other—the key is building a system that leverages these different working styles. Here's how:

1. Own Your Role as a Leader

➝ Take responsibility for the interruptions

➝ Tell your team: "I'll watch Slack. You focus. If there's an emergency, I'll call you."

➝ Create clear handoff points between your different types of engineers

2. Build Real Focus Time

➝ Kill the "quick sync" culture

➝ Funnel everything through one system (pick one—Jira, Asana, whatever)

➝ Create an ownership registry so people know who handles what

3. Shield Your Deep Thinkers

➝ Let your heads-up people handle the front lines

➝ Stop forcing your best coders into client meetings

➝ Batch process interruptions instead of handling them real-time

Make It Happen

If you're running a technical team and you're not actively protecting your engineers' different working styles, you're sabotaging your own productivity.

The solution isn't about making everyone more well-rounded. It's about building systems that let your engineers work the way their brains are wired to work. 

Because when you do that, both your team and your clients win.

🎙 EPISODE OF THE WEEK

Most of us start businesses doing what we love, but nobody tells you what comes next. 

Matt and I break down what we learned the hard way about turning passion into something that actually runs like a business. 

From the mistakes that nearly broke us to the systems that saved us, we share real stories from our combined 40 years of figuring this out. 

If you're struggling to make that leap from passionate expert to business owner, or if you're worried about losing your love for the work—this one's for you.

Take a listen here.

BEFORE YOU GO…

For years, I watched great CTOs struggle with their engineering teams simply because they didn't understand how differently they work. And the answer was right there—we just needed to look.

The difference between how engineering teams work today and what they could achieve by embracing these different styles? That's what gets me excited. 

And we're just getting started. There's so much more to share.

Talk soon,

Chris.