Transcript
Alexander: I’m Michelle, VP of Engineering at Fanatics. I lead a team that’s owning our single sign-on, auth, user login experience, the Fanatics shared cache across our systems, as well as a newly launched fan app being the center for sports fandom. I’ve got enterprise-grade systems that need to scale, and I’m trying to build out a delightful user experience at the same time. Prior to Fanatics, I spent the last decade over at SeatGeek and Spotify, leading product and platform engineering organizations. As you can see by the topic of this talk, I narrate about organizations and how to make them effective and how to find the patterns.
Be Intentional
Today, I’m not talking to you as the VP of Engineering at Fanatics, I’m talking to you as CTO Michelle, who’s leading a hypothetical company and who’s going to set out their engineering organization strategy. I told you it needs to be intentional. You need to bring to the table what are your unique needs, business values, and size of your company. For my company, we’ll start with values. As the CTO, I certainly will have a huge influence on how we want to operate, but at the same time, the company is going to have those to begin with. Assuming I’m not creating this from scratch, I need to do that diligence when I’m talking to any company about making sure there’s a good alignment there. What are the key values I bring with me?
The first one is accountability. I think the 10 years ago buzzword was autonomy. I believe accountability is a direct descendant of that where you still are responsible for doing quite a lot, but you’re responsible for it. There are ways to show that impact. I want a place that’s going to give me that autonomy to go do a lot and make sure that I’m keeping up to my commitments. Learning and growth, this has also been key to my journey. If I stagnate, I get bored. I want there to be dynamic things. Being in Spotify during hypergrowth, of course there’s lots of natural times that came up. In the tech industry we’re in now, hypergrowth isn’t the name of any of our games, but there’s still lots of different ways to bring in that learning and growth to your organization and yourself. Collaboration, I’m not looking for a place where we are setting our teams out to pit against each other. I believe that there are ways that we can set incentives up to collaborate. Two plus two equals more than four, all of that good stuff. That’s what I’m bringing to the table with my values.
Business requirements, say my company hypothetically needs to run the auth system for many different products. It needs to be highly reliable. Say we’re hypothetically launching an app that we want to be the center of sports fandom. That needs to be delightful. Say, hypothetically, everyone comes to it to purchase their favorite gift for their family during next week on, and there’s some bursty traffic when everyone else wants to cash out their bets at the end of that football game. Some business requirements we can work with. We’ll say, company size, 400 engineers, and we expect 5% headcount growth next year. Again, not hyperscale, but there’s some moving there.
Behavior – Are We Showing Up in the Way We Are Expected To?
Where do we go from here? These are the four questions we’re going to ask. Are we showing up in the way we’re expected? Are we prioritizing the right work? Are we getting our work done? Are we maintaining what we own well? I am going to go out on a limb and assume everyone’s zooming in on those bottom two options, because that’s really the bread and butter of what we’re doing day in, day out. I’m going to say, when you start up here at behavior, this is an easy one to skip. We’ve got to ship things. We got to focus. Skipping the behavior quadrant is not like throwing a no-op in your system. It’s much more akin to training an LLM over all of the experiences that every one of your engineers, managers, directors has had. Beliefs about how they think engineering should be done and teams should be run. To one giant system that can spit out all the hallucinations and just throw more chaos into your system.
I truly believe it is worth the time to start here on behavior. How do you do that? I want to show how I would build out the system and constellation around behavior. There are a couple of key artifacts and things you need to be doing. Thinking like your career framework, your performance evaluation, promotion process, values, and principles. I really want to hone in on career frameworks, I think that’s the backbone. That’s how you tell your organization what matters, how you expect them to operate.
The good news is, is that AI can actually help us. How many folks here have built out a career framework or helped build out their career framework before? I don’t know about all of you, when I’ve been involved, it’s always been an art of finding that prior art. Dropbox being one that has published really good artifacts. I didn’t know what was going to happen. I turned to ChatGPT and I said, give me a CSV of an engineering career framework off of Dropbox’s style. It spit this out. The only thing I had to do was copy, paste, transpose, and put in some color there. That’s about what I would have gotten to in my first pass. Less than five minutes, you have the bare bone structure of your career framework. It looks genuinely pretty good. I didn’t inspect every element, but certainly something to start with.
This is where then your intentionality and specific use case come into play. For me, with a value of accountability, I’m certainly going to weave in, what is the level of oversight and independence I expect from each of my engineers at each level? Both to signal to them how I expect them to rise to the occasion, and also what they should expect from the folks around them. I don’t want to create an environment where micromanagement is encouraged, as an example. I would also include the expectation about being able to drive outcomes and what that might look like. Learning and growth being important, I would certainly include expectations around mentorship and creating an environment where it’s safe to fail. With the high reliability that we need for our systems, I would make sure to weave in the engineering expectations and expertise that’s going to bring us there. I also mentioned I’m building a delightful fan-facing app.
The skills that you might want to bring there, and making sure you’ve got really amazing native mobile engineers and web engineers, as well as backend engineers who can think about scale and caching, those look different. That’s great. That’s how we build great teams. Make sure you think about everyone in your career framework and don’t build it in one way that you can only incentivize one engineering group to grow.
We have a career framework. As the CTO, I’m going to take that career framework and say, we’re doing our performance reviews twice a year. We’re going to base it off that career framework. Top of the year, middle of the year, that’s where I’m engaging in my system.
As the director, you’re leading multiple teams. You’ve got managers underneath you. Rather than waiting for the half year, think about a talent snapshot you can do with your team. Where you take that career framework and you say, how is my organization performing to the expectation of their role and level? Have your managers run this. It’s a really great tool. It can be done really quickly to check in, make sure your managers are talking with their engineers, are really understanding how they’re performing. Get an overall view of what patterns are happening. Do you need to invest in different trainings? Do you need to potentially bring in some new skill sets? Also, again, a forcing function to have your engineering managers talk with their engineers so we don’t get to performance review where people are surprised. Then, as the manager, you’re having really regular one-on-one conversations and talking about career progression using that career framework. In total, you end up with this constellation of how you ask the question, are we showing up in the way we’re expected to?
Prioritization – Are We Prioritizing the Right Work?
Where do we go to next? I’m not letting us dive into the bottom yet because I believe you can have the team that delivers on exactly what they say they’re going to, that maintains their stuff as best as possible, but if we aren’t being intentional about what we prioritize, especially in a world where our teams aren’t growing massively all the time, we’re not going to win. I want to jump into prioritization next. Are we prioritizing the right work? What are some things that we think about here? We have mission, vision, strategy. We have technical decision-making. That is key. Knowledge sharing, how people are getting the information about what they should be prioritizing. How do they know to make the right decisions? Diving into mission, vision, strategy first, this is something that we have a business strategy. Assume you’ve got great partners in that, you’re working with them. There should also be a tech strategy to accompany that. What do we need to build out to make sure that we’re going to be able to get to that five-year goal? That should be the direct input into your annual planning process.
As a director, you’re probably committing to quarterly commitments. What are we going to get done? Throw those on our constellation. Pretty standard stuff at this point. There are lots of great articles out there about how to write a great mission, vision, and strategy.
I want to dive a little bit into technical decision-making. How do we be intentional about this process? If I’ve got the business requirement, where this is my traffic pattern and it’s known. It’s well-known where my system is the most brittle and going to fail over, you better believe that the process I put together is going to have a set of questions that guides my engineering organization to make sure they’re thinking about, will this keep the part of our system so we can save? Will it improve that part? Have we thought through the testing strategies, security implications, how this is going to work with different user cohorts? Have one process that’s guiding your team through the questions that you need them to be asking and answering. With the value of learning and growth, I don’t want this to be something that’s sitting in some ivory tower of principal engineers that meet behind closed doors and make decisions. I want to make sure this is something that is visible and open and anyone can be involved in.
Like I said, company size of 400, not huge, not tiny, but we can’t all get in a room with a whiteboard and figure things out. We need to find a way to make decisions, make technical plans, and have that be accessible to a large group of people. What I’ve seen work really well for this is RFCs, so request for comments. ADRs are another good example of documenting the decisions you made for your architecture. This is something that I really see the staff engineers, the principal engineers at your company leading with. Being the ones who are reading all these RFCs coming out, making sure they’re checking the boxes or thinking through the implications.
As a staff engineer yourself, you’re probably publishing a few throughout the year. This is something that happens regularly. You’ll see it’s scattered on our constellation sporadically, not tied to a specific quarter, because these types of things aren’t totally tied to time. They’re as you discover problems that need to be invested in. When you put it all together, you end up with this as your way to ask, are we prioritizing the right work consistently throughout the year?
Execution – Are We Getting Our Work Done?
Let’s get into the meat of it, execution, what we all spend our day in and out doing, writing code. Actually, I’m curious, how many of you all are engineers who are spending your day in and out writing code? How many of you were once engineers who spend your day in and out writing code and now you don’t get to do that? I will cover both here, but a big part about execution when you get into the higher levels is, how do we measure that? How do we track that? How do we do it in a way that doesn’t piss off or waste the time of the people who are actually in the weeds building a thing? This is another place where AI can really come in and help us. It is actually spectacular that we’ve got Peter and Taylor with highly opinionated feelings about what they want to use for code assistants and that they are testing out different things.
This is an area that is going to continue to grow and change, and being able to harness the folks who have that passion in your organization, encourage them to be testing and bring those learnings back, is how you and your engineering organization are going to keep up with the change. Do put a little thinking into how much you invest though, if it’s going to change that much. If I’m talking to my engineers, the things that they’ve seen work really well for these coding assistants, boilerplate code, comments, tests, all good things. Where they’ve seen it fall on their face is if you try to do more involved things or context-specific things. That part for now, leave it to the humans. Make yourself more efficient by getting some of the other stuff out of the way.
Now back to us boring folks who are just tracking things. What are some ways as a CTO I can make sure things are happening that align with my goal of giving folks accountability and autonomy? KPIs, looking at that every quarter. No, I’m not diving into what you’ve committed to this sprint or how that burndown’s going. I’m saying, I trust you to do your work. This is how we’ll know that it happened. As a director, you have multiple teams. Maybe you’re running a scrum of scrums, meeting biweekly, and seeing those quarterly goals we set out to, how are we tracking against that, sprint over sprint? As the manager, you’re running your standup. You have your regular meetings. Your team’s committing to work over a sprint, and moving that along.
One of the things I mentioned was trying to keep your tracking process in line with how your team’s doing work. I could care less what you use, Jira, Trello, a spreadsheet, but if you can harness the way that your engineers are doing work and moving along and showing it, and just be clear about what output you need to see and bubble that up, it really can make a smooth system for everyone. This is what my constellation looks like for execution, for how we answer, are we getting our work done?
Operation – Are We Maintaining and Operating What We Own Well?
Finally, our last question. Are we maintaining and operating what we own well? The core tenets here are our on-call process, how we handle tech debt and maintenance, our incident response process, and my personal favorite, having some operational review that you’re doing regularly. How has AI benefited me here? I’ll say at SeatGeek, I was responsible for our incident management process. We had used a handful of different tools and settled in on the flow where when an incident is risen, new Slack channel gets spun up, everyone jumps in that Slack channel. Of course, high bandwidth communication is important, so you’re going to jump on a Google Hangout, a Zoom, whatever video conferencing you use, but what happens in that video needs to be relayed back to that Slack channel. That is your central source of truth. Open public Slack channels, we encourage folks to jump in, engineering, product, business, operations folks, and contribute to what might be happening. We also invested in incident commanders so that they were in charge of keeping everything on track and going.
One of our biggest challenges was, how do we get the information needed to our operations folks, to folks who were dealing with our customers, while also making sure the engineering team is laser focused on mitigating the current incident at hand. We play around a lot with different roles, like scribes who are, again, putting that information back in the Slack channel, like liaisons who are trying to figure out what’s happening, communicate out, and various success on all those different things, but this is actually where AI just came in and solved my problem for me. We were using Datadog’s incident management on Slack. Between the two of them, they started just spitting out, as soon as you enter a Slack channel, a really good summary of what’s just happened.
If you’re entering in as an operations person, you can see the state of it. If you’re entering in as an engineer who just got paged, you don’t have to scroll back through 30 minutes of conversation, you can get a snapshot of what’s just happened. It’s also really good for doing historic incident patterns and looking that up. Where I would say it is not good, keep it for the humans, is the post-mortem generation. Not actually that it did a bad job, but that it became a crutch, where it’s like, cool, it’s filled out, but you miss those steps of critical thinking. It required a lot more going back in and making sure our engineers had done the due diligence about the incident, and not just relied on a bunch of text that was spit out. That’s how AI has and can help you all.
How do you make sure that your operations, and your question, are we operating well, are intentional? For me, with accountability, I’m going to say we go on-call for what we build. I’m not going to invest in a separate SRE team that’s going to be owning what our engineers have pushed to production. There’s an expectation as the on-call engineer and as the team who owns the system, you regularly have eyes on your system’s performance and metrics. Because I value learning and growth, I’m going to make sure that we are taking on the blameless incident post-mortem culture that so many in our industry do, and encouraging all levels to be present. How you really guide what is an incident, when do you need to jump in, what’s important is by helping your team by setting out these SLOs and SLAs, and error budgets for what really matters to your company. You don’t want to be paging your engineers for something that actually can wait until Monday. That’s how you’re going to get burnout, it’s how people are going to not respond to the critical thing. Take advantage and be smart about what matters for you.
As the CTO, how do I fit into this operation game? Maybe it’s a little more inconsistent. I’ve certainly given the context of what matters to our business to help define those top-level SLOs, but maybe I’m only pulled in occasionally when there’s that really bad incident and I need to do some technical external customer communication. It’s a bit sporadic. As a director who’s leading multiple teams, this is where I think your critical tool comes in, having some kind of operational review. If you’re running these, but it’s just, here’s my team’s dashboards, they’re green, here’s mine, we’re still sad about this one metric, but it’s been that way forever, and everyone’s checked out and running through. I want to say, you’re not running it right.
The focus shouldn’t necessarily be, make sure you have your dashboards, that’s important, but this is the one meeting where you really have the opportunity to tell your team what’s important and that you’re expecting it to move week over week, and give them that focus. There’s probably a lot of things we want to improve. What is that one thing? How can you build that muscle? How can you show your team that if you really put the focus on getting your top-level endpoints to 99.999, and you see it move week over week, and then you shift to something else, you’ve now created this repeatable process that you can start handing off to your staff engineers, other engineering managers, to show, we can drive change, we can give our team grace to focus on one thing at a time, but we have this forum now that’s going to happen regularly that we can funnel questions and problems into.
Then, as the engineer, you are on-call regularly throughout the year. This is about monthly, in my visualization. Hopefully, none of you are being on-call a ton more than that. I know it varies based on team size, but you are obviously contributing to the consistent operation of your systems a ton as an engineer. That’s how we answer, are we maintaining and operating what we own well?
When you put it all together, we’ve gone through different ways and different tactics you can use for each of these questions, from career frameworks to technical decision-making to work tracking and our on-call incident processes, and how AI in the current state can fit into that. The key thing here is that, again, if I was standing on a stage a year from now, the slides in which I said what AI is good for and not good for are going to look completely different. Finding the ways to make sure you’re still iterating and throwing that into your process will really help as you go forward.
Common Scenarios – Agent of Chaos, and Process Overload
If we look at all the constellations we made, how are we showing up the way we are expected to? Are we prioritizing the right work? Are we getting our work done? Are we maintaining and operating what we own well? You throw those all together, it starts to look very similar to this image at the start. Because we have just created a repeatable system that we can use throughout the year to make sure our teams are operating well. That’s great. Say you’re not the CTO. I know we saw a lot of engineers in here. Say instead of having me as your VP who’s very focused on how do I create a system that’s not painful and gets everything done, you have an agent of chaos above you. I have worked with many agents of chaos. I think we probably balance each other well. It’s probably a good mix. It’s a common scenario and pitfall that I’ve seen. When you’re in that world, how do you even introduce any of this predictability and stability?
The other end of the spectrum, which I try so hard to never be, is the process overload, going from 0 to 100 new things. I just know if you check all these boxes and fill out all these things in your Jira ticket, we will get everything done. It’ll be perfect. Everyone will be happy. I’m not seeing one happy face. That is not going to work. Let me talk through a couple of these common scenarios and how you can use these tactics from today to actually work inside of them.
Agent of chaos, like I mentioned, I’ve worked with quite a few, and have enjoyed working with all of them. One of the most recent examples is actually, this past year, we were working on reducing our cloud costs. I think that’s probably a pretty common activity that many of you have done.
One of our big strategies for doing that was moving from our previous setup to Kubernetes. We knew that was going to reduce our cost a ton. It was also a big lift. I hit the beginning of the year, my platform engineers have already been working for half the year on setting up the basic foundations. We’ve got the big migration ahead of us, and the audacious but doable goal of getting it done by June 30th. I said that date a lot: June 30th, June 30th. Because cost consciousness, how do we cut costs, how do we be responsible with how we’re spending was a big theme, and it hadn’t been before. There was a lot of low-hanging fruit in our cloud infrastructure. We had folks from across the company, folks with lots of experience doing this, coming up with lots of really great ideas about how to cut down costs. Of course, my VP was like, “That’s great, do it”. One of the things that I did to help protect the team is reiterate, our goal is to get 100% of our systems onto Kubernetes by June 30th. If we miss that, but have done these other things, will we be ok?
The answer is no, because that small low-hanging fruit is important, but it wasn’t going to add up to the cost savings we get from the Kubernetes migration. Asking it in reverse, if all we’ve done by June 30th is get all of our systems onto Kubernetes, will that be enough? The answer is yes. Reflecting that back then guaranteed me the space to give to my team to really stay laser focused on getting this really hard goal across the line. The answer could have been no, and that would have been fine, but then I’m asking that question, and I’m going to say, and June 30th might become August 31st, and be able to talk about those tradeoffs. Reflect your current priority up and validate any changes that are going to happen.
I think the worst place that any of us can be in is if we just say yes, because you are going to burn yourself out, you’re going to burn your team out. You maybe won’t hit it. I can say, I’ve been in my own agent of chaos, I don’t always remember everything I’ve asked all of my team members to do. If you aren’t taking the moment and saying, Michelle, there’s these five things, this is what I think is the priority, is that right? Then I might not have realized that I’ve accidentally become your personal agent of chaos. I think this is a really important skill for all of us, no matter where you sit in the org, to be able to reflect that back up and share the reality of your ground truth.
My other agent of chaos was a product manager that I worked with while I was at Spotify. He cared deeply about our product. I was building out the ads system at the time, mobile engineer building out the ad experience. We had just moved to a two-week release cycle, there was a ton of configuration that could be done by operators in the actual ad stack itself. This led to a fairly regular occurrence where we saw a number trend down over months. Was this seasonality? Did something change? It led to fire drills. This product person, again, cared deeply, they had enough knowledge of our systems, they were paging engineers, they were pulling folks in from Stockholm. It led to chaos. We found the answer sometimes, but it was really tense, high-stress situations.
Seeing this pattern happen over and again, myself and a fellow engineering manager stepped in and said, let’s create our process that acknowledges there’s an issue that we need to solve, that puts one of our engineering managers as the point person accountable for until this is addressed and solved, they’re on the hook, and a one-stop shop where you can see the progress of it, our hypotheses, and what we tackle down. It was a little bit fun being on this type of teams. That manager also had free reign to say, engineer A, B, and C, I need you, this is the top priority thing, you’re jumping in.
By creating this process and this visibility for our product counterparts, they knew what was happening, they knew they could trust us, and we brought our own accountability to the table. Like, we get it, this is important to our business, we’re treating it seriously. Being able to put that structure in, even as an engineering manager with a product director above us, it’s more of being able to create that structure around you. Like I said, I’ve been thinking about this stuff for a long time.
That’s also where I run the risk of becoming the process overload person, going from 0 to 100. How many of you have joined a new team, it’s complete chaos, everything they’re doing is just silly, and you really want to say, “If we just did it the way my old team did it, I promise it would all be great”. That’s really easy. We’ve seen success happen, just repeat it. The most important thing that you can do when you’re joining a new team, is really try to understand why they’re operating this way. What is this team’s superpower? How are decisions made at this company? Because you may have been in a team where you were pointing everything, you could see a burndown chart for every team in the company, and it rolled up perfectly in some Jira heaven.
If you’re joining a team that doesn’t track their work like that, who is still getting shit done, and is going to be really cranky, trying to put that process into place, you’re not going to get the same results. Instead looking at, what is the biggest problem I’m seeing here? What is, maybe it’s not even work tracking, it’s actually our incidents, we’re not responding to them soon enough. Or it’s that our engineers are pissed every year because they’re not getting promoted and they don’t understand why. Really look to see what the big problem is, and start with the first step. Don’t jump to building out your whole constellation. Really figure out how you can drive iterative change. We can only adapt so many changes at one time.
When you are introducing a new change, something that I really love to do, is put myself in there first. What if that means actually embedding with a team and seeing what I’m asking my engineering managers to fill out at the end of every sprint? Is it doable? Running an incident and seeing all the different fields and steps I need to take, was that painful as heck? Putting yourself through it, one, signals to your team that you’re part of this as well, but you also get to see the pain firsthand and shave off some of those initial first mistakes.
The other thing that I will implore you, who’s worked at a company where you used OKRs? Who’s worked at a company where you used OKRs, and you didn’t use OKRs, and you did use OKRs again? I dislike OKRs, I’m going on the record, not because I don’t think it’s effective, but I think that system specifically is very dogmatic, and you get so many more people talking about, am I doing OKRs right? Not asking, am I prioritizing the right thing? Am I getting that work done? Which I think, in its essence, is what OKRs is actually there to help you do. I’m not saying don’t use OKRs, use them, but what I am saying is if you find yourself in a spot where you’re like, our yearly prioritization process isn’t working, if we just use X system, that’ll fix it all. That’s when the red flag should be going off for you.
Instead, really try to look at, why isn’t our current system working? What is the biggest problem? What is one change we can make? How can I be consistent with this process so that I’m not inadvertently training my leadership team to know that I’m going to roll out a new yearly planning process every year, so it really doesn’t matter? The more you can think about iterative change, even on that long timescale of years, the better. This was an approach I took at SeatGeek where I was owning the 6-week commitment and delivery process, and getting us from a place where we had less than 60% say-do rate, you did what you said you were going to do, to over the span of 2 years, making us consistently hit 80% across the whole org. Doing it without asking everyone to fill in a lot of the different ticks and boxes on Jira. It took a lot of consistency, I’m not changing the fundamentals of the process, and also iteration and listening. How can I address the pain point you’re having? How can I make it easy to follow? How can I make it align with your team’s ways of working?
Again, when you put it all together, you end up with my system of how you answer these four questions. It’s something I think about a lot, and love to hear how other teams answer their questions.
Questions and Answers
Participant 1: Early on when you were talking about values, behavior for development, what occurred to me is that a lot of folks, those are predetermined for them, even if they’re a senior leader in the organization, leading a large company. What is your recommendation for balancing how much you take the template you’re given versus how much do you reimagine as a leader?
Alexander: I think part of that goes into some of the deciding where you’re going to land. I just joined Fanatics this year, and a big part of talking to companies was seeing where that alignment was. If it wasn’t fully aligned, is it something that I’m ok changing to? Is it something that there’s actually buy-in to shift towards a way of operating that I’m comfortable with? It is the case, there are plenty of companies that I’m not the right fit for, and that I won’t be happy there, even if I could be effective in the way they operate. Taking that into consideration when you’re making decisions is a huge part.
The other thing is, I think, by setting out these systems in clarity, it gives people that opportunity to really understand, is this the place where I’m going to be able to operate in the way I want to most effectively? That being said, I think everyone can and should influence. Signaling up, if you’re an engineer, to your manager, your director, your VP, the different areas you’re interested in, starting to show the way that you think things should be operating, those are some of the keys that I found. I think the best advice I got when I first stepped into management was, if you’re solving a problem in your team, it benefits yourself to look up and look around a little bit and see if that problem is happening elsewhere, because you might be able to put a solution or a pattern in place that can help many.
Participant 2: I’m always trying to think practically. You gave some really good ideas here, but I’d love to have a more detailed example. You talked about your Kubernetes migration. Can you explain how these principles actually apply to that, whether or not it was successful, and how you measured your success?
Alexander: One of the most important things is, are we getting our work done? I had my staff engineer who’s running the whole problem, who knew the big key problems, and I was able to turn to my peers as directors behind the scenes, and be like, we have commitment to this work this quarter. Trying to give people the visibility of what actually needs to happen, and then keeping that consistent.
Actually, the story about all the different priorities and ways we wanted to optimize the costs and low-hanging fruit was the biggest way to clear out the noise on top, because that was a definite risk of throwing all of our engineers who had been working in the system and knew they had ways to do it scattered, when they need to be really focused on getting us across the last mile. For anyone who’s worked on migrations, you know the last mile is the most painful. You’ve been doing the work. You’ve built out the thing. It works. You just got to get those other engineers to adopt it. That’s when we need everyone to focus, not to run in a million directions.
Participant 3: I find that one of the things that slows down bigger companies is coordination efforts and mismatched priorities and all that stuff. How do you manage this problem in this framework where you have 10 different teams who do not necessarily care about the same project the same way and things in that type of quarters or years or whatever you’ve accomplished?
Alexander: That’s another big reason why I want to focus on prioritization first. I think us as engineering leaders have a superpower there, because you have an instinct, whether you’re an engineer, a manager, a director, about how much your team can do, especially if you are not getting collaboration from another team. When you’re in that prioritization meeting, this is your moment to show, like, “I can future-tell here. We are going to run into a problem. We are not going to be able to do all these things”.
Communicate that. Be that voice at the table, not in an obstructive way, but in a, we’re going to solve this problem together. What is that clash that I know my engineers are going to run into? Can I actually make that a clash in the decision-makers who are setting out this priority? It’s not a perfect solution, but I really try. When the answer is, we need to make a call that’s right for the business, push those conversations as early as possible and put the pain where it needs to be, a strategic choice, and not where it doesn’t need to be, which ends up being two teams battling it out and being annoyed that the other one never delivers, when the reality is they weren’t set up from the start. That’s one really key place. I mentioned that our delivery process, it got it from 60% to 80%.
A big part of that towards the end wasn’t about delivering anymore. The teams were delivering if they said they were going to. It was about forcing our senior leadership to say, have our teams committed to the right thing for the next six weeks or a quarter? If they deliver on this, will we be happy? Really, again, building that trust that, yes, we can deliver, and making sure that we’re making the right calls and pushing that decision up.
Participant 4: The human feedback in the process, how do you see it affecting the use of this system? What would you recommend to us as the way to get human feedback from our decisions?
Alexander: It’s the most critical. I’ve done a handful of different things. One thing that I run is at least every twice a year, running a survey to the team about, as a team, how do you feel? Are you able to make decisions? Are you able to get your work done? Is this process working for you? I’ve dabbled with it being anonymous and non-anonymous, but I use that to then run a retro with the team. What is inside of our control that we can change, and also as feedback into the process we set up.
See more presentations with transcripts
