3 Must-Read Books for Platform Engineers in 2025
The new year is when we are most inspired to start something new and these books will help you become a better DevOps practitioner/Platform Engineer in 2025
As we're starting the new year, I like most of you want to make sure that 2025 brings more knowledge, skills and experiences allowing us to grow as Platform Engineers and DevOps champions.
Most of the recommended material in this space tends to be technical, often stemming from a break-fix way of living. We all make our living tackling problems head on and the ones we generally see are technical. Technical knowledge is abundant, from articles (even here on Substack), to video platforms such as Linkedin learning, but what that misses is the gaps created around things like trends, growing and managing teams and operational management.
Being successful in the platform engineering requires a broad understanding of things beyond just technical knowledge, and the 3 books I am recommending, in my humble opinion, can be the force multiplier for you in 2025.
Topic: GenAI
Book: "Autonomous Transformation: Creating a More Human Future in the Era of Artificial Intelligence" by Brian Evergreen
In 2024, GenAI took the world by storm. We live in a world where we are surrounded by ChatGPT, AI artwork, AI postings and AI in most digital products. I think it's important to understand reality versus hype. AI will have impacts, but knowing how it can/will impact will allow you to navigate those changes.
A quick GenAI primer: GenAI is software made to respond with natural language; it does NOT have to be correct or accurate in fact it often (don’t take ChatGPT on it’s word). The fact of the matter is that the underlying concepts for LLMs (on which GenAI is built) have existed with natural language processing (NLP) for decades. I actually studied it in the late 2000s. What's changed though is that LLM became possible simply because cloud computing provided cheap and quick access to lots of compute and storage. While it's good at common tasks, multi-dimensional ones such as software development can difficult - I highlighted why in the following post [linked here]. It will free you up to tasks that aren't so hands-on-desk.
We as humans associate communication with intelligence, and I think that has a lot to do with the hype that has built around GenAI. The next phase for this type of AI is Artificial General Intelligence (in this case, it would be correct more often than not and able to take on more complex tasks). It is still unknown if it is even possible do do this, let alone the timeline for such a rollout.
What muddies the waters is the sources driving the hype behind these technologies are also investors who are trying to grow interest in this space. They provide subjective opinions not objective. Nonetheless, interest in this space does mean additional funding in the coming years.
The last decade belonged to digital transformations - organizations modernizing systems to compete in a changing world. The next decade (or less?) of transformations will be driven due to AI. Autonomous systems will complete certain tasks that were previously only the domain of humans - I'm not saying this is a bad thing. We're not as good at repetitive tasks (think of error rates), pattern matching at scale, etc.
This book shows how AI agents are going to impact the way we work. Truth is your leaders are already exploring AI (or at least AI products), it's worth understanding how it will impact you and your role.
Topic: Leadership and Language
Book - "Leadership is Language", L. David Marquet
Failure is the best teacher, and sometimes it is better to learn from other peoples' failures than making the same mistakes. Leadership is Language shows how the 2015 sinking of the SS El Faro ship was largely avoidable and that good leadership could have prevented this tragedy.
As a consultant responsible for many newly anointed leaders, I see people that are transitioning into leadership roles often make mistakes assuming they have a higher output as an individual contributor. Becoming a leader requires a change in approach from always being a "doer" to becoming an "enabler." The goal is no longer to maximize your own output, but to maximize the team's output ensuring it delivers outsized results to an organization. This book has a good way of showing the mistakes we easily make as leaders (I know I have): staying the course due to sunken cost fallacy, prioritizing schedule above all else, and dismissing team member's concerns.
While many of our jobs may not be life and death, there are real world impacts to poor leadership. Platform Engineers have to lead not only their teams, but as problem solvers are leaders bringing disparate teams (like business, development and cybersecurity) to work together.
Things I have learned and adopted from this book:
Adopting intent-based leadership instead of command.
Real world application: rather than telling someone in a "I need you to...." ask "What do you see?". This changes the focus to empower your team and for them to take ownership.
Move from binary decisions to nuanced thinking.
Real world application: Instead of asking "Are you sure?" to "How sure are you?" will allow for a more complete picture to make decisions from.
Focus on learning from failures.
Real world application: When things go wrong, don't just jump in to fix, berate or dictate what to do, instead ask "What was your thought process?"
Change approach to conversations.
Real world application: Avoid asking leading questions, and focus on asking What vs Why.
Embrace silence and take the time for reflection.
Real world application: The goal as a leader isn't to achieve compliance (that's more dictatorship vs. leadership).
We get promoted because we are good at our role, but leadership requires us to shift our focus which instinctively goes against why we thought we got promoted in the first place. This book helps navigate that transition for you, and will ensure that your team does too.
Topic: Engineering
Book - "Shape Up", Ryan Singer
I find in life in general, we do things because that's the way they're done. Given the million things that happen to us on a daily basis, we often don't question it. In tech, we are no different. Take a step back and ask yourself:
Is your sprint cadence working for you and your team or do you find there's not enough time?
Do you find by the time the team get to development/implementation, more time is wasted flushing out features/what needs to be done resulting in overrunning estimates?
Are the processes that your team has are working against them rather than for their benefit?
This book is from the team behind Basecamp and how they run their engineering. They've done a great job of building a system that works for their team to deliver on time and within budgets - it requires features to be properly scoped and the leadership team to decide what's priority. Most importantly, once teams start working they aren't interrupted by unnecessary meetings, distractions, etc.
So, how does this apply to platform engineers? While it's more oriented towards developers, there are items that platform engineering teams can take back as lessons for adoption:
Platform engineers work with multiple teams both vertically and horizontally in an organization. It means they need to have insights into upcoming projects, requirements, and be able to plan for those. Their 6-week sprints gives time to make significant shifts that might be necessary whereas 2-weeks can be too short especially if items haven't been scoped appropriately. Alternatively your team might using PI planning to group 5-6 2-week sprints and understand risks early on to deliver on expectations.
Empower teams to be autonomous, they can break down their own tasks and highlight unknowns early on. This draws a balance between insights to management and ownership by team members. I've found when teams are encouraged to take ownership the quality of the work delivered is vastly improved.
Use the betting table to force leadership to make decisions on what's a priority. You only have a limited amount of time, prioritize and focus on value. If we start treating features as hypotheses and gather feedback it can benefit planning and building next set of features.
The lessons in this book may not be implementable in your organization directly, for example, if your focus is hardware-oriented R&D it might not be an ideal fit, nonetheless the approaches and though process outlined can be adopted to improving your teams internal process.
If you have a book recommendation, or would like to share your experience with any one of the three titles, comment below!