Why Not Both…The VPE as the Player and the Coach

June 2023 - Seedling Edition 5

Every now and then I look at my Audible and Kindle libraries to see what I’ve been reading over the last 6 to 12 months. Since the pandemic, I’ve probably indexed harder on my Audible subscription. I think I listen to 80% of the books I work through. 

I had a bit of a panic attack when I noticed that nearly all of the books I read in the last year were product management theory, organizational behavior (business management) and engineering leadership. There were a few biographies and personal success books sprinkled into a collection. All in all there were 22 books on Audible, 6 on the Kindle and 5 soft cover books of these various leadership, management and theory books. I guess my 80% metric is a little off. 

What was missing?

For the first time in a long time, I didn’t read a single system or software architecture book. There were no books on software patterns, performance, scalability or security. Heck, there wasn’t even a single reference to observability, monitoring or testing. 

It’s not like there haven’t been any books published in the last 24 months on any of these topics. A quick scan in Amazon and you will see many dozens of titles pop up. So why didn’t I read any of them? It’s not like I didn’t purchase one. In fact, sitting no less than 20 inches from my keyboard is Modern Software Engineering by David Farley.

Needless to say, I put this Substack post aside for 20 minutes and read chapter 1 and 2. I will definitely finish this one before the end of the week. 

To be fair, I’m not really sure why I hadn’t been reading certain genres of technology books. I know from a work perspective, I’ve been hyper-focused this past year driving my team to be more outcomes focused. My engineering organization was actively implementing Team Topologies at scale. I personally was doing what I could to expand on my knowledge of product management theory. I've also fascinated with the cognitive and psychological side of building high-performing engineering teams. These are all valid topics and I very much enjoyed the books I listened to and read on the topics. 

I went through a similar exercise in my podcast library. It turns out, I haven’t invested much time listening to as many architectural, security and software podcasts like I had in the past either. 

So I decided to perform a third search, which is/was my Medium and Substack subscriptions. Phew…I found a ton of articles I had read. I haven’t felt like my engineering/technical skills have become stale. However, I noticed I spent most of my time last year focusing on Generative AI, Data Engineering and Kubernetes. All are reasonable topics. They all happen to be on the cusp of a lot of engineer's minds these days.

So why am I bringing all of this up?

Recently I was engaged in an architectural discussion with a colleague. We were talking about patterns for securing Microservices. It’s not a really complex topic when you think of it. I found myself overthinking the API design of the service, observability, the software composition and makeup and then of course things like input validation. Things that I would normally cover like authentication, authorization, logging and encryption were far from my mind. I couldn’t initially put my finger on why my mind was so far from those topics.

Let’s start with the journey many of us go through in our engineering careers. We predominantly start off as software engineers and programmers alike. We may specialize in a given area like architecture, performance, security, infrastructure/cloud, frontend, backend or data engineering. At some point, we decide to move career tracks from individual contributors to managers. Topics like authentication, authorization, logging and encryption are omnipresent in our day to day lives as software engineers. They are part of the cost of doing business. At some point you start to view these problems/topics as a commodity. 

Now some engineers become managers because it is a pathway for promotion, growth and compensation. Ideally, most become managers because they have a passion for leadership, growing others and driving the outcomes of the business. 

In my career, I have been more focused on the latter. I could have stayed in an IC role and experienced promotion, growth and compensation improvements. I purposely went the management track because I believe in the mission of the role. I have made sure to stay close to the code. I engage in common architectural discourse with my team. 

Ultimately, what I’ve realized is that so much of my learning over the past 12 to 24 months have either been topics that I have deep interest in or are technology problems that I have less history and exposure to. That’s not necessarily a problem, but what it means is that I’m not challenging my point of view for technology areas that I have vast previous experience in. This my readers is something that I’ve done throughout my career and has shaped my career. 

The VPE is not the Chief Architect

When I was a younger leader, I was ignorant enough to believe that being the smartest person in the room was critical. I wanted to influence and shape all technical decisions. I wanted to get credit for solutioning the idea.

Then I met my office mate and teammate at Blackboard, Bob Alcorn. He was our Chief Architect for most of the time we worked together. Over 10 years we shared an office for at least 4 of those years together. We were often in meetings together. It was clear that Bob was the smartest person in the room most of the time. 

Bob is/was good at something that I wasn’t. He was good at getting others to solve problems together. He got others to be more willing to present their ideas and work towards a common good. It’s a lifelong skill I’ve been working on since I first met Bob back in 2003.

What Bob taught me is that even with the title of Chief Architect, the best leaders don’t die on the hill for their ideas to be accepted. They work with others to solicit, incubate and discuss ideas. They check their egos at the door. They realize there are many ways to solve a problem.

Often when I’m in technical discussions or white board sessions with staff, I observe that team members will defer to my ideas or points. Sometimes it’s out of unnecessary fear, but often it’s because of HIPPO (Highest Paid Person's Opinion). 

Your job as the VPE is to get the most out of your team in the most efficient, economical and empathetic way. You need to be strong technically too. Good VPEs are really good at being generalists. They think about all of the “ilities” like (scalability, security, performance, reliability, availability, accessibility, maintainability, reusability) as well as other meta topics like cost and impact.

The VPE Should Stay Current and Up to Date

I had mentioned authentication above. A good example of staying current is following trends and shifts in the industry. When I was thinking about authentication, I was initially considering a combination of API Gateway and Token-Based Authentication set of authentication security patterns. Both are simple, common and quite possibly the easiest to implement. 

What I wasn’t thinking about were authentication patterns like MTLS or a Service Mesh. The latter is one of the more hot to trot topics in both the Serverless and Microservices world because of more granular control with enforcing hardened security policies. There are advantages with a service mesh like improved logging, observability and traceability, which at the end of the day makes it easier to do forensic analysis and debugging. 

These are all things I know. These are all things I value. These are all things that are so obvious. Oh and by the way, service mesh authentication has been around for quite some time. I’ve known about service mesh capabilities for a while. It hasn’t ascended to my top of mind. 

It’s an example of when as a VPE you have to stay current on the evolution of solved problems. The engineer in me deferred to simple solutions like using an API Gateway and Token service because they are common, simple, inexpensive and performant. The complexity of tradeoff for a service mesh sidecar for many organizations is worth the gain in fine grain controls, security policies and secure communication. As teams think more clearly about security governance, you will see more teams move away from secure patterns like implementing API gateways, Tokens and MTLS (certificates) on their own, whereas a sidecar proxy can extend MTLS as part of the deployment.

Let’s Wrap It Up

Today’s post was about a big aha moment. It was a reminder that learning takes lots of forms and directions. I was doing the right thing by exploring new topics and areas of unfamiliarity. I was also doing myself a disservice by not challenging my prior knowledge on a given topic. In today’s case, it was the topic of advancements and adoption in secure communication patterns for Microservices. My best advice is stay current and fresh.

Maybe it’s not a disservice. I shouldn’t beat myself up so much. If anything, it was a good reminder to not neglect the things you know well from the past. Try not to take previous learnings for granted. Don’t assume since there hasn’t been a lot of industry noise about a topic that there hasn’t been advancements. It could be that you aren’t in the right listening circles or the folks in your network aren’t talking about a given topic even though they are re-engaging on a topic.

I titled today’s post “Why Not Both…The VPE as the Player and the Coach” and there was a reason for it. I didn’t truly comprehend it until deep into my writing. From a technical perspective, we tend to make recommendations where we have the most learnings and experience. The farther we are removed from the day to day, the harder it is on us to stay up to date, as well as have confidence on a given topic. 

We have a responsibility as VPEs to be engaged not just with leadership and the human side of our job. We have an accountability and ideally an intellectual curiosity to continue to evolve our technical skills. It’s in our best interest to stay current and informed. 

As I mentioned above, I have a series of Medium Topics I follow, as well as a collection of Substack’s that I subscribe to. I also have some newsletters that I receive via email on given topics like DevOps, CI/CD, OWASP, developer tooling and AWS Services. I try to go to a few conferences a year like ReInvent, DevOps Days, Monitorama to name a few. If I can watch replays on a given conference like KubeCon, RSA or Enterprise DevOps I jump at the opportunity. 

I follow 100s of developers and technologists on Twitter. Though sadly, a lot of folks have abandoned the platform over the past year or have minimized their usage. I find myself scrolling the various awesome lists in GitHub, which I strongly recommend folks do. Very recently, I’ve found myself watching various YouTube channels like System Design Fight Club, This is My Architecture and Byte By Byte thanks to a few of my teammates who suggested I give them a whirl.