I’ve only been a people leader for 3-4 years, and when I first stepped into the role, I assumed the job was about unblocking people and setting direction. That’s true—but incomplete.

What I didn’t expect is how much of it is about shaping constraints. Left unconstrained, good developers will build… anything. And I mean that in the best way.

Developers Will Always Choose the Interesting Problem

One of the joys of working with strong engineers is their creativity. Give them a problem like “we need to reliably schedule, run, and monitor a growing set of interdependent data pipelines” and you’ll get a spectrum of solutions:

  • Airflow on Kubernetes—full control, full operational burden
  • AWS Step Functions—managed, but tightly coupled to AWS
  • Lambda functions chained together with custom retry logic
  • A workflow framework like Prefect or Dagster with its own deployment model
  • Or—occasionally—a well-placed cron job

Creativity naturally gravitates toward interesting complexity, which raises the floor of technical knowledge every engineer on the team has to maintain.

As an individual contributor, that instinct is often a strength. As a manager, I’ve started asking different questions: Who is going to maintain this in 18 months? How long will onboarding take for a new hire? What happens when the one person who built this leaves?

And then the harder one: what happens when I leave?

If I champion a technology and then move on, I don’t just leave a gap on the team—I leave a technical inheritance for the rest of the organization. Someone has to understand it, support it, and decide whether to keep investing in it or pay the cost of replacing it. The broader the footprint, the bigger that burden. My technology decisions can quietly shape the org’s trajectory for years after I’m gone.

That’s where constraints come in.

Focus Is a Finite Resource

Everyone has a finite amount of cognitive bandwidth. Time spent learning a bespoke internal platform is time not spent on the actual domain problem the team exists to solve.

If you have a team of engineers with a particular area of expertise, you want their skills compounding on those problems—not on debugging infrastructure they didn’t sign up to own.

Important: I’ve learned that setting a default like “we prefer managed or widely-adopted tools unless there’s a clear, long-term reason not to” means new engineers onboard to familiar territory, the team isn’t dependent on one person’s tribal knowledge, and cognitive load stays where it belongs.

New Technology Is a Team-Wide Commitment

This is something I only recently started to internalize.

When someone introduces a new technology—a new framework, a new infrastructure pattern, a new language—it’s rarely just a technical decision. It’s a commitment the whole team has to honor. Everyone will eventually need to understand it well enough to review code, debug it when something breaks, and onboard new hires into it.

That’s a real cost. And it’s often invisible to the person proposing the change, because they’re excited and have already done the learning.

Note: What makes this especially hard for me: I’ve been that person. I still am. I love exploring new tools and pushing into unfamiliar territory. But I’ve realized that my enthusiasm for something new can inadvertently set a direction the whole team has to follow—whether they’re ready for it or not.

I’ve had to learn to make that cost visible, and to make sure the whole team is aligned before it’s incurred. Not “never adopt new things”—but asking: Are we all in on this together? Does the team understand what we’re signing up for? If yes, move forward. If no, that’s the conversation to have first.

Constraints Don’t Kill Creativity—They Redirect It

For a long time, I was hesitant to impose constraints. It felt like limiting the team.

I’m starting to see it differently. When the scaffolding is decided, engineers can pour their energy into the interesting parts: the domain logic, the edge cases, the optimizations that actually matter. The creativity doesn’t go away—it gets applied where it counts.

Without constraints, every project becomes a mini research effort. With them, teams build on a shared foundation instead of reinventing it each time. Decision fatigue drops. Onboarding becomes predictable. Knowledge concentrates where it matters.

But What If I’m the One Pushing Boundaries?

Here’s a tension I haven’t fully resolved: sometimes I’m the one with the new idea. I see a problem space, get excited, and want to explore it.

I’ve learned that my role in those moments is different than my instincts want. When I was an engineer with a big idea, I built a proof of concept and convinced people. I’ve found that as a leader, I do better when I define the problem—and then create space for the team to figure out how they want to solve it.

Important: There’s a real difference between “I think we should use X to solve this” and “Here’s a problem I think we have—I’d love us to research it and align on an approach.” The first shortcuts the team’s ownership. The second invites it.

Honestly though? I’m still working on this. I catch myself dictating not just what problem to solve, but the specific approach, the implementation details, the shape of the solution. That’s micromanagement, even when it comes from genuine enthusiasm. The instinct to jump to solutions is hard to unlearn when you’ve spent years as the do-er.

When Do You Actually Innovate?

This is the question I keep coming back to.

My default has always been: do the thing that needs to get done. Work the long hours. Pick whatever technology solves the problem fastest. I’m not apologizing for that drive—it’s gotten a lot done.

But the accumulated cost is a tech stack that looks like a museum of every interesting problem I’ve ever encountered. A different tool for each era. Each one made sense at the time. Together, they’re a maintenance burden the whole team now carries.

So when is the right time to innovate? Not “never”—and not “whenever someone is motivated enough to make it work.” I’ve started thinking it’s when there’s a genuine problem the current tools can’t solve well, the team has the bandwidth to own something new, and there’s real alignment—not just one person’s momentum.

Note: The hard part is that “we could probably make the existing thing work” is almost always true. Innovation requires making a deliberate case that the cost of staying put outweighs the cost of change—and that’s a team conversation, not a solo decision made during hundred-hour weeks.

How AI Fits In—But Not How You’d Expect

AI is often framed as a solution to complexity. Sprawling codebase? Feed it to the model. Five unfamiliar tools? Ask the AI.

And yes—AI can absorb massive amounts of context. But I’ve started to think about it differently.

Note: The more constrained the stack, the more effective AI becomes. When engineers work within a focused, well-understood set of tools, AI can spend its context on the actual problem—the business logic, the edge case, the data transformation—instead of burning it on “how does our custom orchestration layer work again?”

A sprawling tech stack doesn’t disappear when you introduce AI. It becomes AI’s problem too. Less noise, more signal, tighter feedback loops on the exact problem that needs to be solved.

The Shift from Builder to Steward

As an IC, success looked like building something impressive. I’m still learning that as a leader, it looks like systems that are easy to maintain, teams that onboard quickly, and decisions that age well.

That shift is uncomfortable. I’ve had to start saying “no” to technically exciting ideas in favor of simpler, more durable ones. But the payoff shows up over time—fewer late-night incidents, less tribal knowledge, more predictable delivery.

Engineers will always find the most creative path forward. I’ve come to see that one of my jobs is to make sure that creativity lands where it matters most—on the problems the team has the skillset to solve.

Important: Technical constraints aren’t a cage. They’re a way of saying: we trust you to do great work, and we’re going to protect the space for you to do it.