The Future of the Engineering Org

The compounding impact of globalization, post ZIRP efficiencies and advances in developer tools??

I have the pleasure of speaking with hundreds of senior engineering leaders each year. One thing that I have noticed in the last year is that we’re on the cusp of a substantial change in the nature and composition of the software engineering org at most companies.?

The nature of the engineering org is fundamentally shifting, creating opportunity for early stage (series A and B) startups and threats for more established businesses with a legacy engineering org. I’m going to be spending the next few months unpacking the changes and interviewing CTOs and VPEs to share the experiments they are running to make their orgs more efficient and impactful.?

Initially this seemed like a series of unrelated threads, the three biggest being remote/hybrid, “the year of efficiency” and more powerful developer tools.?

1. Working from anywhere?

The pandemic proved what most engineers already knew - many developers can work (more?) effectively from home.

Despite the push and pull between managers who broadly preferred a return to office and employees, a substantial subset of whom preferred the flexibility to work from home, in the long run, we’re going to end up with most companies supporting a hybrid workforce with a non-trivial number of remote employees and (if they’re doing it right) a remote first culture that doesn’t make their more distant colleagues feel like second class citizens.?

One of the natural second order effects is that many engineering orgs are going to become more distributed, at the very least experimenting with international staffing.

There are real practical challenges in creating truly global teams with less than 4-5 overlap hours daily, so nearshore is going to continue to grow as one of the best ways to attract a quality of talent you might not be able to engage with in NY, SF, London or Berlin, while reducing the blended cost per engineer on your teams.

?2. Personally I blame Zuck :)

A second thread is the “year of efficiency”. We’re moving to a world where we are rethinking the role of engineering managers and focusing more on efficiency and productivity than we did in the recent past. Some of this is definitely the pendulum swinging too far in the opposite direction, and as the market starts to absorb the talent shed by startup failures and big tech we’re going to have to find a new normal that is more efficient than a few years ago but still attractive enough to retain top talent.??

3. The Rise of the Machines

The final thread is the rise of more powerful developer tooling. Not that long ago when you raised your series A and started the process of doubling your team size every 12-18 months a meaningful subset of the talent (maybe 20-30% depending on the nature of your offering) was in platform/DevOps/SRE, building the infrastructure required to support your feature teams.?

These days with Internal Developer Platforms and other “platform” tools, it’s quite plausible for you to migrate off a PaaS like Heroku or Fly.io and build out your own sophisticated infra with a team of just 3-5 platform engineers supporting 50-80 engineers in feature teams.?

And feature teams are not immune to the impact of better developer tooling. From low code/no code tools allowing us to delegate the details of authentication or search to third parties like Auth0 and Algolia, and the nascent adoption of LLMs for both code generation and other elements of the Software Development LifeCycle (SDLC) we’re going to start to see a difference in the number of engineers required to deliver a given velocity of software development.?

How to Plan

The world, by its nature, is a Complex Adaptive System. (If you haven’t already done so, check out Dave Snowden’s Cynefin framework that provides a way of thinking about different types of systems).???

“Act, inspect and adapt” (or in Cynefin, “probe, sense and respond”) is the preferred approach to engaging with complex adaptive systems, because second and third order effects often mean that simply trying to reason about such systems proves insufficient and misleading. Given that, if the nature of the engineering org is changing, we need to run a lot of experiments across culture, team composition and tooling to identify the new “good practices” for engineering orgs. Unfortunately, any given team can only run so many experiments at once.?

Aggregating experiences

As someone who knows a good number of senior engineering leaders, my goal going forward is to regularly interview a wide range of engineering leaders, aggregating, distilling and sharing heuristics for more efficiently running engineering orgs more quickly than any one company could do, allowing us all to become more effective leaders more quickly.

Looking forward to what we can all learn. Feel free to ping me if you’d like to be interviewed as part of the process, and subscribe to the newsletter to get access to the weekly hints and tips!