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 it seemed like a series of unrelated threads. The three biggest being remote/hybrid, “the year of efficiency” and more powerful developer tools.

The pandemic proved what most engineers already knew - you can work 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 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 nearshore staffing. For anyone who hasn’t yet come across the term (apologies to everyone else), nearshore means hiring staff in time zone aligned countries - e.g. Canada, Mexico, and Central and South America for US companies and North Africa and Eastern Europe for UK/Western European ones.

There are real practical challenges in creating 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. I’m excited to be working at Engineer Access - a company focused on helping businesses to find and work with nearshore talent that is as good or better than their US and European based teams. Ping me if you’d like to try working with us to expand your org!

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.

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.

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 - https://thecynefin.co/about-us/about-cynefin-framework/ ).

“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.

My goal going forward is to regularly interview a wide range of engineering leaders, aggregating and distilling 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 or comment below if you’d like to be interviewed as part of the process!

If you’d like to be kept in the loop, sign up for our regular newsletter exploring “the future of the engineering org” here!

Previous
Previous

Are Player Coaches Beneficial for Engineering Orgs?