Like what you see here? Our mission-aligned Girl Geek X partners are hiring!
- Check out open jobs at our trusted partner companies.
- Watch all Elevate 2022 conference video replays!
- Does your company want to sponsor a Girl Geek Dinner? Talk to us!
Sukrutha Bhadouria: Next up, as you know, we love Slack for being a platinum sponsor and hosting a coffee session with lead engineers, sharing best practices for launching and leading cross-functional initiatives as an engineer.
Sukrutha Bhadouria: Speaking today are Izzy Clemenson, Senior Staff Engineer, and Tracy, who we met earlier today, who is a Principal Engineer at Slack. Welcome Izzy and Tracy.
Izzy Clemenson: Hi everyone. Thank you so much for having us. Today Tracy and I are going to start talking about some tips that we’ve learned along the way of leading cross-functional, sometimes company-wide projects as engineers and not as managers.
Izzy Clemenson: Tracy and I have both been at Slack for quite a long time. I have been at Slack for over five years and Tracy, I think you’re on your sixth?
Tracy Stampfli: Little over five as well.
Izzy Clemenson: Yeah. So, we’re going to tell you really briefly about some of the projects we’ve led to give you some grounding as to kind of the size of projects that we’re talking about and then dive into our tricks. So Tracy, tell us about Duplo a little bit.
Tracy Stampfli: Yeah. So I actually talked about this project a little bit at last year’s conference here, and it’s a project that was code named Duplo and that we launched at Slack to address tech debt in both our iOS and Android code bases.
Tracy Stampfli: At the time we had a lot of legacy tech debt and a lot of legacy architecture, which was really slowing down development.
Tracy Stampfli: And so we launched this very big project to modernize these code bases. It took 18 months, which it just finished about a month or so ago and was a really big refactor, which kind of involved all of our mobile engineers at one time or another, not for that entire time, but over that period, pretty much every, all of our mobile engineers on product and info were involved in this project.
Izzy Clemenson: And this was an engineering-led effort. You brought the need to this effort, to our leaders, right?
Tracy Stampfli: Yeah. A group of engineers, I don’t want to take all the credit, but it was an engineering-led effort. We came up with the proposal, we sort of got pushed for both like that. We should have this project done and exactly what we should do in order to address this problem.
Izzy Clemenson: Great. And then I’ve worked a lot as Tracy noted, she’s been working more on the infrastructure side and a lot of engineering-led efforts.
Izzy Clemenson: I spent most of my time at Slack working on the product side of things, working on product and executive driven efforts that involved a lot of engineering. And so Slack Connect is my most recent example. It was a multi pillar multiyear project. We were in beta for two years. It took another year and a half to get to GA.
Izzy Clemenson: And the thing about that was even though the vision came from our CEO, the execution was across all of these engineering teams fundamentally changing what we meant by core objects in our infrastructure. What is a team? What is a user, what is a channel?
Izzy Clemenson: And so, although I didn’t bring Slack Connect to Stewart, Stewart brought it to our engineering team, there was a lot of cross-functional engineering efforts that needed to get done in order to get this feature out the door.
Tracy Stampfli: Great. So we’re going to talk about kind of three different things down to the beginning of a project like this, running it, and then kind of finishing it up successfully and to start with launching a project, a really big cross-functional project that maybe involves a whole bunch of different groups at your company.
Tracy Stampfli: How do you know that it’s actually time to do something that big? How do you know, oh, we really need to do something larger than our normal kind of project to address this. And it’s really about the size of the issue that you’re addressing.
Tracy Stampfli: I mean, in a lot of cases, like the ones that Izzy and I are both talking about, these were issues that our normal processes were not able to handle as part of our kind of normal processes or normal feature development.
Tracy Stampfli: It was something where we really needed a larger effort to address it. And it’s kind of about the downside of not doing something like that.
Tracy Stampfli: We were in kind of an unsustainable path with mobile development at Slack where it was just so much slower to do mobile development because of the tech debt that we knew we had to do something big to address it.
Tracy Stampfli: And that kind of ties into the second point of scoping problems like this. You have to scope them large. You’re trying address a really major issue, a major product need, major developer pain. You have to scope something really large to address that, but that can be really scary as well because it’s risky. It’s big, it’s risky.
Tracy Stampfli: How do you know how long it’s going to take or how many people it’s going to involve?
Tracy Stampfli: So one trick that we used or technique that we used for Duplo was to start off to sort of break it down into milestones and start off with something smaller in order to start off with the sort of the easy ones or the things that are much more well defined. So we said, okay, in this first milestone, we’re going to do this stuff that we know how to do it.
Tracy Stampfli: We know how many people it’s going to take, we know we can achieve it. And that sort of gave us momentum for the rest of the project. And also give us more time to define the rest of the project.
Tracy Stampfli: And in order to figure out like some of the unanswered questions that we had about what we were going to do later on. Izzy do you want to talk a little bit about getting stakeholder buy-in for these big projects?
Izzy Clemenson: Yeah. So like I said, the projects I’ve worked on, the main stakeholder which would be our CEO, kind of came up with it, but there’s a lot of other stakeholders that you need to talk about.
Izzy Clemenson: Tracy needed essentially to get to a point where we’re saying we’re going to stop feature development for a good chunk of people on mobile and make this investment, or in the case of more product focused areas, no one else’s roadmap is going to move forward because this product takes priority.
Izzy Clemenson: And so a lot of the stakeholder buy-in is to make sure that the leadership that you are working with, whether it’s PMs, EMs, customer success, whoever it may be, understand why you’re doing this, what will the benefits be, and how do we know we are making progress? Success we’ll talk about at the very end, but towards the project, we need to know that we’re making progress.
Izzy Clemenson: So that kind of gets into running the project. And when you’re talking about something as large as what we’re talking about here, it’s not a matter of brute force. You, no matter how dedicated you are, cannot do this alone. It is impossible. There are not enough hours in the day or hands on keyboards to do this alone.
Izzy Clemenson: So you need to be a part of driving alignment. Does everyone who is participating in this work, know why you’re doing it? Are you all focused on the end goal and why you’re doing it?
Izzy Clemenson: Once people understand the why and deeply understand it, they are empowered and empowered is a very important word for me here, to make smaller decisions along the way so that you don’t always have to be checking upon things. And you don’t feel like you’re having to micromanage that project progress.
Izzy Clemenson: And that helps keep projects on track. You basically pick different people across organization who are helping drive this project towards the end to you break down smaller projects along the way of this team over here is going to handle whatever case. And this team over here is going to handle this piece.
Izzy Clemenson: And what you need to do is at periodic points, bring in representatives of those projects, smaller projects to make sure you’re working together. If someone’s getting far ahead and other people are behind, does that mean you need to shift focus, go back to your stakeholders and kind of reassess how you’re making progress along the way?
Izzy Clemenson: And once you break down into smaller projects, that’s where the leadership of other ICs is really important. ICs here meaning individual contributors.
Izzy Clemenson: It is really important if you are leading a project to pay attention to the smaller, or smaller is a terrible word, to pay attention to the leaders who are leading the smaller projects, because if your project is this big, this is an opportunity for people to be seen, to be heard, to practice their leadership skills and to get promoted.
Izzy Clemenson: So when I work across multiple teams, I pay attention to who ends up in these leadership positions. You want to, this is a point where you can have a voice in the representation and diversity of the new, the upcoming leaders at your company.
Izzy Clemenson: Because if you’re on the line for the larger project, you can be a representative and invest in representation across the rest of the company or across the rest of your team. As people are working on smaller projects and they can use that as their own skills or to invest in their own skills.
Tracy Stampfli: Yeah. And I really think it’s important to call out the successes of those leaders or just of people working on the project in general. That’s something I always try and stay aware of as with these really big projects.
Tracy Stampfli: It’s part of my job as a leader to make sure other people are recognized. And so calling them out in public channels or to their managers to make sure again like that, the great work that they’re doing is seen super important.
Izzy Clemenson: And even too, back to those stakeholders, people who may not interact with some of the more senior executive leadership, if they have made an impact on this project, their names should be heard and you get to be a part of elevating their work.
Tracy Stampfli: Very true. So moving on to completing a big project like this, this can be actually pretty complicated, figuring out how to measure success of a really big project.
Tracy Stampfli: A lot of times when you get to something that’s this big you kind of have to come up with your own metrics for measuring it. A lot of times, it’s not as simple as, okay, we’re we know this is what we’re trying to do, and then we’re done.
Tracy Stampfli: And that’s not usually the case, especially I think with something like an infrastructure project where maybe it’s a refactor or a migration, you’re not just shipping a product, you’re trying to measure health of the code base maybe.
Tracy Stampfli: And that can be a tricky thing. And so when we did Dupla, we tried to come up with a lot of different kind of quantitative measures, like migrating lines of code or removing deprecated instances, deprecated patterns, adoption of new technologies.
Tracy Stampfli: We’re trying to improve build times or development speed so we tracked local build times and remote build times. So we came up with a whole suite of quantitative metrics, but we also looked at more qualitative metrics.
Tracy Stampfli: We wanted to talk to developers and say, “How do you feel about the impact of this project? Is this actually making your development process easier and faster?” Maybe talking in the case of development, a big product change, talking to customers and getting customer sentiment, developer sentiment.
Tracy Stampfli: These can be really important measures. And being able to see how that changes over the course of the project can really give you a sense of its impact, sort of similar to being it’s hard to measure success.
Tracy Stampfli: It’s also kind of hard to know when you’re done with big projects like this, because again, you’re never really completely done. You’re not going to completely finish getting rid of all the tech debt in your code base. You’re not going to get to the point where everything is perfectly modernized.
Tracy Stampfli: There’s always going to be more work, there’s always more work to do. And so you have to just kind of define a stopping point where you say, “Hey, maybe we’re not completely done this entirely, but we can maybe transition at this point back from, instead of having this big project umbrella that we’re working under, maybe we sort of transition back at that point to addressing, say tech debt as part of our ongoing product work as part of our normal process.”
Tracy Stampfli: And then just setting again a clear goal so that you know when you’ve hit that point and you can show that you’ve delivered the impact that you have said you’re going to deliver before you kind of transition out of this project.
Izzy Clemenson: And that kind of hard to measure done-ness isn’t just for infrastructure or code refactor projects. It’s also something that I’ve experienced with product because a complete product is never done.
Izzy Clemenson: The project I’ve been talking about was something that Stewart envisioned at the very beginning of Slack. Clearly we shipped Slack before this was done and lots of people use our product and it met many, many people’s needs.
Izzy Clemenson: And so one thing along the way is to work particularly with product managers and that part of the executive leadership to say, “How much of what we’ve built solves a current customer need that we can ship today and how much can we build incrementally on top of that?”
Izzy Clemenson: Sometimes the answer is if we shipped what we have today, it still wouldn’t do anyone any good because it’s not finished enough, but other times you can find ways to incrementally shift.
Izzy Clemenson: So you need to have that balance and that conversation with the stakeholders that you have of how can you know when to ship what you have?
Izzy Clemenson: So I just want to say, thank you everyone for coming. I know that not everyone is going to work on a project that is company wide, but I hope some of these tips will allow you to go into your next leadership opportunity with a little bit more confidence.
Angie Chang: Thank you, Izzy and Tracy for your talk. It’s really exceptional. I loved hearing about how to launch a large project as a lead engineer.
Like what you see here? Our mission-aligned Girl Geek X partners are hiring!
- Check out open jobs at our trusted partner companies.
- Watch all Elevate 2022 conference video replays!
- Does your company want to sponsor a Girl Geek Dinner? Talk to us!
