Delegate decisions not just tasks

Jane, Joe, and Alice notice a scaling issue – critical operations that used to be fast are getting slow and users are complaining. Nothing is broken, but there's a growing sense of frustration.

Joe suggests "hey we could shard the database! I read a blog saying that's how big companies achieve scale"

Alice sighs, rubs her temples in frustration, and shoots him down. "Joe ... our data fits on a large SD card, we don't have time for your big ideas. Let's just add an index to the slow queries and hope that solves it"

Alice is not wrong – sharding your database is a last resort when all else fails. But if a version of this conversation happens every day, how soon before Joe takes the hint and shuts up? Alice always knows best and we'll leave her to it.

A few months pass and Alice is burnt out, in meetings all day every day, at the end of her line, and wondering why she's surrounded by a bunch of people who can't do anything on their own.

She did this to herself! The quickest way to kill a team is by setting a bar where ideas are "good enough" to share. Ridicule anyone who gives a suggestion that's below your bar. See how fast they stop sharing.

The solution is to aggressively let others do the work.

Early in a new product's life, you get to own everything. You build the code, you design the architecture, understand every stakeholder's wants and dreams, handle every bug and feature request. You own the process start to finish to on-call.

You think it, you build it. The product and the code are an expression of your best vision for how software should work. You don't achieve every dream, but you do your best with the resources and skills available.

When new people join, they look at your baby and they have ideas. What if you moved this code over there? What if the API was easier to use? How about we try something other than your favorite library?

At this point you have to make a choice:

If you try to stay in control, you'll drive everyone crazy. Mostly yourself.

As you attempt to keep an iron grip on the direction of the product and its codebase, you'll frustrate new engineers who have their own ideas and suggestions. They suggest obvious improvements, but every idea turns into a long battle when it doesn't fit your vision.

You think you're defending the quality of the vision, but really your ego feels attacked and you're pushing back. How could something you designed so carefully not be perfect? Who are these people to tell you there's a better way? Don't they understand the constraints you were under?

That was 2 years ago. Those constraints have changed.

If you keep this up, you'll become the bottleneck. The person we need to consult for everything. That means meetings all day every day.

Or, you can let go of your legos: Set guidelines, agree on basic design and architecture goals, then ... let go. Problems will get solved in a way different to yours and that's okay. As long as they're solved.

Love the problem, not the solution.

Users hire your software to do a job. They don't care how you do it as long as the app doesn't get in their way, usually works, and isn't frustrating to use. Likewise stakeholders care about your team being able to keep things running and make improvements without blowing it up with bugs.

Beyond that, nobody cares about the details but you. Relax. Let people do their thing. They'll make your baby better.

Your ego loves being the critical member of a team.

Everyone looks up to you, seeks your advice, runs important decisions by you, and makes sure their code is up to your standard. You're the genius who started this product and knows where all the bodies are buried. Feels great!

Then one by one your team starts leaving.

Joe gets pulled into a critical company-saving project. Huge career opportunity. Alice single-handedly talks the CMO off a ledge and repairs an important stakeholder relationship after a bug killed their metrics. Jane spends more and more time with product, helping define long-term strategy.

All the while you're sitting there making progress on your team's core products and making sure everything looks right. Your ego loves it, but your mind is thinking "Where are MY opportunities?".

They're not coming. You're critical to this project. We can't afford to lose you. Plus aren't you swamped being in every pull request, meeting, chat thread, and discussion about your precious baby? You don't have time for new opportunities!

This is the hidden cost of hoarding your legos: You become trapped in your role. No time for big opportunities.

Your goal should always be to code yourself out of the job.

Then step back and relax. You've empowered the team to play with your legos and you're free to take on new challenges and opportunities.

You might even change jobs to a different part of the business! Leave your baby in the good hands of your team. Trust.

As teams and products grow, early members think they understand everything at a deep level, but they're not as involved as they remember. This could be you.

When you started this thing, it was just you and few others. You helped with every major decision, discussed every detail, and wrote much of the code. You knew everything.

As new people joined and teams sprung up, you graciously shared your legos and let everyone work. Fantastic!

At first you can keep track of the code and how things are changing. You see every pull request and discuss every big feature.

Then surprises start to creep in: You can't find a familiar file. You go to fix a bug and it's not where you expected. You see an unfamiliar code pattern. A weird library you've never heard of.

One day you comment on a pull request and the bomb drops. "We tried your approach and it didn't work because the big feature we built last week doesn't play nice with ...".

It happened: You no longer know best. You're too far removed to understand every nuance and detail of the codebase.

While you were running around maintaining a technical vision for your baby, the team was making progress. Small details changed. Local problems here and there that folks ran into. Nuances that fit together by sheer force of will and a glue function or three.

You can get spooked by this, try to rein in control, and throttle all progress. (don't do this) Or you can get out of the way. Someone just spent a few hours thinking about the issue and how best to solve it while you've spent 5 minutes looking at a pull request. Who do you think is the expert today? 😉

Have feedback, give suggestions, but defer to the person doing the work. As one of my managers used to say: "I would advise against that decision, but you're the one maintaining this system"

The engineer closest to the problem has to own the solution. It's the only way to scale. You can't fit a whole company in any one person's brain.

You need people with a broad perspective who set and nurture a direction and people with a focused perspective who implement the details.

PS: if you find yourself already stuck as an Alice, the best time to fix that was 2 years ago. The second best time is now.