“Solving challenges for architects at my organization is a work in progress. It isn’t that we need to bring in more external knowledge. For the most part, we have a lot of the knowledge that we need inside the organization–it just isn’t necessarily connected, and it isn’t necessarily very leverageable.”
—Wesley Beary, Architect of Engineering Practices and Culture, previously Salesforce
This week on the API Intersection podcast, we spoke with Wesley Beary–Architect of Engineering Practices and Culture, previously at Salesforce Technology. We originally reached out to Wesley after writing about the history of API Style Guides, as he played a key role in publishing one of the first open-sourced API standards. However, that was many years ago, and Wesley has continued to grow into a broader role at Salesforce after Heroku was acquired.
Focused on people, innovation, and learning, Wesley has been a part of Salesforce for over a decade now (including his time at Heroku). Using his technical background and focusing on API governance evidently led him to the organizational side of things. With hundreds of architects and thousands of developers, things can get muddled quickly without proper process, education, and communication. And that’s where Wesley comes in.
We’ve yet to have an episode where the lines of API governance blur with greater company standardization and company-wide process; it was definitely a unique insight into a very large-scale way of doing things.
From Team API Standards to Company-Wide Process
“Be able to take the technical knowledge and effectively advocate for that to impact the direction that we’re going in, and taking advantage of what your peers know and what you know, it really just moves the company forward when you combine it all together,” shares Wesley.
While Wesley began as a software architect focused on creating consistency across the API program, he eventually took on a much larger scope of governance and education across the entire company.
“I started working more on governance things, and I think that’s what led me more towards this culture stuff. I was doing all this API-related governance work, but I wasn’t designing every endpoint anymore; other people were. So, how could I better help them? Guidelines and processes were needed,” shares Wesley.
So, Wesley shifted to producing a design guide, filling that broader, general gap across the other developer and architect teams at Salesforce. That eventually led to developing an RFC process that they started using internally to run the defining of a set of things for architecture decision records and more general decision records. As Wesley began this journey of educating and enabling all the developer and architect teams around him, he realized that he’d found his niche.
“This iterative step led more and more towards that more org side, and I truly felt there were several things organizationally where there were needs that just weren’t quite getting met, and things fell in between the cracks. There wasn’t someone taking a holistic view of what it meant to be an architect and how to communicate all the value of that ecosystem, and I wanted to be part of that,” shares Wesley.
Today, Wesley focuses on how the few hundred architects at Salesforce could use more support, enablement, and resources to succeed internally. Before starting any enablement projects, he always asks himself: ‘Who knows the valuable information I need right now? Can we find them in this situation quickly? Can we get them to share that in a way that will resonate with the people involved?’
Much like the APIs he used to build, Wesley’s purpose today is to be that connector point between teams, individuals, and projects. Wesley’s organization uses a robust vertical alignment process that allows for good synchronization and understanding if they were to trace upward through their organizational hierarchy.
“There’s definitely a lot of it that involves making connections basically and getting people to learn from each other about what’s going on, what works or what doesn’t work within our organizational context. It’s not a generic leadership book where you’ll be better off if you just read it. It’s coaching, apprenticeship, and continual learning to get it right,” shares Wesley.
A Balancing Act: Balancing the Flavor & Familiarity of Standardization
So, just how does Wesley go about connecting and empowering the architects of Salesforce to produce their best work? It all goes back to a balance of innovation and standardization (much like you’d see in an API design itself).
“I think for a lot of this is a balancing act. I don’t think I should try to innovate or come up with a new idea for every single part of the API, but that doesn’t mean that I can’t do 80-90% of it in a way that seems relatively straightforward/traditional and then try some things around the edges,” shares Wesley.
For example, in the context of the Heroku API that Wesley worked on, his team did some things that were more off the cuff, such as the way they do pagination, which was a ‘quirkier’ way than others would have approached it. Wesley emphasized that you don’t need everything about your API to be new, shiny, or different. Still, it should always go back to user experience and a client development angle first and foremost.
If you’re too ‘out there’ and innovative, the user will be turned off from trying your product or experience. There needs to be a nice balance of familiarity to draw them in but enough new and different innovations to keep them around. That familiarity is better known as consistency and standardization–so that your users know what to expect from you when they consume your API.
“It should be mostly familiar, but there’s a little twist, and in some ways, I think it even helps you to appreciate that twist even more and the difference that you bring to the API space. I learned to strike that balance from consuming a bunch of different APIs and learning how different companies found that balance,” shares Wesley. “I observed which features they did and didn’t emphasize, and what was easy to do and what was harder to do until I was able to produce that same balance in my API creations.”
What helps with enabling his peers around new technology, various team projects, and education of new innovations is drawing from raw, diverse inspiration from different places. Tying it back to his journey through creating style guide standardization–one of the most impactful things for Wesley has been looking at many various Cloud providers to figure out what he liked and didn’t like. He also spent time looking at style guides that weren’t even API style guides to draw inspiration for his work. For him, understanding how to apply concepts from other realms, teams, or similar companies to their own work helped to strike that innovative balance he was looking for. It also helped to get him out of the echo chamber that was his own internal team.
The balancing act for successful API innovation applies to your style guides and governance program as well, not just your actual API creation. You have to find a pattern of consistency for standardization to work well (familiarity), but including a bit of ‘flavor’ (innovation) now and then will help keep your consumers and readers engaged.
For Wesley’s approach to educating and breaking down the silos within his own team of internal peers, he applies those same principles to keep teammates engaged. He is striking a balance between spreading consistency and standardization across the organization while also adding new and fun ways to consume and understand the process at Salesforce.
It was a fantastic time catching up with Wesley and traveling down memory lane. For more insights, subscribe to the API Intersection podcast.
