Continuation from Part 1.

Chapter 2: Staff/principal engineering

2022-2024. A new title (L5 / staff engineer) and one of two ICs reporting to the group’s director alongside the other line managers.

This was when I first started to think seriously about developing myself and learning how to operate. “What should I be doing” and “How should I be doing” it were no longer obvious, and I didn’t have clear internal role models to emulate (this was a “me” problem - there were certainly others at GoDaddy in this kind of role! But I am not one who naturally finds and makes connections, especially in a remote role). Two books that I read and recommend to every aspiring IC who wants to move past simply doing engineering work: Staff Engineer: Leadership beyond the management track and The Staff Engineer’s Path. Both of these books were inspirational, were the start of my mindset shift from “I do work on a team” to “I’m an owner of this business, what do I do to make GoDaddy succeed?” Just the start, mind you - I don’t even know if I fully got to that mode of thinking by the end of my tenure there, but I certainly moved along the spectrum.

Anyways, with the role change my operating model changed. I was no longer attached to a specific team, so I floated between projects while trying to learn more about parts of the platform outside of the auth team and connect with other senior engineers. I worked on lots of cool stuff during this time and continued to learn from the talented engineers and leaders in our group, but a few things stand out with lessons to remember:

The Poynt acquisition. GoDaddy acquired the payments and hardware company Poynt to break into the commerce space. I was the lead for the Identity integration, moving all of their users into our system and integrating their entire platform with our authentication model. This was the first really large cross-cutting project I was responsible for architecting and it… did not go very well! Well, maybe. Did I look back at the design decisions made not six months later and have big regrets? Absolutely. Did we launch a couple of months later than the original commitment? Yeah, but what big multi-month company-spanning project doesn’t? Most importantly - we launched, and then we didn’t really need to think about the integration for years again as the commerce org integrated and executed on their plans.

Reflecting on this project afterwards was eye-opening for me. We put a square peg into a round hole (their reseller/user model vs. our reseller model) to accelerate integration, and it led to some ugly code and some less-than-ideal interaction patterns. It was hard to reason about, a special case, and once in a blue moon when a bug surfaced it wasn’t easy for auth team devs to deal with. I had a perpetual backlog item in my personal tracker to prioritize reworking it, but in the 4 following years it never made the bar of worth the time we’d spend doing it. Maybe we could have done it the “right way” from the start, but maybe that would have been 3 extra months of implementation time spanning more teams. That was probably not a tradeoff worth making! Big lessons here:

• Clean code != good business outcomes
• Persisting through challenges and getting a project done is more important to your leaders than getting it done the right way.
• A timely intervention from a senior leader can be motivating. We were in a “rollout/rollback” cycle for a few days around the launch time and the head of commerce got us all in a single call and gave us a motivating speech and we all bug bashed for ~4 hours together. This was effective!

In a similar vein - later on, and somewhat related to the Poynt integration, I was put on the “account-identity split” project. We and others had this big idea: we needed to separate the “account”, the business account with GoDaddy, holding products and subscriptions, from the “identity”, the human user(s) who have access to that account. We had a big “inception”: 3 days of all-day meetings with important (L5+) engineering and product leaders from across the company to map out the implications of this change and what would need to change. It was… big. Changing-every-important-system-at-the-company big. We came up with some clever shim patterns and other things to make it less painful, but there was no getting around the fact that if we wanted to commit to this refactor it would be a monumental effort.

We came out of the inception with a bunch of followups, and as the lead from Identity it was on me to recommend the path forward. The idea was conceptually appealing, a perfect nerd snipe for all of us in the Identity group. It solved problems… if we had it. But we didn’t have it yet, we’d have to invest in building it! I tried to return to the “why”, why did we want to do this in the first place? It all came back to fine-grained multi-user. The new commerce features needed this: invite an employee to work on specific parts of your store, not your whole account. Some tiny fraction of users also operated multiple businesses, which made segmenting them off into accounts owned by a single identity appealing. But it was really multi-user, and I came to the conclusion that this solution was disproportionately complex relative to the value we’d get - and we could get multi-user without upending a domain model with 20 years of business history built on top of it. I wrote this up, convinced my leaders, and the full split project was shelved in favor of building out a Zanzibar-like fine-grained authorization system and a roles layer on top of it.

The final thing that I’ll write about during this time period is my participation and leadership of a “principal engineering council” in my VP’s org. This group was created to give staff/principal engineers a forum to connect across teams outside of specific projects, share knowledge, bring ideas to leadership for prioritization etc… What did we do? Mostly vent about reliability, process annoyances, or whatever else was holding us back. I rotated in the leadership/steward role and tried to make something of it, putting together agendas at the last minute and trying to leave meetings with action items but I can’t say that I was successful. Why was this less-than-successful? Certainly not a lack of engineering talent or even engagement from engineers in the group. Many reasons contribute, but I’d boil it down to this: A group who’s main continuing deliverable is “meet once a month and talk” is not going to do much more than meet and talk! If I was an engineering leader setting up a group like this now, I would ensure that one or both of the following were true:

• The group has real key results and deliverables. These can and should change regularly, but there has to be a driving force towards action
• The group has a steward that is focused on bringing discussion, and turning discussion into key results with accountability. This will be a non-trivial responsibility for someone that takes at least 10-20% of their time depending on the scale of the group. Both of these bend the shape of the group towards action and results, not just discussion. Talking, venting, brainstorming is valuable, and maybe a forum for that is valuable in and of itself, but it is likely not worth a recurring monthly meeting on valuable engineers calendars. Get something done!

That’s all for now. Next up: Management!