Office Hours: Conversations about Engineering Management
Jesse Kipp, Engineering Manager at Cloudflare, will interview other engineering managers about leading successful teams. In this segment John Fawcett joins to discuss the transition from individual contributor to engineering manager.
Hello, thank you for tuning in to Cloudflare TV. Today we've got John Fawcett on video here and we're going to talk about engineering management and engineering management at Cloudflare and John is an engineering manager here at Cloudflare who works on our marketing engineering team and John can you start us off by telling us a little bit about yourself and your team and what your team is responsible for.
Sure, sure, sure. So like Jesse said, I'm John the engineering manager for the marketing engineering team and that means I'm an internal tools team and my customer is actually the marketing department.
In the marketing department they have a lot of asks, you know, they want instant updates on the website whenever they change things in the CMS, they want fast turnaround on new pages, internationalization, personalization, analytics and generally easy content management.
So effectively, our team keeps the lights on for Cloudflare.com and personally we're always just trying to make Cloudflare.com better, faster, lighter, more maintainable, secure and beautiful, generally more excellent.
But yeah, that's what we do in a nutshell.
We control Cloudflare's marketing properties like the blog and open for business, built for this.net and so on.
All right, so you are fairly new to being an engineering manager, I think about six months now, is that right?
Nine months actually. Nine months, okay. So tell me a little bit about how that transition, when it came about from an individual contributor to a management role.
Well, I had been working at Cloudflare for about three and a half years in product strategy and it was super fun to move from product to product, from AMP to workers to registrar and I got to consult teams on like how to best set up their UIs and stuff.
It was a really good time but after a long while with registrar, I kind of felt like I needed something new and I wasn't really being challenged enough.
I needed to really, I knew I needed to just go off and do something that was completely uncomfortable for me.
And yeah, so I mentioned to my boss in our one-on-one that I was looking to do something different and he had mentioned this role opening up on the marketing engineering team for engineering manager.
And I thought, well, hey, that's the only team at Cloudflare that does Node.js.
Maybe that's a good fit for me. I can help coach people on things that I actually know about.
So I took the job, I interviewed and I got it and immediately I was, like I knew that I was supposed to stop doing IC work and I tried really hard not to but I think to this day, it remains a hard thing for me to not do is take a step back and really just let my team solve the problems and let me be the umbrella that blocks them from the rest of the distractions and just really just helps them move forward and be an unblocker.
Okay, so what does a typical day look like for you?
Well, generally when I log on, there is a bunch of unread messages in chat.
I've got a triage, any potential issues that have occurred in the Cloudflare.com that people are talking about, say in the marketing room or the everyone channel.
I've got to check my email and go through a whole page worth of unread emails and then also I've got a number of like JIRA subscriptions that I keep track of the daily goings-ons of my group.
Just triaging new tickets that come in and yeah, just trying to continue the work from the day before.
Sometimes I'll be doing some IC work myself, but mostly my day-to-day is triaging tickets and coaching other people like new members of the team, for instance.
Also, meeting with various stakeholders. You said my calendar looks scary.
It is. It's a lot of meeting with people, so it's good stuff. How does your team organize work?
Do you do sprints? Do you do Kanban? Is it just total chaos? Yeah, we operate in two sprints.
I inherited this from the previous EM. I didn't want to do a whole lot of changing up of the processes if something was working.
We operate in two weeks sprints. I actually work with a program manager named Susie Bates, who helps keep our backlog just fresh and gets the requests for marketing and makes sure that they are solid requests.
She keeps everything organized for us. I think that's sort of a unique thing for our group is that most people don't really have this project manager style person that helps keep our backlog groomed.
We do Kanban, sort of.
We use story points to try to estimate work. Day-to-day, an engineer is going to have sort of a bigger ticket item that they'll be working on for the entire sprint, plus a lot of smaller items, bugs, or small tasks that come through.
Cool. You mentioned having trouble taking a step back from doing individual contributor work now that you're a manager.
I remember going through that, too.
I think most managers who come up through the technical path end up having that experience when they first start.
What brings your awareness to a situation in which you need to take a step back and figure out how to help your team do something as opposed to do it yourself?
I guess it's just really I shouldn't be doing any, so every time that I do, I simultaneously feel guilty about it.
It's like the amount of work that my team is being asked to do is more than we currently have resources for.
It feels like an imperative for me to actually do IC work, but I think my time would be better spent writing specs.
I do this IC work, and then I get I feel guilty because I haven't worked on a spec that I was supposed to have written already.
It's moments like that where I'm like, well, crap.
In the moment, it feels like the thing that would help your team get work done on time is to do some individual contributor coding, but in the long term, what actually helps your team get more stuff done is laying the work out for other people to get it done.
Not only that, just thinking of ways that we can become more productive.
We're in an interesting position in the company where we're not working on just a product, and we don't have a product manager in the traditional sense either.
We have a number of marketers that have a channel to our team, and they have goals that they want to accomplish, and we have to figure out how to accomplish those, help them accomplish those if they have a dependency on us.
I've been thinking a lot about how we can become more productive as a team and get more of the marketing requests done, but we really have to take a step back and think about things from a holistic perspective and a strategic perspective and really change the way that we're doing things.
If we just stay on course, we're going to be productive.
We're going to do the day-to-day things. We're going to basically satisfy the status quo, but we really need somebody to take a step back and re-envision a lot of processes and re -envision how the relationship between engineering and marketing operates.
We need somebody that is in the know enough to be able to write it down and with enough authority to actually execute on some of that stuff.
Very fortunately, that is me. I could definitely be doing all those things, but at the same time, well, actually, I had a conversation with the head of marketing, and I was like, hey, we're operating a little too hot right now.
Cloudflare.com may just go down at any moment. I'm scared of that. We need to take a step back and re-evaluate the work that we're doing.
I said, it's like we're fixing a car while we're moving it.
He says, so you want to stop the car for a while and work on it?
I'm like, yes, but you can't. You can't just stop the car. We've got a certain velocity that we have to maintain.
While I do want to take a step back and re-envision these processes and make my team way more productive in the process, we have to do the day-to-day stuff still.
What's a change you've put into place since coming on board to help your team be more productive?
Yeah, well, the first was a really obvious change for anybody who's been involved in this space.
So, the tech stack that we were using to build Cloudflare.com was, it's a response to the changing requirements over time.
I did a talk for Engineering Presents about the reinvention of Cloudflare.com every couple of years.
I take us through going from cfwww, completely PHP-based marketing site, to Jekyll, to Node.js, now back to Gatsby for a static site again.
When your devs are working in an environment that is behind on the latest, I guess, best practices, it doesn't feel good to work there.
You don't feel excited about the tools that you're using whenever they're the latest and greatest of eight years ago on web tech, right?
So, just getting things updated and simpler has been a help to dev productivity, I think.
That was sort of my first goal. Did you do all the properties that you cover at once for that?
Oh, I wish. Yeah, I mean, there is a unifying thread there.
There's a vague idea of getting the blog, getting Cloudflare.com, and all of our little micro sites, all living under one tech umbrella, rather than being spread out in different repos, different technologies, different deployment strategies.
I mean, Cloudflare.com is deployed with two Kubernetes clusters, right?
One in the United States, one in the EU, whereas the blog is just like, there's no coop cuddle.
It's just like, oh, yeah, here's a Docker image.
Use Terraform to tell GCP to use this new image. And there's vastly, there's a big disconnect there between those two things.
If we ever have to make updates to the blog, it's this process that none of us quite understand all the way.
But there is this idea that you can unify all of your tech under one sort of concept.
And I think that concept is actually going to be a static site, Gatsby, hosted on workers, and driven by content that is in our CMS contentful.
And those three things can get us really, really far.
So I'm working with our brand design team to create a set of primitives that can be reused across all properties.
And that's something that I need to write a spec for.
All right. So let's change course here a little bit.
So when we've all started working from home, now about six months ago, at this point, and how have you changed how you and your team works in response to the COVID-19 outbreak?
You know, I took this job, and I asked Usman, I was like, is it going to be a problem that I'm the only employee on this team, the engineering team that is based out of Austin?
And he's like, Hmm, you're gonna have to visit San Francisco probably a couple times a month.
So before COVID, we were already a remote team, essentially, the engineers were in San Francisco, and the manager was in Austin.
So we already kind of had to figure out how remote work would work for us.
But the one thing that did change is now I just don't get any face time.
I was going to San Francisco twice a month. And yeah, thank God, Alaska Airlines is extending my, my MVP status another year, just because of COVID.
No, I'm just kidding. So I think the biggest thing that's changed is the complete lack of face time, whereas before we got it twice a month.
Now we just get it no times.
So how do you keep connected with your team?
Yeah, so pre COVID, we had this little micro incident.
And I forget what it was, like, maybe clubstore.com was was going down or something.
But we all hopped on a call. And I was in the Austin office, and they were in San Francisco office.
And we just, we just troubleshoot the thing on the call for 45 minutes.
And as a new manager, who, you know, doesn't, who's, you know, managing stuff through chat, and like ad hoc meetings, I was thinking, this is great.
Like, this was really fun to hop on a call with you guys and just do some work.
We should do this every day. So we started the daily jam. And so I mean, we were already sort of operating like that, before COVID.
But the daily jam, I feel like really took off during COVID.
So it's an optional meeting for all my engineers, they usually show up for the full hour.
It's from four to 5pm for me, so two to two to 3pm for them.
Just like sort of like end of day. And we all get together and and talk about any issues we might be having.
We talk about just random stuff that it keeps us keeps us friends, right.
And it, I feel like it instills a sense of camaraderie that is necessary on a team.
We also started opening up to other teams, like the brand design folks.
So you know, as you can imagine, we work pretty closely with designers.
So it's really great to have our designers come in and just hang out with us to have a relationship to make it so we're, you know, we're actually a face behind the jiras that that get moved across the board, right.
So the daily jam has been really, really awesome. And highly recommend it for anyone that as a manager have have an hour long, no purpose meeting with all your all your ICS and invite other people as well.
But just sit there and do your job like normal.
Do you all ever do any coding during the jams? Oh, yeah, yeah.
That's one of my favorite things is to, I mean, basically every single jam, multiple people will have questions about coding doing some best practice or, you know, Mark will will come in like, Hey, I've got a TypeScript question, or we've got one of the brand designers that come in and like, Hey, I have an HTML and CSS question to share your screen.
A lot of times, I may be working doing some IC work.
And I'll just I'll just live share my editor and just just do sort of like a I guess, like a streaming thing where I'm just coding, not really asking any questions.
But then if somebody asks a question, then I'll stop. So you have an hour in a day where you just make your team watch you code?
No. Yeah, so yeah, one of the things I found during the COVID crisis is that the more I up my game at writing specs, and in particular writing requirements, the smoother things go as well.
That's been one of my big changes during the COVID. I'm glad you've come to that because I need I need to get there.
I need to get to the point to where like, the majority of my my job is writing specs.
I feel like I could do so much more if that were the case.
You've hired some people who will be in the Austin office though, when we return to office?
Yeah, yeah. She she just started two weeks ago. Well, got done with orientation two weeks ago.
Cool. So what is something that surprised you about becoming a manager?
Yeah. I would say the number of people that are vying for my attention.
And it's not just like my team members, or, or people related to my team members.
It's just like, all of marketing. They're like, hey, that guy's that guy's in charge of that team.
Now, let's let's ask him if we can do this thing or how feasible this is.
Or let's, let's schedule recurring one on ones with with john so that you know, maybe maybe we can build a relationship and get my work done faster than other people.
That's remarkable, because my impression of you before you became a manager was you were already a pretty in demand person.
But at least it was scoped to like a particular thing. I feel like in marketing, it's, you know, there's obviously a lot of different goals to increase the revenue of Cloudflare.
A lot of different stakeholders there. But a lot of them have engineering dependencies.
So it's, it's just a lot to keep in your head.
And at least when I was in product strategy, too, it was I would, I would consult with other groups.
But I knew their products. It was it was a lot easier to for me to grok because I was like, Oh, yeah, I know what Argo tunnel does.
Or like, I understand what stream is doing, like, I know their exact needs in the UI.
But, you know, when, when I get a request to help increase pay as you go, pay as you go leads by 15%.
And, you know, there's a bit of a disconnect, right? Like, I know Cloudflare.com is a product, but the marketing strategies, I I don't know as as deeply.
What's something that you feel like you so you said you at the beginning, you said you decided to you said learning something new is a big part of what?
What led you to being a manager?
What's something? What do you feel like you've been learning? As you?
Yeah, on this journey? So I, when I when I said I wanted to be an engineering manager, I wanted to be the kind of so okay, Cloudflare, I've seen two types of managers, there's the the kind, it's like very much people person, they tend to do all the things a manager is like actually supposed to do.
They're on top of one on ones, they're on top of like career growth, they, they generally just, you know, they grow their team to have lots of ICS on their team.
And they they don't do any technical work themselves, usually.
And then there's the manager that is very much involved in the day to day.
They're a high level IC on the team. And they're managing some of the aspects of being a manager.
And I thought I wanted to be the latter.
And so I learned that that is actually not a good, good way to manage a team, especially the team that I'm on.
So it would be better if I were to just grow my team, handle all the aspects of the team that are not technical.
This is, you know, this is really just about creating process and organization, making sure my my team members are, are working on things that they're strong at, and things that actually give them fulfillment.
And communicating with stakeholders and stuff and is unblocking where I can.
So that's one thing I learned is that like the the hybrid style of manager is probably not right.
For this team, at least. Other things I learned are that one on ones are actually really powerful.
Previously, I didn't really have a I didn't really care for one on ones, I found them kind of awkward.
And I was just kind of itching to just get out of them. As soon as I went in, as a individual contributor, when you were meeting with your manager.
Yeah, yeah, yeah. And I think that's just because I didn't, I didn't realize what they were for.
But now as a manager, you know, I, I don't, I don't have a one on one unless I have.
Well, that's not necessarily true. I always have an agenda for my one on ones, I always have some things that I want to talk about.
And I always take notes. And I keep track of everything that we've talked about in our one on ones.
That way, I can just be a good person and follow up about stuff.
If one of my ICS is having trouble because of, you know, their apartment situation, or immigration or something, I may not be able to do a lot about those particular things.
But at least I'm aware, and I've got like a record of it so that I don't forget about like what's going on in my, my team's life.
So I don't know, I find one on ones incredibly helpful for me.
And I hope my team, you know, finds value out of it as well. That I will figure out soon.
I'm also learned a bit, a lot more about the Cloudflare capabilities.
Whenever, whenever the people team first showed us the Cloudflare capabilities matrix as an IC, I was like, it was kind of nerve wracking.
I was like, wow, I'm, I'm not good at any of this stuff.
I don't, I don't deserve to work here.
But I didn't have a very high opinion of the usefulness of that rubric. And now as a manager, it's, it's a really great tool to just tell my, my ICs like, hey, these are like really tangible things that you can do to improve.
And it's not just about like checking these boxes or anything.
It's more like, there are particular trails you can go down.
And, you know, these, this is this is the company telling us how to get better.
It's actually really good guidance. And I appreciate it.
So as you've gone through this transition from being an individual to a contributor to a manager, what resources have helped you learn and develop?
Yeah. So before I took the job, I set, I set one on ones with almost all the engineering managers that I knew.
And I tried to get like advice from them on how to be a good engineering manager and what they thought were the challenges.
And I talked with Alex Vidal, who was a former EM and he went back to being an IC.
I talked to James Colbyhouse, who was the EM for the UI platform team.
Now he's back as an IC. Talked to Ian Spivey and Eric Reeves.
I talked to Larry Archer, who was just about to become an EM around the same time.
And I feel like they just gave me a lot of confidence that I could actually do the job.
They told me a lot of great things. I learned from Eric Reeves to, to try to like funnel as much as you can into JIRA and, and make, make subscriptions to search filters, bucket your time every day to, to go through those, those filters or those subscriptions.
Ian Spivey, you know, told me the power of the one-on-ones and to really, really like make sure you keep up with that.
And reading a lot of David Kitchen's articles on, on wiki about sprint planning and velocity has, has always, has been really helpful.
But I think a really big help has been the EM forum.
I don't know if you've been going to those EM forums, but it's just, it's cool to hear other people's stories about engineering management.
All right. We have just about one minute left. So my last question, are you hiring?
I am not, but I hope to be soon. As I said before, I, you know, I, I think, I think we need more on our team.
So I'm going to fight for some more headcount.
All right. Well, thank you, John Fawcett for taking the time to talk to us today.
And if you're watching and interested in working with John, you can keep a lookout for roles posted online at Cloudflare.com.
Hopefully he'll have a position open.
Right on. Thanks, Jesse. All right. Bye.