In the Phoenix Project (worth a read), there is a character called Brent, who is to go-to person for everything in IT. I don't know if this character was modeled after Brent Ozar, but I always picture him when I re-read the book, and I suspect he was that person in previous positions. I've been that person as well, and it's both exciting, fulfilling, and very stressful. At Redgate, that person has been Robert C, who is my go-to person for many questions.

In the DBA world, I think of Jeff Moden. He's been a prolific and incredible author over the years on many things SQL-related and is a huge proponent of others learning to write better code and better utilize the database platform more efficiently. I suspect in his company, he is the go-to person for most database-related questions and problems. I also suspect he solves most of them very well and has the influence (or power) to effect change.

However, are you Jeff in your organization? Do you have a Jeff? In many of the customers I work with, there is no Jeff. Sometimes there are very smart people, but they cannot effect change. Or they don't know how to go about making change happen. In other companies, there isn't anyone who is an expert on the database or related technologies. Too often, I think people aren't often aware of what expert really is and they just do the best they can without knowing if it's a great job or a poor one. That's my opinion, but it's based on decades of experience (and success) working with lots of others on database code.

The good news is that most of you can learn to be Jeff. You can work to improve your skills, both technical and interpersonal (soft), to raise the quality bar at your organization. Maybe you can get more work done and get a huge sense of satisfaction from your job (and a raise). Maybe you just want to get things done more efficiently and get away from work more often.

There are many ways to do improve the quality at work, but essentially the idea behind platform engineering is to produce tools that make developers and operations groups more efficient. The goal is to get more work done, easier, reducing the cognitive load on everyone involved with software. Not because they can't do the work, but because we want them focused on their specialty. Whether that's writing C# code for an application, writing zero downtime database changes, or making beautiful reports. The hassles of actually capturing and moving code should be something provided by a platform. A person can do some of this by sharing their knowledge, not just in conversations, but providing templates, models, standards, and other code elements that might help their co-workers become more productive.

DevOps is about producing code quicker, reliably delivering that to the customer, and raising the quality bar (don't forget this) and platform engineering is the next evolution here, where the tools, process, and flow are set to make the implementation of DevOps easier for most developers and DBAs. Even if your organization doesn't want to produce a platform, the idea of building and deploying tools (samples, models, snippets, etc.) to make someone else's job (or yours) easier and smoother is something we all can do. We can all aspire to be Jeff and get there with a little investment in our skill across time.