Keavy McMinn - Senior Principal Engineer at Fastly

This story was recorded in March, 2020. Learn more about Keavy on her blog, Twitter, and Linkedin.

Tell us a little about your current role: your title, the company you work at, and generally what sort of work does your team do?

I’m a senior principal engineer at Fastly. Fastly is an edge cloud platform that provides services like a CDN. I work in OCTO, the Office of the CTO, which is composed of about ten principal or distinguished engineers who report directly to the CTO. Each member of OCTO tends to have their own focus, and mine is being the API Lead.

What does a Staff-plus engineer do at your company? How do you spend your time?

There are several quite different types of principal and distinguished engineers in OCTO. There are also principal engineers that work within engineering teams directly, rather than within OCTO. In the OCTO group, some work on internet standards or academic research, some do deep technical research and prototyping, some help incubate a team building something completely new. I’m closely involved with the broader engineering organization in my API Lead role.

We all work on different things, but we have a common goal of taking a holistic, long-term and system-wide view on things. We also try to find and help with the sort of things across engineering that might get overlooked or fall between the cracks. Our CTO supports our work, but doesn’t identify the projects to work on, that’s up to us.

I’ve never thought about my time in terms of percentages. Some of my work goes in phases, with more of one thing this week, more of that the next. A massive amount of my time is spent doing written work, research, and talking to people. I’ll have regular meetings with the teams and managers that build APIs. I’ll spend time breaking a long-term strategy into little chunks, doing research, and writing a proposal on that. Then I’ll have to market that proposal around the company. Less on writing code lately, but in other phases I’ll build demos or tooling to support the wider work. That coding work is still really enjoyable.

Where do you feel most impactful as a Staff-plus engineer? What’s something you’ve done as a Staff-plus engineer that you wouldn’t have done earlier in your career?

As a regular engineer, it can be hard to carve out time. You have to work more within the constraints and cadence of regularly scheduled projects. As a principal, you have the trust, the time and the space to try something out.

When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others. You’re more respected from the outset, and that’s been really noticeable. You also get access to executives, so you get information earlier and might have a seat at the table to influence things.

Do you spend time advocating for technology, practice, process or architectural change?

I was hired specifically to set the direction for strategy for the API. Part of that is steering the technical direction and choices we make. I approach it as a collaborative exercise. You know I’ll do the grind work of doing the research, I analyse all the information, present tradeoffs, and make a recommendation. I’ll take in all the organizational and engineering group context.

I present what I think is the best case for us, and people can disagree with that. And, you know, they often do. I’m steering and influencing more than saying, “I’ve got the authority to just tell you what to do.” I’ve never seen that style work well.

For controversial decisions, I’ll meet up with representatives from different, relevant groups. I’ll meet with a group of engineers, tell them what I’m going to recommend, and ask “What do y’all think about that? What am I missing?” I’ll also meet with the management and product side, and maybe legal, docs, security or different people depending on the project. I’ve also done it the opposite direction of just presenting the thing first, and then having calls to get feedback instead of just waiting for people to leave a comment in the document.

What’s something you’ve advocated for?

One of the things that I’ve been advocating hard for in my current job is design documents for API changes. So before anybody writes any code, when the cost of making changes is low, they write down the user workflows and what would an interface look like that could enable those workflows. Sometimes it turns out that a seemingly simple thing is really difficult, particularly when the group isn’t used to flexing those muscles.

My approach to advocacy is to remind ourselves what the pain points are that everyone felt that led us to trying to make a change. We’re not trying to be perfect for sake of theory, code beauty, or a lofty concern. I bring it back to “These are the pain points that everybody said they felt, and this is an approach that you know ultimately is going to help with that.”

I help get other people to care about the same things, like I’m going to start pairing with more engineers on API reviews. While I do the reviews, I try to help teach others what I’m looking at, and be encouraging through the processes and conversations.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

This hasn’t been as much of a focus for me in my current role. At GitHub I was conscious that I had privileges from my seniority and tenure, and sponsored an engineer there. I would give him more and more challenging things to work on, encouraged him to question anything that was unclear or curious to him about my work, and advocated for further responsibility and recognition for him.

How did you build organizational trust?

At Fastly, I was given trust from the beginning. When I joined, I was hired to come in and work on specific things. I remember asking, “Is there a time scale for this?” and for their notions about strategy, and being told explicitly that they wanted me to figure it out and tell them. So definitely a lot of trust and responsibility.

There are pros and cons of when you build that trust instead of being hired with it. As you build up trust, you simultaneously build up a lot of context, which is how it worked for me at GitHub. Although, I find in my current job that it was actually really useful to come in without context and be a set of fresh eyes. That makes it easy to question when folks think, “Oh, well, maybe we’ve just always done it this way.” It can be liberating not to be tied to the past.

There is a popular idea that becoming a Staff engineer requires completing a “Staff Project.” Did you have a “Staff Project,” and if so what was it?

I’ve never heard it given a name, but I understand the idea. I did lead and architect that type of project - solving gnarly engineering problems, with large impact for the company - a few times, but unfortunately they didn’t lead to me being promoted. They did lead to my career progression though. Those projects gave me the experience, knowledge and confidence to position myself differently. Even to give public conference talks or know that “I’ve done X and could do X again.”

Were public speaking or public visibility important to reaching your current level?

Yeah, I think it’s been a huge factor for my career development in general. I don’t think it’s necessary, but I think it can definitely be helpful, it’s been helpful for me. My very first conference talk I was asked to do - because the organizers thought I had an interesting perspective to share, coming from an art background. It was terrifying, and initially I wanted to say no. But my mother persuaded me to say yes. So public speaking was a slightly more accidental than deliberate strategy to start with.

Mostly, I enjoyed the people I met at conferences. Later the speaker networks led to job opportunities for me.

How did you first get a Staff or Principal title? What factors contributed most in you reaching that title?

I was hired at Fastly as a Principal Engineer. So, to be honest, for me the biggest factor was changing companies. The type of work I was doing didn’t dramatically change, but changing companies was the thing that ultimately enabled me to get the title.

There was someone that was a strong advocate for hiring me specifically, and I’m sure that helped. They weren’t someone I’d directly worked with before, but they were familiar with my work.

Has working remotely impacted your career trajectory?

Not that I’m aware of. I’ve always been a remote employee and I’m sure it’s been a factor in being able to have serendipitous conversations but I’ve just been doing it so long. You make a deliberate effort to have the conversations and build relationships. Also, my companies have been largely distributed. I can imagine it being more of a potential issue if being remote is the minority, or the company doesn’t fully embrace being distributed.

Did you get any advice on reaching Staff that was particularly helpful for you?

Not really, I got some bad advice. It’s such a cliche, but the “This is great. Now you have to prove it again.” There’s some advice that pushes people more in the sort of hero direction, like saying that you need to invent something unusual or magical to qualify. There are so many different directions one can make it. Engineering ladders often contribute to these beliefs.

What about a piece of advice for someone who has just started as a Staff engineer?

The thing that springs to mind is to find your peers or support network. Just like management, it gets lonely the higher up you go and it’s important to find peers that will still challenge you and you can brainstorm ideas with. It doesn’t even matter if they’re in your similar area of work or even are in different companies.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I tried it once and didn’t have a good experience. I realized it’s just not where my passions lie. I have too much respect for engineering management to do it for anything other than the right reason. The right reason is to support other people.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

Conferences have been a resource for me, as well as getting to work with mature, low-ego, wonderful engineering leaders and engineers. Chad Fowler, and his book The Passionate Programmer, is at top of that list. Dave Thomas is another one of those people whose workshops I used to go to when I was first learning Ruby and his book The Pragmatic Programmer is another great one.

Next chapter: Dan Na - Staff Engineer and Team Lead at Squarespace

Previous chapter: Stories introduction

Book

If you've enjoyed reading the stories and guides on staffeng.com, you might also enjoy Staff Engineer: Leadership beyond the management track, which features many of these guides and stories.