Transcript
Schirmacher: I want to start out by introducing you to a very special person named Devin. This is a picture of Devin. Devin is special to me because he's the first staff engineer that I ever managed. Unfortunately for him, I mismanaged him. I did not give him the information or the context that he needed to do his job at a high level. To make matters worse, I thought it was his fault and I even considered letting him go. Devin and I had a really tumultuous relationship. He was the type of person who would just let me know whatever he was thinking with little to no filter. I remember one time he even shouted at me and asked, are you stupid, Adam? Imagine saying that to your boss. That's just who he was. I'm happy to say that we did turn things around. In the process, he taught me a lot about effectively managing staff and staff-plus engineers. He went on to do some pretty great things at my company, Gusto. He built and rebuilt parts of our payroll platform, that processes billions of dollars per year, and probably pays some of your paychecks. Even though I'm admitting I made some mistakes, I don't beat myself up over those mistakes. Because the truth is, managing and for that matter being managed is hard. I would argue, at the staff level, it's even harder, or at least a little bit different than what I was used to. While I'm admitting these things that are painful for me on stage, I want the folks, if you're a manager, think about who is your Devin. Who is that person that you wish you could go back, do some things differently? If you're a non-manager, I understand we might have people who are staff engineers, maybe above, maybe you're hoping to get there, honestly, maybe you're not sure where you stand, which is actually pretty common, too. I want you to think about times where your needs were not met. Maybe that time is right now.
I'm going to be sharing some stories about how I learned the three most important elements in my mind of how to manage staff engineers effectively. Those three things are sharing context, raising your expectations, and fostering self-awareness. I think if you get those three things right, you can build better products and have more resilient teams, especially when you're managing through tough changes. I've been a lead of lead. I've managed probably 5 to 10 staff engineers, depending on how you count things. Also had to fire people. I've had to promote people. I've had to demote people. I've done a lot of different things. I'm currently a staff engineer right now. I'm here to just share my experiences and hope that you can learn from them.
Context Sharing
We're going to start out double clicking into what I said was, in my view, the most important thing, that's sharing context. This started with Devin, this was right before COVID hit. This is February 2020. COVID was in the news, and we were like, maybe we'll have to go home for a couple weeks. It didn't work out quite that way. My company had gone through this big reorg. Suffice it to say it was pretty unpopular among the people. We've all gone through these things. No reorg is really popular, but this one was really painful for a lot of people. Devin was really vocally unhappy about it. That is how he came to report to me. I was moved from a frontline manager to a manager of managers' position. Devin was, again, the first staff software engineer that I had ever managed. Our first one-on-one, I remember sitting in the corner office in Denver, thinking, this is going to be exciting. I'm always excited to meet new people, manage new people. I'm sitting there thinking about how great this could be. He walks in, first words he ever says in our first one-on-one ever is, "Adam, what do you think about this stupid reorg?" We've probably often had people that are this unhappy about things. I tried to tell him everything. I told him all these reasons that were shared in email, shared in announcement. We're going to improve communication. We're going to align teams whose work is closely related. All these things that he had already heard, but he just wasn't buying in. Our first one-on-one was that difficult.
Our second one-on-one was also that difficult. He had the same challenges. I gave the same responses. It felt like we were going nowhere. By the third one, I was getting really worried, because I was starting to hear from other people who were not even Devin and just worked with him. They were saying, "I talked to Devin, and he seems really upset about this thing. Now that he said, I'm upset about it too." Started becoming this negative influence. I don't discourage people from talking to each other, and having concerns, but this was a done decision. We're not going to dereorg. We're not going to roll back the commit. We had to find out how to move forward. I said to myself, I need to shake things up. I need to try something different with Devin. I wanted to do a walking one-on-one, which I've done many times in person. It's great. You just go for a walk with someone. Go walk around the streets of San Francisco or Denver, or whatever. COVID had just hit so we couldn't do that. I put in my headphones, he put in his headphones, and we did it over the phone. We did a walking one-on-one in our neighborhoods, and it still had a remarkable result.
I finally had to confront Devin. I said, "Devin, I'm sorry, I know you're unhappy. This is going to be a disagree and commit for you. We can't go back. There's nothing I can do. You just have to figure out how to get past it." I took a pause. In that moment, I was so nervous, because I thought Devin was going to explode. All he said was, "Adam, just tell me the truth." I thought, just tell me the truth? Here's the thing, Devin is a perceptive guy. He knew that I wasn't telling him the whole truth, just as managers often cannot or do not tell the entire truth of things. I said to myself, I got to just level with him, so I spilled all the beans. When I say spill the beans, we had this reorg. We had all these nice public reasons about communication. We had these not so nice reasons. There were teams underperforming. There were products that we were considering cutting. There were serious communication issues with certain individuals. Those were the things that we didn't say out loud. I told them all those things. I was worried he was going to call me a big, fat liar. Say that I was the worst manager he's ever had, but he just said, thank you. We ended the one-on-one early, which is something we had never done before.
That night, I remember thinking, what is going to happen next? Is he going to tell the whole team that I can't be trusted, that I'm not being honest with them? What's going to happen? I barely slept. In the morning, I woke up, and I checked Slack first thing in the morning. I know I'm not supposed to check Slack first thing in the morning. I checked Slack first thing in the morning, there's a wall of text from Devin. This in itself, wasn't unusual, I got those before. This one was different. I started reading it and it said things like, if we want to avoid that same communication issue that prompted the reorg, maybe we should do XYZ. He had suggestions of how we actually do better. I had never heard this from him. It was in that moment that I realized I messed up. I was thinking about letting him go and I thought, maybe I should be let go. I should have told him this way earlier. As we went on, I kept sharing more context with Devin. He kept eating it up, and I kept seeing good results from it. I invited him to leads' off-sites. I shared with him some gory financial details, everything I could. Devin became an ally rather than a challenger.
I look back on this and I think, what did I do right, what did I do wrong with Devin? The big thing that I did wrong was I tried to protect Devin. My heart was in the right place, my head was somewhere else. The thing that I will give myself credit for was the walking one-on-one did generate a different result and it helped us make a breakthrough. I want to talk for a moment about my philosophy now on how I share information. You may have heard this analogy before of a manager being an umbrella, protecting people from all the bad things coming down. I try to be a transparent umbrella. Like this little girl, she's not going to get wet but she can look around, so I want my staff engineers to look around and be able to understand what's going on in the business. That's my philosophy now and it's really helped me in a lot of ways.
Lastly, on this topic of context sharing, I want to highlight a few places where I think most staff engineers crave more information, and they can do better work if they get it. The first is any performance evaluations. Most companies have some process. Managers sit around, they say, how valuable was this work? How valuable was that work? Who's going to promote it? Who's not? Having staff engineers in that room is very valuable. I've personally aimed for about a one-to-one ratio of managers and non-managers in those forums. The second thing I want to highlight is any staffing plan, when you're thinking about what skills you need on your team, how many people you need to hire, whatever it may be. Unfortunately, these days, it could also be layoffs. I hope not, but that can happen. The third thing I want to highlight is any org change, like I talked about with Devin. I think when you share that context with people, they can, not just be non-challengers, but they can actually be advocates and help you make good decisions. Lastly, financial details. In my experience in smaller companies, these often matter a lot, whether it's your runway, whether it's how soon you want to be cash flow positive, what-have-you, I say share those details. Then your staff-plus engineers can actually help you do a better job. Again, I want to go back and address, some folks might not be managers, I say look at this list. These are things that you can ask to be involved in. You can go to your manager and say, I met this guy named Adam and he said, you're supposed to invite me. Maybe it'll go somewhere, maybe it won't. That's Devin.
Raise Expectations
Next, I want to share what I believe is the second most important thing in managing staff engineers, that's raising your expectations. I want to do this by introducing another special person named Vikram. Vikram and I met about a year after I met Devin. He was an internal transfer from another team. He'd been at the company for a few years, and he was looking for something new. When I first met him, I did what I call like my intake one-on-one. Most people have some version of this. You get to know someone. I would ask things like, what are your goals? What do you like? What do you dislike? What was the high point of your career, or low point of your career? I figured out through that conversation, he just wanted to be somewhere mission critical. He wanted his code to really matter. He would say, I want it to matter if I mess up. He didn't always use the word mess. I had just the thing for him. This was a great match, because my team, again, we're managing the core payroll product. This is our bread and butter. We are doing this big project where we're refactoring our tax engine. Turns out when you work in payroll, everything is just about calculating taxes and paying taxes and collecting taxes, everything is just taxes. I set him on his way. I introduced him to the team, and he got going. Within a few weeks, I started getting good feedback from folks. They were saying things like, "Vikram pointed something out in my PR that I didn't even know to look for," or, "Vikram really helped us with this retro and it went smoother than it's gone before." Needless to say, I was really happy. My emotions were up here. Great point in the managerial career.
One fateful day, it's a Monday, I'm sitting on Zoom. I'm talking with some other managers, having lunch, and my phone goes off. I have a special ringtone that's just for PagerDuty, and this was PagerDuty, so it immediately sent chills down my spine. Gave me an adrenaline rush, much like I have at this very moment. I looked at my phone, I'm like, "If I'm getting paged. I'm a manager of manager. I'm a few levels up. This is really serious." I go check out what's going on, we had a site outage. In our business, a site outage is just the worst. It was caused by an engineer under my purview, who had submitted a change that involved an unindexed query to a database. It brought the database to its knees. We had about 20 minutes of outage until it was rolled back. Then, unfortunately, we had a really big data cleanup after that point. Now I'm right here, I'm at a medium. I've been brought down a little bit. That Thursday rolls around, another serious alert. This time, it was a business logic error. It was an error in calculating travel reimbursements for New Jersey residents. I care about people of New Jersey. I want them to get reimbursed for their travel. This was another big incident. Joking aside, it really matters to get this stuff right. This incident is going on, and I'm down here. Remember, this is peak COVID, before the vaccines. I've people in my one-on-ones crying because they lost people to COVID. I have people who have COVID themselves. It just seemed like everything was going wrong.
Of course, my boss contacts me. He's a great guy. He's like, "Adam, what can I do to help you write more stable code?" He has a big heart, but nobody wants their boss to have to ask them that. I'm really in a panic. Much like with Devin, I decided to try something different. I sat down with the other managers in my org, and we decided to interview everyone. We would go around, we'd ask them some questions. Do you agree that our code currently has stability issues? Why do you think this happens? What can we do to support it? We started doing these interviews. Luckily for me, I got back to Vikram, and he stopped this whole process. Because I asked him these questions, and then he asked me the most important question. He said, "Adam, why are you doing this?" I was like, "What do you mean, why am I doing this, like code is unstable. Code needs to be stable instead." He said, "No, why are you doing this?" I said, "I don't know what the alternative is." Then he said the four words that every manager longs to hear. He said, can I own this? Those are beautiful words. It brings a smile to my face, just hearing them for myself. I said, of course, you can own this problem. I also said things like, "Thank you so much, Vikram, you are such a saint. If you change your mind, let me know, I can take it back if you need any help at all." I went on and on because in my mind, it was an act of charity. I thought he was offering to do something way above and beyond. I know it's a bit sad. I know it's a bit pathetic looking back, that I just simply didn't know I could expect out of him. Even though he was a staff engineer, and I worked with other staff engineers, I had never worked with someone with the appetite and the capability of owning that cross-team stability problem.
Now this was Vikram's problem. He handled it quite differently. He said, Adam, "Stop the interviews. Let me handle this." He said I want to be invited to every post-mortem and I want to be free from all my normal project work. Easy things to grant for me as a manager. He went around and he paired with everyone. This is actually something that I try to emulate to this day. He pair programmed with everyone as his day-to-day work. He saw where people were missing certain skills. They could be things of, how to test for an unindexed query. How to look at a query plan. How to use certain internal tools that we had. He came back to me and he said, "Adam, I think I know what's happening. People just don't know what they don't know. They just need to build some of these basic skills," but we have deadlines. He said, "Adam, people aren't going to feel free to work on these skills right now unless you say so." I knew what to do. I had heard this concept of lending authority. I sent a big email to the whole team. This is about 25 to 35 people at this point that are reporting through me. I said, "Everybody, we have stability problems. I would rather move a deadline back because we took the time to avoid an outage, than move a deadline back because we had an outage. Vikram is going to be setting up some workshops. He's going to be working with people on how to do some better testing practices, just how to avoid more outages, and I expect you to go to them. I expect your projects to be later than they otherwise would have been. That is explicitly what I want from this team." With that endorsement, Vikram went ahead and set up these workshops. I wish I could tell you that it forever eliminated all production outages, it just didn't. We did avoid repeating the same mistake twice. Everyone on the team agreed that they learned a lot. I learned a lot through this experience, too.
Looking back, what did I do right? What did I do wrong? The big thing that I wish I could have back is just I wish I could go back and ask him that right away. Day one, say, "Vikram, you are a staff-plus engineer. I have this big problem across my org. I want you to handle it." I can say that now. I didn't know that I could say that at the time. The thing that I will give myself some credit for doing right is that I lended authority through that email that I sent out. I want to double click on this for just a moment. You may have heard this term, influence without authority. I'm not knocking that term at all. In my experience, it's hit or miss. It only works insofar as someone's trying to influence them, influence someone else, along their goals. If they're trying to go against them, it doesn't work. If someone's trying to ship a feature by Friday, and they're over here saying, learn about monads and microservices. They can't have that kind of influence. You have to be able to give them the authority to actually get things done and get things changed.
Lastly, on this topic, I want to, again, highlight a few opportunities. These are things that I believe you can ask staff engineers to do. They can own big org-wide, multi-team problems. They can address cultural issues. They can also handle technical roadmapping. I'm not a manager of staff engineers at this point. I am a staff engineer. I expect to be given tasks like Adam, own our technical roadmap, you own this whole thing now. Not just giving input. The last thing are these really big ambiguous problems. I don't know if this comes up for other people. I'd love to know. In my company, every now and then something comes along. It's like, Adam, you have to build X. Nobody can really tell you what X is, or what the goals are, or who the customer is. These days, I expect people at the staff-plus levels to be able to take that whole cloth and figure those things out. Again, if you're not a manager, if you're a staff engineer, or maybe you're hoping to get there, these are opportunities where you can go and say, "I want to own this."
Foster Self-Awareness
Lastly, I want to talk about the third most important element to managing staff engineers well, that is self-awareness. We're going to do this by meeting another special person to me, this is Maria. Maria and I met through our company's internal mentorship program, maybe you have these. We match people up. People sign up, and they say, I have these skills, and I want to learn this. Then someone else says, I have these skills and I want to learn that, and you pair people up. She had a problem that she was experiencing where she felt like everyone agreed with her and nobody did anything that she wanted. She felt like she knew she was supposed to have influence as a staff engineer, but it wasn't resulting in real action. She got paired with me because, being a former director, former manager of managers, I felt like I could help her with that. I'll give a little bit of a sneak preview and say that she helped me as much as I ever helped her.
She shared with me some of her communications, some of the things where she was trying to get her team to do things differently. I noticed this pattern of suggesting things. If you say something like, we should refactor, it's easy for everyone to look around and be like, "Yes, great idea, we should refactor." Then everyone goes back to the work that they were already going to do. It doesn't result in any real change. I suggested to her, "Maria, try making this a concrete proposal. Something that someone can say yes to, someone can say no to, or someone can suggest changes." She took that advice but she had a little bit of a problem. In her past experience, she had been on another team. When she did things like that, she got feedback that she was pushy, or that she was abrasive. If you're in this room, and you hear me say those words and you squirm a little bit, it makes you a little uncomfortable, you're right. Those are things that she would get criticized for, and if I did those same things, I would not get that same critique. It's just a reality.
To her credit, she wanted to push through it. She wanted to figure out how to make it work anyway. I happened to know her manager. Her manager was named Lauren. I knew Lauren. I knew that Lauren had gone through things like that before. Maria asked me for advice on how to approach her manager, and I said, "Lauren's a good one, just go tell her what you've been through or what you're trying to do." She did that. As I knew what happened, Lauren was fully supportive. Lauren handled it as well as I hope every manager handles it. She said, "Don't worry. I got your back. You can do things that other people think are pushy but I will tell you if you cross the line, otherwise, just carry on." Maria took that advice, and it went great. The next few months she shared with me many examples where she suggested concrete changes to her team, and they actually took action. She could actually look back and point at what they did and said, that little decision there, that was me, I helped change our trajectory. That went great for Maria.
It turns out, I need a little dose of self-awareness too. Several months after that, she reached out to me. She said, "Adam, how you been? I have some feedback for you." This is great. I love when people give me feedback, and I trusted her. I said, what is it? She said, "You're coming off as a bit of a jerk, and that makes people not want to work with you." Tough words to hear but, honestly, it wasn't the first time I've ever heard that in my life. I tend to have a pretty direct tone. I just say what I think, and sometimes it just doesn't come off very helpful, very constructive. She pointed this out to me, and she's such a good person, she made sure that she had several examples. She was like, do you want to talk through any of these with me? She gave me some advice that I take to this day. I use all the time. She said, "Adam, with every communication, you need to tell people that you are their friend. You need to tell them that you are their ally, and you're here to help them. Maybe you are discussing an incident, maybe you are discussing something that needs to change, but they need to understand that you are on their side." That was the bit of self-awareness that I needed, and I still try to do that. That's why I say that Maria taught me as much as I may have taught her. What did we do right? What did we do wrong? In this case, the thing that she changed was she was making a lot of suggestions, but not any concrete calls to action. In my case, I had a very direct tone that wasn't always coming off as helpful and having a tone of partnership.
Lastly, I want to highlight again a few pitfalls that I've seen happen a lot. The first is not having a concrete call to action. I always think, can someone just say yes to this, can they say no to it? Instead of just nodding and nothing changes. The pattern that I unfortunately have fallen into at times is what I call the smart jerk, where you might be right about something, but people don't feel like working with you. Anyone who knows me closely knows that I'm mostly trying not to be a jerk, and I'm not all that smart sometimes. The third one that I want to point out is really applicable disproportionately to folks who have been in a staff-plus role, or an architect role for a long time. They can get so involved in documents, in slides, in presentations that other folks don't see them as a real engineer. I'm not saying that this is right or wrong. I'm just saying that it happens. Those folks, it behooves us to tell them that this is happening. Because they can't be effective if other people are looking at them and say, "That person is not on call. They're not a real engineer, so I don't trust them. I don't care about what they say." That really happens. At best, we can tell them, or at least we can tell them.
The last one that I want to point out is what I call the bottomless pit of despair. We've all been around these people. Oftentimes, it's someone who's really perceptive. They can tell you what's wrong with your deployment pipeline. They can tell you what's wrong with your hiring pipeline. They can tell you what's wrong here and wrong here. They're not incorrect about any of these things, but the net effect is that people who are around them are constantly feeling a sense of negativity. It's just bringing people down. Again, whether they like it or not, that will make others choose not to work with them or choose not to engage with them. When that happens, I tell those people quite frankly, that they're being a bottomless pit of despair.
Conclusion
In conclusion, I want to reiterate, these are the three things that I think are most important for your staff engineers doing their best work. That is sharing more context, like we learned with Devin. That is raising expectations, like we learned with Vikram. That is fostering self-awareness, like Maria helped me do.
Questions and Answers
Participant 1: How do you ensure that you don't catch yourself doing that where it's like, you're trying to lay out some philosophical goals, but no one's actually adopting them and using them, and how to find the balance of actually ensuring it's happening again. I think it's a good point to have. Writing a story to people that, you don't have to run a workshop, you have someone else here to do it, or in here with devs, and all that. I think that's the biggest thing I struggle with. Then I try to get other people in the organization to also do that of teach, show, support.
Schirmacher: There's a few things that spring to mind. One is, I think, for me, I focused a lot on trying to measure how much I'm getting through to people. I try to cultivate my loving critics, people who will tell me, "Adam, this isn't working out. You're not getting through to people," or whatever it may be. I like to ask questions along the lines of, on a scale of 0 to 10, how strongly do you believe that this is the right solution? Sometimes people may feel obligated to nod with you when you're suggesting something, but you ask them a little bit more open-ended question. Then they'll say like, I'm about a 6. Then you're like, ok, I do have some work to do here. Or if you're trying to make a change that you can actually measure. For example, how thoroughly people review PRs, which was an effort that we had at a different time. We would actually measure that, and chart it over time and see, how many comments are there? What is the time between when the PR was open and when it was reviewed? Some things you can measure, some things you can't. What I personally try to focus on is making sure that I have some people who seem like they're really truly getting it and can be the champions of that after I've gotten sick of it or moved on to something else.
Participant 2: Do you have any thoughts on limits of expectations for staff engineers? I think you talked about, like not providing enough responsibility or not providing a role that is sufficient. Obviously, there's limits to that. I've seen some of that in terms of just like letting somebody drift too far with people management.
Schirmacher: Yes, in terms of limits that are good for them, or limits that are good for the team? Those two things can be a little different. I think a lot of people get pushed towards people management just because they happen to be a good mentor or happen to make good friends on the team. I like to just know where people stand on whether or not they ever want to manage people, or at least whether they want to right now. When I was a manager, I tried to provide a counterbalance, and make sure that they didn't get sucked into things that were too people manage-y. The other thing that I've seen a lot, is a lot of staff engineers, they're so curious that they get their hands in too many things, and then they're not actually doing a good job of any one of the things. I like to set some limits there. Sometimes it's just as simple as a work in progress limit. I will talk with someone and say, you jumped on this thing. What are you going to drop? If you say nothing, I don't believe you. We have to talk about what you're going to consciously drop.
Participant 2: To a certain extent, staff engineers are very senior and you trust them to manage their own tech very effectively. Certainly, there's limits on that. I think that last bit that you talked about, that it touches on where the limits on that should be.
Participant 3: Often, when you work with senior engineers across multiple things, and they have opinions, and they care that their opinions matter. Sometimes there's more than one opinion in the team, and we don't know how to steer the ship properly, find the direction, and make sure everybody is heard with the least involvement of the manager. We don't want anybody to feel that I said something, I proposed something but my proposal did not matter, things like that. I think it always happens quite often. How do we reach consensus?
Schirmacher: In the realm of staff engineering, I generally expect staff engineers to have a high EQ where they understand where other people are feeling unheard, and they understand where other people are feeling disengaged with the process of making that decision. As a manager, my view is that, it's my job to set up a clear framework for making that decision. Sometimes people are unhappy with that. There have been times where I've had to say, "This person is the tech lead. They are going to make the final decision. You very opinionated person who disagrees are probably not going to get your way." Sometimes that meant that they didn't like me, or maybe they didn't like me for a little while. Nobody wants to work somewhere where you're constantly trying to please everyone and you don't make a decision. For me, I like to just make sure that the decision maker is clear. I will be upfront about how I'm evaluating them. If this gentleman is the decision maker, I will say, I'm going to get feedback from you. If people don't feel like you've respected their opinions, that will reflect negatively on your review. If they say that you did a great job navigating the many opinions, it will reflect positive on your review. That's how I personally think about it.
Participant 4: You spoke a little bit about awareness pitfalls, things like that, and some suggestions on how to address them. The one thing that you mentioned about staff engineers not really being seen as real engineers, being aware of that is one thing but how do you address it, or what can you do to address that?
Schirmacher: I think to a certain extent, that feedback has some validity to it. I've worked with folks who are brilliant in the abstract, but they don't understand how many constraints are down here where people are actually coding and actually committing things. To some degree, the critique that they're not real, I wouldn't ever say they're not real engineers, but it can affect their credibility in a real way. For the folks that I've worked with, and even for me, personally, I make it a point to always be coding. It doesn't always mean production code. It can be, if you have an idea for a new architecture, put together a prototype. Put together something that people can look at and click and see that it actually works as you're describing. I think the more people see that you're actually capable of building things, the more you have credibility, even if you're not on the frontlines building every single day.
Participant 5: You did say you got paged by PagerDuty. How do you manage in your head expectations of different timescales, like I've made a change, I should see something good, it'll be a month, a year. You in your head as you manage, some things that you do should pay off right away, or some things that people do, now that you've put them in a position should pay off maybe over a longer timescale.
Schirmacher: I think, especially as a manager, and this is true as a staff engineer too, a lot of things only have an effect that you can see 18 months later. That's really tough. I think of our work as a whole as a diversified portfolio. We have things that are going to deliver value next week. We have things that are going to deliver value 6 months from now. Then we have these longer-term things. For the things that are longer term, I've seen a number of things tried and a number of things fail. I've seen, for example, where you just look and say, does it look like they have the right ideas that could pay off in two years? That becomes pretty political and becomes a showmanship thing. I think, for rewarding longer term work, I personally focus on trying to keep people engaged for the long term. If they're working on something that has a two-year payoff, I want to make sure that the incentives are set up right for them to be at the company, and working on that for two years. That can mean incentive bonuses at the end of that period. It can mean different things. I try to align the incentive structure so that they're happy to stick to it for as long as it takes for the thing to show real value. That's not always possible, though, so I've been lucky.
Participant 6: Related to the story you were saying about Vikram, you had mentioned that at the beginning, you would have just given him the project and just like let him mind from there. Is there anything now that you would look for in a staff engineer to know that they're ready for something like that, besides just them saying that they're ready. Then vice versa, if someone says they're ready, and you don't think they're ready, what do you look for?
Schirmacher: On average, I see that most people are ready before they think that they are ready. When I say ready, I don't mean that they're going to be the best ever at that thing. I mean that it's out of their comfort zone, but like just a little out of their comfort zone, and it's going to push them. Nine times out of 10, I have to try to nudge someone to take on a bigger task than what they feel comfortable with. It's pretty rare that I have someone who says they're ready, but they're clearly not. I honestly don't know if that's happened to me. I think in terms of looking for the right opportunities and the right people for them, I'm not a manager these days, but I keep an eye out for those things constantly. Everyone on my team, I talk with them, and I know whether they're looking for something. I will often go to their manager and say, "This person is ready for the next big thing." Sometimes I'll get a little cantankerous about it and I'll be like, "And you should probably have them do it, or you might be doing them a disservice as their manager." I'll try to really nudge for that to happen. Frankly, I see so many opportunities abound for people to be able to step up. It's a problem of limited resources, rather than not enough opportunities.
Participant 7: To refer back to the example from Vikram, because, for example, in his case, everything was on fire, really high priority incidents, a lot had to be taken care of. How do you find that balance to delegate to the things and actually trust them to get done and not to go into the micromanaging thing? Because I noticed for example, personally, if the stakes are lower, I love to delegate and I build trust, and trust enough and can keep in check. When things are on fire, it's too easy to go with working out, it's easier for me to take care of it rather than trust somebody else to do it. Do you have any hints, tips, advice on?
Schirmacher: My observation is that, in the many companies I've been a part of, we've lost a lot of people whom everyone thought we would be dead if we lost them. Everyone thought, if we lost that person, what are we going to do? People tend to step up to fill the void. I feel like to some extent, if the stakes are high, the urge to involve oneself, it partly comes from not knowing just how much others will step up to the moment. I've so many times seen people step up and do things that I didn't even know they were capable of, because the moment called for it. I'm a bit of a thrill seeker just even outside of work, but I like seeing that things are just close to the brink of catastrophe and just seeing how much people fix it that maybe you didn't even know could fix it or would fix it.
See more presentations with transcripts
