Books for software engineers and managers

An Elegant Puzzle

An Elegant Puzzle

Systems of Engineering  Management

by Will Larson, CTO of Calm

Engineering Manager,
Tech Lead

How strongly do I recommend An Elegant Puzzle?
8 / 10

Review of An Elegant Puzzle

What I like about An Elegant Puzzle is the narrow focus on engineering management. While many books are about engineering or management, this book finds the intersection.

This book is a dense read and initially I was surprised by the breadth of topics covered. The author covers team structures, system migrations, hiring, succession planning, and much more.

An Elegant Puzzle is most useful for engineering managers who have been in their role a year or more. You’ve settled in a bit and developed a routine. You’re comfortable enacting change. Now you can start seeing some of the issues and opportunities that Will Larson presents.

Much like Larson’s newer book Staff Engineer, An Elegant Puzzle has a Silicon Valley orientation and you may need to take some advice with a grain of salt, particularly around company and team growth expectations.

Keep innovation and maintenance together within one  team

As engineering teams grow, a common pattern is to split work. One team works on innovation, the other on maintenance.

For the innovation team this initially seems great. They’re working on exciting greenfield projects. Opportunities are endless.

The maintenance team sees things differently. They’re stuck on legacy code with no career growth opportunities in sight.

The quickest way to lose trust is building science projects in the name of  innovation

Innovation usually starts out with a practical application. But it can quickly evolve into a science project as engineers get excited about the technology.

Building science experiments is a recipe for frustration from teams depending on successful delivery from your engineers, and the ultimate defunding of your team – either literally or in confidence.

The real cost of rewrites is not the rewrite itself, but the subsequent data and system  migrations

Great, you rewrote that nasty part of your application. No doubt the new code is cleaner and hopefully better tested.

Now comes the tricky part – migrating everything over to the new system. Now you’re touching parts of the system and code you never intended to. Now you’ve entered the dreaded boondoggle.

Boondoggles happen when projects spiral out of control. Small rewrites quietly become multi-month monster projects that suck energy and momentum.

Counterintuitively, the worst mistake you can make is bailing part-way through and leaving a half-done migration. Finish the work you started.

When something stops working at increased scale, it is a sign the system was designed appropriately and not  over-designed

It’s easy to take pride in systems that are still standing years after they were built, despite increased load.

But that might be a sign the system was over-designed to start.

Developing for scalability needs balance with YAGNI and the understanding of opportunity costs. That time you spent building a scalable system early on may have been better spent on something delivering more business impact.

As you move from generalists to specialists, you will create more single points of  failure

Growing teams typically create more specialized roles. A team of full-stack developers starts hiring mobile engineers, which splits into Android engineers and iOS engineers.

As we introduce more specialized roles, we unfortunately create more single points of failure. If you only have one Android developer and she gets sick, how are you going to deploy that Android critical fix?

Most engineering managers struggle with time management; they should stop handling exceptions and design paths for someone else to takeover  work

For your team to grow, managers need to stop handling exceptions and open the door for somebody else to takeover that responsibility.

One of two things will happen:

  1. Somebody steps up
  2. Nobody steps up, in which case there’s a good chance your contribution wasn’t that valuable to begin with

The author provides a longer list of ways managers fail to manage their own time, but I found these tips the most useful.

The first step to succession planning is to figure out what you  do

Succession planning isn’t something I thought about much as a new manager. I was just doing my job and doing it well.

But for my team to grow 2-3x, I needed to start thinking about the work I did and who on my team can grow into that work.

Whether you consider it succession planning or delegation, taking an inventory of your work will provide growth opportunities for the developers on your team and yourself.

Treating your peers as your first team allows you to practice your manager’s  job

As a manager, it feels like your first responsibility is your own team. You watch over them, support them, and lead them.

But your peers are other managers.

And if you’re expected to takeover your boss’s role, you need to start thinking about serving your peers. Attend to their needs and find areas to lead among those peers to practice the job of your manager without yet taking over that formal responsibility.

That also means growing a more self-sufficient and sustainable operation within the team you manage.

An Elegant Puzzle