Deliberately Shaping Engineering Organizations

Your team’s running along and getting work done. You’re busy supporting all of that, which is great. But don’t lose sight of the longer-term leadership work of shaping the org, or you’ll waste the current momentum. Leaders obsess over product roadmaps but treat their future org chart like weather: we’ll look out the window in the morning.

That’s how you end up “promoting” whoever’s standing closest, scrambling to retrofit teams to needs you never considered, and building permanent structures out of temporary problems. Shaping organizations is deliberate leadership work. Let’s cover the four most common ways we screw it up.

Arm’s Reach Solutions

I have the somewhat annoying habit of asking leaders what their teams will look like in 3-6 months. Often, the answer is some stuttering accompanied by general hand waving. That myopic attitude translates in practice to leaders who go for the easiest solutions in front of them.

This is not about coming up with the wrong conclusions and therefore being forced to do something fast. It’s about not even thinking about what might happen. That’s how I regularly see leaders scrambling to promote ICs to managers for the main skill of being there. I’m highly in favor of internal growth and promotion, but it doesn’t make sense if we’re talking about people you never interviewed for their management fit and potential. You have to treat promoting them a bit like interviewing them all over again, or you’re shaping your org haphazardly.

Autopilot hiring is another symptom of this. Don’t make these decisions following the path of least resistance. Think about the actual role’s requirements, discuss it with the person you’re considering for the position. I highly recommend setting up an experiment to evaluate the fit before making a decision that’ll be harder to undo.

Not Considering the Happy Path

Senior tech executives, especially those who aren’t cofounders, often need to boost their optimism. We regularly see the contrast of a startup that has audacious goals, but the eng org isn’t set up to support them. It’s as if we don’t believe our own plans.

For example, consider leaders who are reluctant to grow a certain team, believing the peak in work needed is solely temporary. That might be the case, but if the peak is actually in line with the company’s bet on spinning up a new product or expected growth, you might as well face the truth and plan for the peak to become your new standard.

You can also see this when you think about the company’s growth goals, e.g., number of new clients they expect to onboard, and contrast it with the team’s ability to support that. Sometimes it’s obviously not feasible. Like when customer success is will break down under the load long before those goals are reached, or the architecture isn’t made for that scale.

Sometimes these are issues that can be solved along the way, but other times we’re talking about efforts that take time (you cannot double customer success throughput in a week). Consider the happy path and ensure you’re not shaping your organization to become the bottleneck that prevents it from being achieved. Don’t miss the boat.

Shaping with Unrealistic Optimism

This doesn’t happen as often, but it’s still an issue. Especially around areas that engineering leaders are naturally more excited about. For example, when they hire a bunch of DevOps people because it’s needed to set up the environment right now, not realizing that even if the company grows 10x, this DevOps effort is not supposed to maintain the same level of work in the future. Any time we’re hiring specialists for short-term needs, we’re bolting down the organization in a way that will make it harder to react to our actual needs in the future.

Similarly, when we create tiny teams assuming growth will magically handle this. If your plans don’t realistically show that growth as happening anytime soon—don’t do it. Not a week goes by without me seeing a startup that has created nano-teams (a manager and a couple of team members) without any chance of those becoming proper teams even a year into the future. This ignores the managerial overhead that you start paying immediately, and shapes the organization to just be too clumsy and slow.

Only Changing Under Pressure

As opposed to our first point, this is not about being reactive, but about not taking advantage of opportunities to do things differently when we still have them. When we wait too long and start moving when the deadlines become tight, we no longer have enough room to experiment properly, even if we want to. You cannot innovate in a situation where taking a wrong step means the project will fail.

Those moments will inevitably come; we cannot foresee everything, but they shouldn’t become your default mode. Run lightweight trials when there’s no existential pressure. We make better decisions and are more innovative when there’s breathing room.

Shape your org before reality does it for you. Shape up.