Following The Manager’s Path
You may have heard that I have a new book coming out. With co-author Ian Nowland, I’ve written a book called Platform Engineering: A Guide for Technical, Product, and People Leaders. And as I discussed recently on the Refactoring podcast, it serves as much as a follow-on to The Manager’s Path as it does a book for the niche audience of platform engineering leaders.
I wrote the first draft of The Manager’s Path in late 2015, after a four year period of intense learning and growth that came from being a new-ish manager leading engineering at a growing startup. In retrospect, it is amazing how much of what I wrote then still holds up to my own high standards after many additional years of management at larger companies and at larger scale. There’s very little I would change about the book; I channeled lessons that were fresh in my mind directly to the page, and with the help of many reviewers and contributors, I believe I captured much of the essence of management growth.
You might expect my follow-up to be about either managing at much larger scale (say, senior management at a big company), or more focus on the executive management side of things. But the truth is that management at big companies is as much about the quirks of the big company as it is about management itself, and executive management is well-trod ground that I’m not sure I have a novel insight into. So instead of pursing these obvious follow-ons, I wanted to write about what I’ve been learning since I wrote my last book, Platform Engineering.
Platform Engineering, whatever you might have heard, is not about a particular technology (say, kubernetes, or integrated developer portals), nor is it just a renaming of DevOps, nor is it a silver bullet that you build to solve all of your developer productivity problems. It is, in my opinion, the evolution of software infrastructure in response to the growing complexity of modern software engineering. And while there is a lot of technology needed to make it work, one of the reasons that companies struggle with their platform teams is that the industry lacks an understanding of how these teams should be structured and managed in order to succeed.
This is where the book comes in. If you are an experienced manager of application engineering teams, you may be great at getting large teams of people to adopt agile practices, ship quickly, and manage technical debt to a reasonable level. But the nuances of platform mean you need a somewhat different set of skills to survive. You need to balance agility and speed of shipping for the ability to plan and execute long-running initiatives. You may have significantly more control over your team’s roadmap, which means you are both engineer and product lead all at once, and your stakeholder group in this case becomes much more diverse and challenging. The operational expectations of shared software services are very high, and you need a team that mixes software, systems, and reliability engineering effectively. You’ve gotta deal with the inevitable push for the next great thing that your team wants to build to replace the old systems, and manage constant change in both your own systems and underlying dependencies without constantly pushing more work out to the application teams that use your stack. And, especially these days, you have to effectively defend the existence of your organization when there are budget crunches.
This is hard work. If I have one concern for the future of platform engineering, it’s that it might be so hard to pull off that companies will abandon it because there aren’t enough leaders who can do the job. But I also believe these skills are the next evolution of good engineering management, and even application engineering leaders would do well to familiarize themselves with some of them. We all need to occasionally run long, engineering-driven projects; we’d be better off if everyone got a little bit savvier at how to approach them. The lessons of rewrites and migrations are useful if you have inherited a legacy application stack that may need to evolve to meet your business demands. Developing product sense and making sure your own teams are applying it can help you become a better leader, and while you may have fewer stakeholder relationships to wrangle, that is still a skill every engineering manager needs to develop.
I have spent my career in the relentless pursuit of figuring out how to do hard things well, and I love sharing what I’ve learned with the world. If you care about improving the working lives of engineers through technology, this book will tell you why that’s hard to do, and give you some approaches to handle those challenges.
Enjoy this post? You might like my books: The Manager’s Path, available on Amazon and Safari Online, and Platform Engineering: A Guide for Technical, Product, and People Leaders, coming out fall 2024 and available in early release on O’Reilly Learning!
