Ben Edmunds (Wayfair)
During today’s conversation, we speak with Ben Edmunds, Senior Staff Engineer at Wayfair. You’ll hear all about his role at Wayfair, from his day-to-day active projects and how he goes about setting OKRs to the legacy and new deploy tooling he uses, and the method he has adopted to guide engineers. Ben shares ample advice for young engineers and stresses the value of learning more than one coding language. He reveals the finer details of life at Wayfair and the tools he uses to make sure that goals are reached, which include surveys, direct conversation, and partnership. We talk about the role of auxiliary engineering, the templates engineers build for application in partnership with an engineering team, and Ben points listeners in the direction of topics they should research, depending on whether they are looking to improve their software engineering or technical leadership skills. We hope you join us for an action-packed episode today!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that sets staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romas and I’m joined by my co host, Alex Kessinger. We’re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Sure. Today’s guest is Ben Edmonds. Ben is a senior staff engineer at Wayfair where he works on the platform team. I appreciated Ben’s take on influence over authority. So let’s get into it.
David: All right, Ben, well, thank you so much for taking the time to chat with us today. We’re really looking forward to it. If you could start by just kind of telling us who you are and what you do.
Ben: Yeah, thanks for having me. I’m Ben Edmonds. I’m a staff engineer at Wayfair. Yeah, so I mostly edit YAML and talk on Zoom most of the day, but every now and then there’s something more interesting.
David: How would you sort of describe your day to day? I mean, beyond editing Animal?
Ben: Yeah, it depends a lot on kind of what the currently active projects are right now. Leading a project to decompose our monolith. We have a older legacy PHP monolith that’s grown rather large, and we’ve had an effort for the past couple years to move people to decoupled applications and a newer ecosystem. And now we’re at the stage where we’re trying to really target getting rid of that monolith instead of just letting people kind of naturally migrate away. And so with that, I’m coordinating across a lot of teams, a lot of trying to source interesting projects that will help the effort or convince people to work on the project. So as a engineer, it’s a lot of convincing and getting people excited more than telling them what to do.
Alex: Interesting. When you say YAML, I’m curious, does that mean that you feel like you work more on the infrastructure side of things or the application side, or do you sort of like, straddle the divide?
Ben: Yeah, it’s a joke. We say because I’m in a developer platforms department. Right. And so a lot of our day is abstractions on top of abstractions to help people deploy or work with infra in some way. And so a lot of infra now is ran on YAML Configs and you know, love it or hate it, it’s kind of the world we live in.
Alex: Yeah, for sure.
Ben: It gets torn, you know, some weeks I’ll code a bit, other weeks I don’t code at all.
Alex: Interesting. So would it be safe to say that you sort of build products for engineers in your. In your organization?
Ben: Yeah, yeah, definitely. So I’m on the PHP platforms team. We support the. I think we have about 1200 php engineers and then we’re inside the developer platforms and we have over 3,000 engineers total. And so we’re building tooling and systems for those engineers to use to make them more efficient and productive.
Alex: Is there a typical approach to being a staff engineer in your organization?
Ben: I wouldn’t say so really. It really depends on your department and your team. We have competencies that we kind of align against in general Wayfair. And a lot of that is where your scope of influence is. So as a staff engineer, you’re expected to influence multiple teams working towards your department’s goals. And then as you go up the chain like a principal engineer, you’re expected to influence the whole company. Right. And so a lot of it’s based on that. And the day to day can change a lot based on the team and the projects. Really whatever’s the most leverage towards that scope. Cool.
Alex: And do you feel like, are there any particular qualities of how you approach staff engineering? Like. Like when you moved from, you know, being more code for focused to being staff engineer, you know, what did you find striking about being, you know, the role being different? I guess.
Ben: Yeah. I’d say it’s a interesting challenge in like resetting your expectations for what a productive day is. Right. So before it was pretty easy. You get that dopamine hit of shipping something cool or how many commits you have or how many tickets you closed or whatever. So staff engineering, it’s really more about how can you make other people more productive or help their goals along. How can you unblock people? And so the goals change. But I do like that the kind of. The influence changes. Right. You can get more things done. Maybe you’re just not as deep into any one thing. Yeah.
Alex: When it comes to influencing other engineers, how do you feel like staff engineer is special in that regard? If any engineer could talk to any engineer, you know, they might have influence. But how do you feel like staff engineers use their influence specifically?
Ben: Really? I guess you’re trying to use that influence for a broader problem. A lot of times that problem is something the engineer cares about, but not always. Right. And so you have to find a way to make that problem interesting to them or how does that problem help them in a certain way. And you have to really just like find the people that need the thing that would like to work on the thing and help them do that. A lot of times they don’t even know about it yet, especially as a platforms team. Right. Like we’re building a lot of things and you know, there’ll be tons of engineers just don’t know about the things yet. And you can send out all the releases you want and they might not see it. So a certain part of it is really connecting people.
David: That makes sense. I’m curious to sort of pin this back to some concrete projects just as examples for folks to keep in their head as we’re, as we kind of continue to talk through abstractions. So one project you mentioned is, I think you said untangling the monorepo or was it decoupling the monolith? I think oftentimes those happen at the same time. Can you, if you’re comfortable giving more details on that project or if there’s sort of another project that, that would make a better example. But I’m curious to sort of know more about projects that are cross cutting and where you’ve sort of had to, had to coordinate with a lot of different stakeholders to make it happen.
Ben: Yeah, sure, I can get a couple. One other example is we build templates for applications, right. So I want to generate a new application and so I want to start with all these things that automatically work with our intro. The mistake a lot of platforms teams make is just kind of making that in a silo and then pushing that out for people to use. What we really try to do is partner with an engineering team that’s already doing something in that space. And so like last year I was working on a new template for Kafka and so we partnered with an engineering team that was working with Kafka a lot. And we worked very closely with them. I worked with them to build out that template, to test it with their teams. And then we published that for more teams to use. That’s one way we work with other teams. But at the same time we’re accomplishing our goals of shipping a template for more people to use. If we weren’t involved in that mix, maybe that team would have built a template, but it would probably only stay inside their org or their pot of teams. It probably wouldn’t go out to the rest of the engineering org.
David: And in that example, once the template is available. What’s the process for driving adoption?
Ben: A lot of it. We go for organic adoption. We try to follow the diffusion of innovations model, which means you can have early adopters and then you go through a cycle until eventually you get the adoption you’re going to get. Different things call for different amounts of us driving that. Right. Like the Kafka template. It’s kind of, if you need it, it’s there for you to use. We have the central location you can go to build new applications and you’ll have it as an option there. There’s not much we need to drive that for the other project dimension, like the monolith, there is a lot of driving of that. It’s a lot of convincing teams that they should do a thing and then helping them be successful doing the thing. And it’s a big problem. So I kind of bash my head against the desk sometimes trying to figure out what the next step is for that. I’ve been describing it as like, it’s a Gordian knot. And so I’m just pulling threads all day. I don’t exactly know which thread’s going to lead to a bigger section of the knot coming undone. And that’s what a lot of it is.
David: Yeah. You mentioned the diffusion of innovation model, and I think oftentimes that’s, you know, that makes sense. And that’s the. That’s sort of the only thing past a certain scale. That’s sort of the only option that works inside organizations. But drawback that I’ve observed with that approach is that you can end up having sort of lots of different versions of the thing in use at the same time. Because, you know, you’ve got. You got some early adopters and you’ve got some late adopters, and they’re all kind of using different versions of the thing that you’re trying to improve. Have you faced that? And like, is that just sort of the cost of doing business in your mind, or do you have sort of some thoughts around how to mitigate that?
Ben: Yeah, we’re still figuring that out in a lot of ways. So we’ve been very much a growth company and we’ve gotten larger and larger. Right. So that problem became bigger in probably the last year or two than it was previously. Right now we’re doing a lot of work to automate the process just to make it easy to do the right thing. So if you’re on an outdated version, you’ll get an automated PR that upgrade you to the latest version of the thing. You’ll probably get a notification via Slack or email that tells you to upgrade the thing. And we’re just trying to really make that just easy to do. And then we are starting to define some rules for, like, for this subset of things like, say, Docker images. We’ll support two versions back or X versions back, just to gain a little control over that.
Alex: Interesting. So I feel like you’ve talked about this a few times, or we’ve touched on it, like, sort of like making it easy to do the right thing. You talked about a Gordian knot. You talked about, you know, you want to. The diffusion model. All of these things feel a little amorphous. They’re not like one plus one equals two, or like, I can’t judge my success by how many PRs I’ve submitted and stuff like that. So I’m sort of curious, in that sort of amorphous space, how are you making sure that the work that you do is aligned with your organizational goals?
Ben: Right. That’s a great question. And I guess it differs. So we’re in a process right now where we go through every six months and we kind of evaluate what our department’s goals are, and then we feed that down to teams and we set goals against that. So we use OKRs on my team. Different teams and Wayfair use different things, though. And so we’ll set okrs that say, you know, we want to drive. Let’s say we’re driving adoption of a template. We would say we want 10% of users, for example, to be using that template. And then throughout that quarter, we would have projects that target that. So one project might be some kind of automated system to move people from their old thing to the new template. And then we would track our progress against that. A lot of times that doesn’t work. Right. And so that’s. That’s where the data is helpful. So we might say, oh, well, we’ve only got 5% of users, and we’re not really ticking up from there. That means either our goals are bad, you know, we need to rethink it, or it means that we need a new approach towards that goal. So we might throw out a new project that tries to tackle it in a different way.
Alex: Interesting. So in an example like that, where you set a 10% goal, is that a moment where you might say, why do the engineers not? Or, how could I make this something that an engineer would find more valuable? What’s interesting is that sometimes it feels like our goals are pretty static or number driven. But the model, by which we achieve our goals is super amorphous. How much do you think about a developer, the value the developer sees from the things that you build as the means to achieve your goals?
Ben: Yeah, that’s almost the only means. Right. We have a very strong culture. We don’t tell people what to do. For the most part, engineers have full autonomy to choose their tools in their stack. So as a platforms team, if our tools aren’t the best tools, they’ll just use something else. And they’re free to do that most all they want as long as it works in our infrastructure. So that’s really the ultimate goal. We have a few tools for that. We have surveys, we have talking to people directly. We have the partnership aspect. Then one other thing we do a lot is called auxiliary engineering. And so that’s where we’ll take an engineer, we’ll embed them on a team that’s doing a thing, and they’ll work with that team for maybe a quarter or set engagement to make that thing. Right. So we’re saying templates. They’re making a new app using that template. We would embed, embed an engineer on that team to work on that new app. And then that gives us a ton of feedback that we wouldn’t usually get because you’re actually in the weeds working with them on that thing. And then they will come back to us and we’ll take all that feedback and use that to feed our next approach.
Alex: That’s cool. Have you ever been in a situation where your team has identified that some set of tools or some infrastructure is continually delivering less than awesome outcomes? You would really love to help people use a new kind of infrastructure. How do you close that gap between, if anyone can choose anything, how do you help make sure that folks are using the best stuff or the stuff that produces the best outcomes?
Ben: Yeah, a lot of it goes back to making it easy to use those best things and then if they’re good enough, people will migrate there. Right. So like deploy tooling, for example, we have some legacy deploy tooling, as most companies do. We have newer deploy tooling. The newer deploy tooling obviously saves you time. We have data on the velocity it gains to teams. Right. And so just by making sure we’re publishing that information, keeping out there about how much better this new deploy tooling makes your life, teams migrate more and more and then it’s a snowball effect. Right. So you get the first several teams to use the thing and if they’re finding value from it, they tell other people about it. Then the snowball continues, they tell other people and then adoption tends to go from there. Cool.
Alex: I’m curious, does your team ever have to take the last 5% over the finish line?
Ben: Yes. So a lot of that comes down to just setting a deadline. Right. We’re not supporting this thing after X date and I’m really sorry, but it’s going away and then it becomes a rather manual process of, hey, you’re getting a bunch of notifications or maybe we’re reaching out one to one to those teams that are left on there saying, hey, you need to get off, we’ll help you. We got to do this by this date.
David: Something that strikes me about that is that in order to identify the teams that are using like the old version of the thing, you need probably a programmatic way of identifying usages of the thing and you probably also need some way of tying those usages back to the owning team. Can you describe a little bit about how that works at Wayfair?
Ben: Yeah. So we have different approaches for our Monorepo and our decoupled apps. I’m working through that a bit. So the Monorepo, it’s actually part of the project we’re working on now, is tooling to help identify those things and alert you and then escalate those alerts to make sure the proper teams see it. There’s a bit of an ownership issue there. Right. So it’s something that’s so large and has grown over time that it can be a more difficult problem to sort through. In the decoupled space of my team owns this one repo with this one app. It’s a bit of an easier problem because you know who the collaborators are on the project and then you can notify them. We’re utilizing a lot of GitHub for that, so we’ll have automated issues that are published. If you’re out of date, we might have an automated PR that gets sent to upgrade you. Yeah. And so in the newer ecosystem we have a lot more automation around that and we’re constantly building more.
David: Interesting when it comes to sort of this type of project, like introducing the Kafka templates or starting to untangle a Monorepo. You know, there’s obviously we talked a little bit about sort of how you achieve alignment with your organizational leaders, things like OKRs. But how do you get buy in from the teams that are actually going to be doing the work?
Ben: A lot of that is through the partnership and the value. Right. Like for the most part we don’t push things down. There’s very few projects that come top down. Most all of them come more bottom up. So if we can’t convince you to do it just because it adds more value to you, then you’re probably not going to do it and you’ll have to do it. So it really comes down to that. We try to think of our development platforms team really as a startup and the engineers as the customers. You don’t have to go use Heroku. That doesn’t make your life better, but if it makes your life better, you’ll use it.
David: And what’s the process for sort of making sure that you’re doing that, that you’re making your customers lives better?
Ben: Yeah, a lot of feedback. I spend hours a day talking to people, right. Like getting feedback or working with them on projects. A lot of partnering with teams. So someone’s struggling with something, we’ll jump on and help them do the thing, or they’re doing something new. That’s a constant process of iterations. Working with teams do a lot of workshops as well, on my team in particular. So we’ll have, let’s say, through the template building process. Back then we had weekly workshops, so we’d pick a different team each week and just sit there with them while they tried to boot up a new template and get it working and take feedback the whole time. And so we did probably five to 10 user workshops for the first version of that template just to get it smoothed out. A lot of times that smooths out our docs as much as it smooths out the actual code or the actual template. And we found that pretty helpful because it’s really easy to skip things in docs, especially if you know how something should work. But when you have someone with fresh eyes coming in, it’s immediately apparent what’s missing from the docs.
David: So that workshop approach sounds really interesting. Can you say more about, like, how it works?
Ben: Yeah. So the, the hardest part of it usually is finding the, the teams that can dedicate time. Right. And so we’ll try to line up several teams over several weeks. We usually do one per week because.
David: And what’s, what’s the ask there like, when you’re looking for teams that can dedicate time, Are you, first of all, are you talking to their managers? Are you talking to engineers in the team? And then is it like, are you trying to find people that have a use case that lines up with the thing, or are you like, fine with sort of pretending to do the thing just to sort of get them working.
Ben: Through the paces, it mostly depends on the project, ideally is someone that would actually use the thing at the end of it. Right. And so we’re almost always talking straight to engineers. So with that Kafka template, we looked for engineers on teams that had a Kafka app or would maybe be making one in the near future. The ask of them was really to devote at least an hour a week, maybe a couple hours if there was some follow up, to sit on a video call with us while they tried to boot up the app, be very detailed and very, very much a critic of the software. Just be brutally honest with everything happening so that we could take that feedback away. Usually we would have a workshop with them one week and then we have a follow up the next week where we fix the issues they found, have them try it again. So you’re looking at probably a couple hours for each person that commits to depends on what it is. Right. If you can even do it in an hour. So the templates, they take 20 minutes to boot up a new app with a template and really poke around and try it out and all that. So an hour was enough time to get some feedback in the process, work through a couple of things and really see it through. And then we tried to line up several teams to do that. So you get a lot of different perspectives on that. We consider our customer the senior engineer at Wayfair, not necessarily a manager, even another staff engineer. So we try to really target those senior software engineers.
David: It’s interesting that you mentioned sort of the follow up session a week later and showing that you fixed the problems that came up in the first session. I imagine that as you sort of do this with multiple teams, the number of fixes sort of compound one of the challenges that I found working in platform teams has been sort of closing that loop and informing users of all the improvements that have been made over time or whatever. Like, especially if you have sort of some folks that are carrying preconceived notions about a thing that was, you know, suboptimal a few iteration cycles ago and now it’s great, but they don’t know that it’s great. And like, do you have a strategy for sort of that marketing side of the job, like promoting improvements that have been done without getting too noisy?
Ben: Yeah, I don’t know what to do other than just follow ups. Right. So we tend not to do more than the one follow up with the same team. Sometimes we will based on all the feedback. It’s probably a problem if we’re giving you something that has so much feedback that we can’t fix it in a week or two though. Right. So that maybe means we weren’t quite ready for the workshops then. Usually we’ll go through several workshops. We’ll see the feedback kind of diminish over time. And we don’t wait for it to have zero feedback or zero issues. We wait for it to be at a real MVP kind of place. And then we’ll keep it rating on at release. But then we’ll release it and we’ll follow up with everyone that workshopped it. We’ll usually include them in the release, you know, as someone that contributed to it by being a part of the workshop. Just a bit of the kudos for being a part of the process. And then ask them to reevaluate it. And, you know, maybe they do, maybe they don’t. Hopefully they do.
David: That makes sense. You focused a lot on sort of this idea of like organic adoption by virtue of providing value. And I think that sounds really great. Like in the ideal case, you also mentioned that sometimes you have to sort of take away support for things and let folks know that their approach will no longer be supported. I can imagine that sometimes, like, it’s even a stricter case than no longer supporting something. Like, sometimes you actually need teams to actively move away from something. Let’s say there’s like a security or reliability drawback to the previous version of the thing. Is that something you’ve encountered? And if so, what’s the strategy there? Like, how do you sort of impose these asks on other teams?
Ben: Yeah, so we’re still actively working on tooling for this in some of our environments. But what we’re working on now is a process to where you have a deadline. So let’s say the deadline is end of year. You would start getting warnings on your PRs if you use the thing. And then as the deadline approaches, we escalate that up. So the next level would be you start getting warnings if you use a thing that uses the thing. Right. So, like, if it’s in your dependency tree at all, you’ll start your warnings in your PRs. The next step after that is your PRs start getting blocked so you can’t merge. We work on a system, so we really care a lot about not gatekeeping. Right. Giving teams their own autonomy. And so the way we do that is you can unblock yourself the first time by just pressing a button in your GitHub PR the next time, that escalates up to your manager. And then the next time it escalates to their manager. And so the idea there is to apply pressure on a team and to keep there being a cognitive cost to ignoring this thing and also to apply that up to eventually department level. So the departments have to set aside time to take care of that. We haven’t hit it too often yet, but you know, there is an eventual step where you’re just blocked until you fix the thing at some point.
David: That’s, that’s a fascinating approach. Is that that tooling all custom built, like sort of the, the various escalations?
Ben: Yeah. So it’s kind of the hard problem just we don’t have great ownership data in one place. Right. And so we have custom APIs that really like pull that information from various places and then feed that into a GitHub check on the PR and then that’s where it shows up.
David: Cool. So if I guess another sort of version of the same question is like, what’s the. Well, actually, do you maintain some sort of global visibility on this? Like do you have a way of tracking versioning for the things that you maintain across different teams? Sort of like the admin view of the, of the, of the view that individual engineers would see on pull requests?
Ben: No, but we are working on it. So I don’t know if you’ve seen Spotify’s Backstage, which is kind of like a dashboard for your platform, as a service solution. Right. And so we’re working to integrate Backstage and we’re building that out. We have it now, but we’re limited on what we offer through there. But we’re slowly but surely building more and more into it so that you would actually have both a global dashboard maybe for your, your org, and then you could drill down to your team, could have a dashboard and we would track things like what’s out of date, what’s maybe being deprecated, what’s coming up that you need to update, things like that, that you would track across.
David: Very cool. This is, this is not, this is just out of curiosity. This is kind of a non sequitur. But are the separate repos that folks are sort of spinning up at Wayfair, is it still all the same tech stack? Like, is that all consistent? But it just sort of the code ownership is spread out between different repos.
Ben: So we have four languages that we support officially and so that’s C Sharp, Java, PHP and Python. And then we have other. We just used here and there, but they don’t get official support. The, the overall stack stays the same. Right. So like we’re deploying to Kubernetes for all of those apps. But, you know, the. The actual implementation details might change based on the language. So, like, every language uses a different.
David: Framework, and so different teams own different repositories. But presumably there’s like, a way of sharing code between repositories. Is that like, by publishing packages or how does it work?
Ben: Yeah, so we use just libraries. Right. And we have an internal artifact server, and we share them through that.
Alex: Earlier you were mentioning that, like, you know, we talked a lot about delivering tools as a product. Right. That you see your team as a product builder and that you have users which are your senior engineers, and feedback is the mechanism by which you make this stuff better and you make it more valuable to your customers. And I was curious, do you have, like, an approach that you take to cataloging feedback? You know, do you have an approach for that?
Ben: No, not really. I think H team does it slightly different. For the most part, I just use a Google sheet and try to somehow categorize and find patterns. But a lot of that falls back to my lack of organization skills a lot of times.
Alex: I mean, you know, like, I think a lot of people might not even keep Google Sheets. So there you go. That’s awesome. It’s interesting because it falls into an area of research. It’s like you’re doing qualitative research. You said there’s a survey which is quantitative, but I think we all recognize that surveys don’t give you that sort of clear understanding of why a person doesn’t want to use a thing. Or, like, you know, like, they’ll be like, no, I don’t use it. And you’ll be like, but why? Like, why don’t you want to use it? And so qualitatively, someone can say like, well, it doesn’t deliver this, this, and this. And so it’s really interesting. Have you found yourself using the sort of experience, you know, the stuff that you’re collecting in this feedback mechanism? How are you feeding it into your sort of, like, prioritization process to understand what you want to work on next?
Ben: A lot of that comes from looking for patterns. So if we’re getting the same feedback very often, then that’s a, you know, good signal that we should probably focus there a little more. And then a lot of times we try to just feed the next thing, and then we’ll. We’ll put together potential projects for our next planning cycle, and then the team votes on and picks those projects. So I’m not exactly telling anyone to do It, But I will, you know, if I feel strongly about it, I’ll try to. To write a nice pitch for it, assuming that someone will pick it up if it’s compelling.
Alex: Nice. And do you ever, like, compare the feedback that you get with other teammates of yours? How do you compare and contrast the sort of feedback that you’re getting from teams?
Ben: Oh, yeah, mostly when we do that, we’ll do that as a team. Right. So, like the template workshops, I wasn’t just running that. I ran several of them, but there’ll be at least two members of their team on each one. And then we’ll trade out so that we all get experience running them and get the feedback and we’ll collect that feedback in one place.
David: Nice.
Alex: And do you. Earlier you mentioned that some of your engineers are embedded and it sounds like they’re sort of augmenting a project, but is that also like a feedback gathering experience where they get to have that in the trenches view of the work?
Ben: Oh, yeah. It’s mostly feedback for us and then for the team, it’s really kind of culture changing. We don’t do those engagements just to augment a team. We won’t go in just to help a team do a thing. Our goal when we go in really is to. To affect a lasting culture change. So for the longest time, we had a team set aside that only did this for testing. So they would embed with the team to help them work on their testing processes and then they would lead that team in a better place, hopefully where they now have a culture of testing and they have the tooling and everything set up to do that better. Yeah, and they would, of course, take feedback back for the next one and to smooth things out. But that was really their goal in that process, was to change the culture of that team, not necessarily to help the team write the app or whatever the team cared about.
Alex: Yeah, that’s cool. That sounds like a really big investment from the company’s perspective. How did the company decide to invest so much in testing that they actually started augmenting teams with more engineers? Do you know a little bit about how that happened?
Ben: Not really. That was before I got here. Yeah.
Alex: Cool. No worries.
Ben: In general, that process, I believe it was started as kind of an experiment, and. And that’s how we do a lot of things. We’ll have a hypothesis, we’ll try to do an experiment, we try to really coach it around. We think this thing might work. We’re going to try it and we’re going to collect data and see what happens? That was one of the things where we had data that this actually moves the needle. This actually works on affecting change. And so we’ve done more of it and it’s just grown from there.
Alex: Nice. So if I understand what you’re saying is when you want to help move a team in a direction, you have lots of tools at your disposal, but actually putting an engineer into the team is a highly effective way of helping teams adopt new practices.
Ben: Yeah, exactly. And it kind of feeds back into the snowball. Right. So like if we do one team in say a super pod of 10 teams. Right. And so we embed and change the culture in that team, that will tend to spread out. So that team’s doing testing, you know, they’re happier, they’re enjoying it, their app’s working is more stable. Right. Assuming we meet those value props, then they’ll kind of evangelize that for us to the teams around them and spread that even further so we don’t have to embed with every team to do that. We just have to embed with select teams across the org and then watch that spread.
David: Cool.
Alex: That’s really interesting. So, changing topics. One of the things we like to talk about is sort of like sponsoring and mentorship. Is that something that you do with engineers and you’re organization or outside of your organization at all?
Ben: Yeah, I wouldn’t say it’s not structured, but it’s definitely something you do and are expected to be. As a staff engineer, a lot of my sponsorship lately has been around helping other engineers get started with public speaking and speaking at conferences or meetups and things like that. It’s something I’ve enjoyed doing for a long time and it’s nice to help other engineers get started doing that.
Alex: Interesting. How did you. What led you to help start sponsoring people around this topic specifically?
Ben: It’s really something I’d like to see us do more of as Wayfair. Right. So like, when Wayfair recruiter originally reached out to me, I had no idea that Wayfair is one of the largest PHP shops around. Right. And it seems like a shame that more people don’t know that. And I assume they don’t if I didn’t. Right. So like, we’re solving a lot of really cool hard problems and I would just love for more people to know about that and, you know, hopefully come work on cool problems with me or, you know, at least we can have better conversations if there’s a little more knowledge out there of what we’re doing.
Alex: Cool. I didn’t know that. And when I think of php, I think of Facebook and I think of Etsy and that’s. That’s in Yahoo.
Ben: Yeah, yeah, I was. I was the same way. You know, I don’t know the numbers, but we probably have more engineers than Yahoo now.
Alex: Yes. Do you mentor or sponsor people outside of sort of like public speaking at all? Is it always just public speaking or do you have like a range of stuff that you help folks out with?
Ben: Yeah, that’s really just been the kind of my focus these past few months where I’m trying to help people. Being in this project I’m in right now, I don’t have a ton of time. Right. Like, I’m kind of stretched thin with what I’m doing. So that’s. I have to be careful where I’m spreading my focus in the past though, for sure. Mentoring a ton just throughout working on projects. Or maybe there’ll be an engineer that. Trying to grow in a certain area. It’s been a lot of like, an engineer wants to grow their career in a certain way. So we’ll help mentor them and then through the process, sponsor them for projects. Might help them along that path. Right. So, like, if an engineer is trying to grow from, say, senior to staff, really kind of work with them on what skill sets they need to do that, help them. If I see an issue that they should focus on, and then really just like, as a project comes up that might help them along that path, suggest them for it, talk to them about it, and try to put them up for that.
Alex: I have sort of like a random question. Maybe this won’t make the podcast.
Ben: We’ll see.
Alex: I started my career in php. I actually worked at Yahoo. And I remember for a long time languages like PHP had this, like, negative connotation. Right. But when you look around, people were productive. They were productive in these languages. They made value with them. And I’m curious if a person was entering sort of like technology today and they were worried about the language that they choose. And I don’t think really anyone should ever worry about that. Think about producing value for your customers. It seems though, like, there’s lots of organizations that have senior engineers that have lots of experience and they’re building really big systems. What would you say to a person just starting out, like, you know about, like, don’t worry about the stereotypes or whatever.
Ben: Yeah, I really don’t think you should. I’ve been doing PHP for, I don’t even know what, 12, 15 years now. It’s. People were Concerned about that when I first started using php and now, you know, it’s still going pretty well, you know, still plenty of jobs out there for it. There’s ebbs and flows. It’s very easy to start working something and then it just kind of dies off and then maybe it comes back later. I would probably shy away from choosing something super niche, right? So like, probably don’t pick something that’s like a third transpiled version of a language. Probably actually dive into the language itself and you know, like if you’re going to start with something, Maybe start with JavaScript instead of TypeScript for example. But again, I don’t think it really matters. Once you know one, it’s easy to pick up another. I don’t even know how many languages I’ve used over the years, but. But you know, I’m sure it’s a dozen, right? Like PHP could completely go away tomorrow and that would be fine. I would mostly advise people to like, don’t become just a single language engineer, really be a software engineer and pick up a few languages along the way. Be comfortable jumping around and that’s how you get real longevity in your careers. You’re not just stuck in that one niche. Cool.
David: Ben, we’re kind of wrapping up on time and there’s a couple of questions that we always want to ask folks. One of them is sort of if there are any resources and that can be like blogs, podcast, books, people, etc. That you would point other engineers toward if they want to sort of dig into some of this stuff.
Ben: Yeah, I’d say there’s probably two areas to focus on, right? Like if you’re trying to build your technical knowledge, I would focus more on things that won’t be short lived. So I would focus on like system design patterns, maybe some algorithm basics, you know, how a database works, rather than focusing on like what the newest, hottest framework is. There’s still room for that. But I would try to focus a little more underneath and then through trying to build up maybe your communication skills, your people skills in order to work towards staff engineer, I would actually recommend reading up on some management books. The time I spent in management has been invaluable to my work as a staff engineer because you just become a lot more comfortable with people and kind of jumping around more broadly and maybe at a shallower context. Whereas an engineer, I always like to dive very, very deep in things and that can be almost a detriment. So I would focus on those two rungs of the skills letter. As far as Actual resources for that rans and repose. Michael Laupp is. He’s got some great books and a lot of great articles. I found that pretty valuable. And then, you know, Will Larson have to throw out his name. He’s got some really great material. And then another one is manager’s path. I think that applies pretty well to the engineering side as well. You know, maybe slightly different, but it’s still very up.
David: That one’s Camille Fournier, right?
Ben: Yeah. Cool.
David: So one thing that we didn’t touch on at all today, and, you know, I can’t. Can’t just drop it in at the end and then not. Not touch on it. Tell us about your time as a manager and tell us about how that has influenced your work as a staff engineer.
Ben: Yeah, sure. So I was a manager for, I want to say, like, eight years. It was a while. I was a CTO of the last company I was at, and I was a director before that there. And so it was a dual role. Right. I was still very technical, but I was managing people. And there were times where I was coding and there, you know, there were months where I didn’t touch code at all, which is kind of scary as someone that considers themselves an engineer. Right. But really over that, I learned to focus on what matters to the business. And that’s not always, like the coolest project. Right. And a lot of times moving something else along is more valuable than just getting in and doing something yourself. I really learned to help unblock people and to focus on it as helping others instead of just getting things done myself. And that is where a lot of that change happened, between valuing the things I shipped that day versus buying the things other people ship that day that I helped them with. And, yeah, I enjoyed it. I defined it a bit emotionally taxing for me personally, you know, it’s. You have to judge that line between providing value to the business, but also making it, you know, a happy place to work and helping people through technical problems and all that. So I’m. I’m finding the switch to IC a little relating right now. It’s kind of nice to be able to focus in more on the technicals and dive a little deeper and not the people problems. But I. I do use the skills every day. Right. Like, as a staff engineer, you might not be managing people, but you’re. You’re influencing people and working very closely with people.
Alex: That’s really cool to hear. Sort of along the same lines, you sort of dropped in there that you were the cto, which I think is even like. Is another thing on top of being a manager. Like, from my outsider perspective, it’s like, it’s about strategy. It’s about making sure you really understand what the business is, is trying to do. And I’m curious, have you taken away any skill sets from being the CTO and applied them as a staff engineer? As a senior? I see.
Ben: Yeah. I think my focus on providing value definitely comes from that. Right. Like, as the CTO of the startup, if you don’t provide value, you’re out of the job. And I think a platform team is pretty similar. Right. Like, if we’re not providing value, people will build it themselves or go somewhere else for it, and then we’re out of a job in a way. So I think that’s where a lot of that real focus for me comes from. The other thing is probably just being able to jump around between different problems. It’s a large company. There’s a lot going on. And as a cto, you have to solve multiple problems for your users, usually. It’s helped me kind of have that dual focus.
Alex: So we have our final question, which is funny, we’ve actually kind of talked about it a couple times now, but, like, how much time do you find yourself coding nowadays?
Ben: That’s a good question. Should I put this in, like, a month and a week and a day?
Alex: Whatever makes sense to you.
Ben: So I have coded zero this week. I probably coded four hours last week. Yeah, a lot of the depends on the project. You know, last week I spent probably half my weeks coding most of the year. And then just as the projects change and I started working across different teams, that’s. That’s just not where my time was the most valuable. I do tend to, like, still go back to, like, this itchy feeling that I need to be coding, and then I have to remind myself, like, oh, that’s just not the best thing I could do today. These other things are more leveraged or better. And then if coding is the best thing to do that day, I’ll definitely do it. Nice. Well, thank you.
David: Yeah, thanks, man. This has been. It’s been lots of fun. That’s it. Thanks so much for listening to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website podcast.staffenge.com the website also has our contact info. Please don’t be shy, Sa.