Top Ideas in This Book
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.
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.
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.
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.
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?
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:
The author provides a longer list of ways managers fail to manage their own time, but I found these tips the most useful.
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.
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.
How strongly do I recommend An Elegant Puzzle?
8 / 10
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.