Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
94. Engineering Management
Hosted by Anand Gurumurthi, with guest Marcus Blankenship.
Moving forward in your career as an engineer can seem like an impossible feat. For many individual contributors, the belief that hard work will lead to recognition and promotions is a misguided one. Two engineering managers, Anand Gurumurthi and Marcus Blankenship, offer career advice on how to ask for feedback and get your contributions noticed.
Anand Gurumurthi, a Director of Engineering at Salesforce, is joined by Marcus Blankenship, a senior manager at Heroku Salesforce on the Runtime Networking Team. Their topic for this episode is to provide career advice for experienced engineers looking to advance their career.
There are several all too common scenarios individual contributors face, which Anand and Marcus discuss and offer their perspectives for. These include learning how to ask overcoming bias on your own work and figuring out how to better assess your strengths and weaknesses. In addition, Marcus and Anand discuss getting over the fear of asking for help. They agree that showing an active interest in finding out how a system works is a good way to show that you're engaged in your work and want to grow.
In summary, confidence in the workplace is the key to getting what you want. Whether you're looking for a promotion or want to better understand a problem, you are in charge of starting those conversations. In situations where you're looking for guidance, ask for specific feedback from people who want to help you.
Anand: Good morning, good afternoon, good evening, everyone. Hope you're staying safe with you and your family during the pandemic and also the wildfires that everybody in the West Coast is battling. My name is Anand Gurumurthi, I am a Director of Engineering at Salesforce, and today with me, I have Marcus. Marcus, do you want to introduce yourself?
Marcus: My name is Marcus Blankenship. I'm a senior manager at Heroku Salesforce on the Runtime Networking Team. And Anand, I have to say, I'm really excited about this.
Anand: Me too. So this is a common favorite topic for engineers and engineering managers, and it goes something like this. So from an engineer's perspective, if I'm as good as I think I am, why is it hard for me to move forward in my career? So let's think of this podcast as a career advice from engineering managers to fellow engineering managers, and also for engineers on how they can structure their careers to get what they are looking for in their jobs.
Marcus: Anand, I want to kick off with a quick question I'm going to surprise on you. When you were an engineer, did you ever feel this way?
Marcus: So let's see, we got a pile of questions here. You want to pick one off the top and toss it out there?
Anand: Sounds good. All right. The first one is the, "I'm great and nobody is paying any attention," scenario. A couple of ways that I've seen this manifest is you work really hard and you think that you're ready for the promotion, but you're not getting promoted, but others around you are. And another way that I've seen this happen is you're not getting recognition for the work you're doing. So what are your thoughts about that, Marcus?
Marcus: First, I think it's a tough situation to be in because there's nothing more frustrating than feeling like you're doing good work and feeling passed over. So this one really hits me. I remember, as an engineer, I felt this on multiple occasions and it really started to generate a sense of confusion. And I think I actually went to my boss, whose name was Melind, and I kind of just laid it out in frustration and he gave me some advice. He said, "How visible is your work to the stakeholders? How visible is your work, maybe your team knows, but how visible is your work to your manager and even to the end users and the people that have asked for it?" And I realized that I had kind of just been assuming that if I did great work, everyone would clap and cheer and I didn't have to do anything more after that. And he started to help me see that that probably wasn't enough.
Anand: Yeah, that sounds very much like we, from when I first started my engineering career, I was having the very same reactions, like, "Hey, I did amazing work," and I was waiting for all the appreciation, but nothing came along. And I had an excellent manager and mentor who helped me understand that this is a teamwork and it is, how can you rely on your team and your team members to help understand what you're doing? Again, I think in this scenario, what a lot of people are looking for in the attention phase, my guess is the positive reinforcement in the form of a positive feedback, that, "Hey, you did a good job," right? Everybody is always interested in getting feedback, it always helps them. That was the realization that I had when I was looking for the recognition or attention after doing some work.
Anand: So I guess my advice in this scenario would be asked for feedback, just like, Marcus, you said you did, go talk to your manager or your peers or your mentors or anyone that you feel comfortable with and ask them for specific feedback, "Hey, I recently completed this project, do you have any feedback for me?" Always one of the other things that I've noticed, and I'm sure you have as well, when you ask people for specific feedback, they are always more open to sharing feedback, both constructive and positive rather than a, "Hey, how am I doing?" Right?
Marcus: Yes. And when I started the process, I didn't do it very well. I would do the, "How am I doing?" Or, "Did you like the way I did this?" And I realized the more valuable question was to kind of adopt the business mindset and to ask people, "What was the value that came out of my work?" Because when I started to keep track of not just that I had delivered something or that people liked working with me, because I used to think that's how you got promoted, but I started to keep track of like, "Oh, I just added X amount of value," or, "I reduced overhead by Y amount per month," or whatever it was, when I saw the value of my work, I felt like I started to be able to build a better understanding of the impact I was making and I had a much clearer case to start building when I wanted to talk with my manager about the reasons I felt I should be promoted.
Anand: Yeah, and it is always a good idea to keep track of this, not just as a promotion building case, but also for you to self calibrate, "Hey, am I solving the same caliber of problems that I was last year? Or am I seeing a trend in the direction that I want to be moving towards?" Right?
Marcus: I love that because it is really easy to... There was a phase of my early engineering career where I got tasked with writing a lot of reports and I thought I got really good at it but as you mentioned, now as I look back, I was only good at that one thing. And a year later, I think I'd kind of gotten stuck. So I wish someone had given me that advice to ask, "Where are you currently developing? Where is your skills growing?"
Marcus: I think one other thing that comes to mind here to be honest is I have had engineers and Anand, you tell me if you've ever had this, that sometimes self-assessment is really hard. So sometimes engineers feel they are doing an excellent job and they look around and they say, "I'm as good as everybody one or two levels above me," but the engineering manager does not share that view. In fact, it's really because it's not an accurate view. It's kind of a bias that we hold. I think we all do hold this bias. Do you have any tips on how we can like calibrate? If somebody thinks they're really good, that doesn't mean they're actually as good as everyone around them.
Anand: Yeah. I think that's a very, very common scenario that I'm sure everybody is facing. And we did face this here at Salesforce and in Heroku. So one of the things that we started doing for this one is doing a self assessment based on our career ladders, right? Every company has a career ladder for what it looks for in a senior engineer or a lead engineer or a principal engineer. And the hardest thing for us to do is to go self-assess us against the role that we should be performing or the role that we are looking forward to. In case I want to get promoted, you want to understand what the next role looks like, right? So today we have, again, I wouldn't say we have solved it, but we are working towards it, is looking at a career that could be define centralized career ladder across engineering and having the engineers do a very honest self assessment of it.
Anand: And the way we do it is the engineers do their version of the self assessment, the manager does the assessment of how they think their direct report on this person is doing, gather feedback from their peers. We do it in a quarterly fashion that we ask like, "Hey, personally, you've been working with person B for the last six months, what do you think are their strengths? How are they performing against these specific things in the career ladder?" And you get a belt of data from that, right?
Anand: And then it is always hard to find out the areas that you need to focus on, but I have seen so much success that people who are doing the self-assessment, the manager's doing their assessment and the feedback from their peers collect it all together, and then you can start seeing gaps, right? So for example, let's say I'm a lead engineer, and I have some stellar examples that I can think of in the last six months of delivering projects, but one area where I am struggling to find examples, my manager's struggling to find examples and my peers are could be something like mentoring a junior engineer on the team, right?
Anand: Doing this type of assessment helps you understand where your gaps are and it allows you and your manager to come up with areas on how you can get better at it. Some of these things you can easily do, some of these things make your manager accountable for bringing those opportunities to you. So what else am I missing there, Marcus?
Marcus: No, I think that's absolutely brilliant and so important. If you want to be promoted, you must clearly understand the requirements of the level you're trying to get to. So you have to own that responsibility. I don't think at most companies these days, maybe very small ones, but most companies, if I were an engineer, I would no longer expect that it would happen by magic. It happens, I think, by intentionally knowing what the standards are, working to those standards, getting feedback, assessing yourself and asking others for that feedback and then creating those action plans to fill those gaps. And if you're still not getting promoted, I think then it becomes a different kind of conversation because there may be some implicit cultural expectations that aren't even written down and you and your managers just need to have a really honest conversation about those.
Anand: Very true. Ready to jump on to the next one?
Marcus: I am. Let's see. Okay. How about this? "I don't feel like I can ask for help or people are going to think I'm not delivering and this impedes my ability to get promoted because it really impedes my ability to learn and grow and even do work." So Anand, what about people who feel like they can't ask for help or they're going to be looked upon as dumb?
Anand: Oh, wow. Yeah, I have been in this situation. I don't think I'm fully cured, I still feel this way. But one of the things that I think helps here is leaders leading by example. I have seen really successful executives at Salesforce and other places, when they are given a problem, they are not afraid to say, "I don't know." The leaders leading with vulnerability, I think, is really critical here in setting the right environment for the team that builds a psychologically safe environment where if a leader is proving time and time again that it is okay to be vulnerable and saying that I don't know and asking for help, nobody is going to look at them as incompetent. It is actually the reverse, they're like, "Hey, wow, this is really good to see in a leader that they say and are honest that they don't know." And I have always seen that when people come to me or others, when they say, "Hey, I don't know, can you help me?" They're always going to get the help that they need.
Anand: So my advice would be, if you think that, hey, you don't know something, it is okay to acknowledge that, it is okay to acknowledge that you don't know something and that you need help. So talk to your manager, talk to your peers, talk to people you think are amazing at it and see how they have the scenario in the past. How have you handled this in the past, Marcus?
Marcus: As an engineer, I found someone I could trust. And oftentimes it was another senior engineer and I would build a relationship such that I could go to them privately and say, "I don't understand this requirement," or, "Okay, I am totally confused when we're talking about how to deploy this thing, can you just take 30 minutes and help me?" We did have to have a rapport for me to feel like I could trust the person, but that wasn't that hard to create. They had also been in my shoes within the last couple of years. They oftentimes, in fact, they always remembered and they would say to me, "Oh yeah, that's super confusing, our documentation's terrible," and then this is my favorite line, "And you had no chance to understand it." I mean, hearing that was like, "Oh, what a relief!" Because inside of course my big fear is that I'm an idiot and everyone else is going to find out and I'm going to make myself look stupid.
Marcus: Then I remember actually asking other people, "How do you know what you know, and how do you find out what you don't know?" And I started asking my boss and I started asking in team meetings. It was pretty awkward at first because nobody wanted to admit that they would ever not know something, but slowly, frankly, that one question of how is it you know what you know, and what do you do when you don't know, started to kind of make it a little safer to talk about, I think. And in time, people started to accept that not knowing something was not a deficiency, it wasn't a sign I wasn't a good engineer or wasn't ready for promotion. And there was some stuff I was looking at in our notes here like, are you too busy to do training? Do you feel like you just have no time in your day and you have to talk to your boss about carving out some time to learn stuff? Half the time, I just need to go for a walk and be able to think sensibly.
Anand: Yeah. One of the things that I've been sharing with my team is that if you're not taking the time during your work days to get more training and learn new things, you're solving the same problem that you have been solving all along and that is not really helping you grow, right? So one of the things that I'm encouraging other engineering managers that I work with, and also the engineers is when you create your career plan, always make room for learning new things. It's probably automation, what you're working on or learning a new technology or reading about a behavioral change that you can implement in the team. It can be anything. So always make room to get the training and learn. Learning always should be the number one goal.
Marcus: It's funny, we're kind of in the learning business, aren't we? I mean, because anything that's written today is going to be replaced eventually and probably in a language or technology that's different than it's written in today. I fully believe that many people listening to this podcast work for managers who are not as super cool as you and I are, and those managers might have the impression that the person, they know everything they need to know, it's just about executing. But I think without it not acknowledging I don't know where to go look for help and I need help with that question, you're going to be stuck and probably feel pretty scared. So you may have to take a risk and just ask it. And again, I think the meta question of, "Boss, how did you learn what you know?" is a nice indirect way of getting to some of that.
Anand: Alrighty. So the next one is, "How do I not sound desperate when no one else is having issues, or is this a, oh, this is how things just work here?" So the status quo problem, if you will.
Marcus: Oh, you're confused or frustrated or you feel like things aren't great, but everybody else seems to be just fine with it?
Marcus: Woof, that sounds like rocking the boat a little bit. I think the first thing, and you've been at Heroku Salesforce a long time and I only joined about eight months ago, so I had a lot of this feeling when I joined the new organization and I had to take a step back and I had to say, "Look, I guess I don't know how everything here works, but I'm going to trust that a lot of it does work, even if I don't understand why." And I had to really kind of reset that with, it was very frustrating to not understand everything and trust that these practices, these things that I'm hearing about, the problem is not out there, but the problem is my incomplete understanding of them.
Marcus: And that was actually really hard because I wanted to either understand it or I wanted it to change to be a way that I agreed with. And it's taken quite a few months now for me to really indoctrinate it and get the culture and how all these different things fit together. And I think that's why I see many people around me as like, they're worrying about the problems that are actually problems and maybe the problems that can be solved and other kinds of problems or other kinds of situations, they're not really thinking about so much.
Anand: I know, I always use the, "Oh, I am still new here," even though this is year nine for me, at Salesforce and that has always worked for me. If you say that, "Hey, I don't know," again, building on what we talked about earlier, right? "Hey, I see that we always do releases this way," for example, and ask the question of, "Why do we do this this way? What is preventing us from doing it better?" Right? Again, not in a questioning what is the processes in the team, but more like you said, like, "Hey, help me understand why we do things this way." As always, again. This is one of those hard ones where it's uncomfortable to talk about it, but I'm hoping that if you are one of those brave people, lead by example here, ask for questions on, "Hey, let's talk about why we do X this way or Y that way," and maybe you will solve the problem that you didn't even know that you had.
Marcus: Oh, that's so true. Anand, have you ever asked why and then the person has said to you, "Well, I'm not sure, we've just always done it that way"?
Anand: Countless times.
Marcus: And it's a really nice realization that you're not the only one that doesn't know why and maybe there's an opportunity for the two of you, whoever you're asking, or maybe the larger team to just say, "Let's consider if this is still the right way, if this is the way that makes the most sense to us now, because it seems that this decision got made so long ago that nobody was even here and we don't even remember why we made it."
Anand: Yeah. Oh, that's an everyday scenario.
Marcus: It does require a certain amount of bravery. I think you kind of picked up on that. I was in a meeting the other day and people were asserting facts and everyone like, "System X does that, well System Y does this other thing," and they all knew what it meant, why those were important statements and I didn't. And I had to say, "What is the implication of that?" And it felt really dumb because everyone else knew, I felt like, but I didn't know. And when I asked that question, half the people paused and they said, "Well, I'm not quite sure, I just know it's true." And it's easy to start talking about facts when we really need to be talking about the why, or we really need to be talking about the ramification of those facts.
Anand: One of the things that my team does really well that I started to like is they take time every week or every other week to look at a system and just do a group learning. So let's say we have a control plan, they say, "Hey, let's take a couple of hours this week to just walk through the code and see why it is built this way, what problems are we solving with it?" More of a taking the system and writing the requirements document. And I have to say, it has brought some really good questions forward in terms of like, "Why do we have this?" And we have projects now because it could be just an experiment that we did and we just didn't clean it up after ourselves. So do that in your teams, make room to do that in your teams.
Marcus: All right, Anand, I think given time wise, this might be our last question today. So I'll toss it out here. "My ideas are never the ones selected and I feel like nobody takes me seriously."
Anand: Man, this is a tough one and a good one to spend some time on.This has manifested in multiple different ways and one of them being a conscious or unconscious bias, I had seen this especially show up in female employees or employees who are from underrepresented minorities that for example, they would say they would have an idea they presented and nobody say yes, and then someone else thought the same thing and everybody's like, "Wow, that's a great idea." I have lived through that, I'm sure you have seen that happen, Marcus.
Anand: Yeah. So again, my recommendation to you would be if you're one of those people who have witnessed this, stand up against it, this is not a inclusive workplace. And if you're a manager, pay more attention to this, this is something that I think it should be part of every manager's job requirement is to make it a safe space for everybody in the team to feel safe to share what they think. Even if it's not a good idea, right? I am a strong believer that no idea is a bad idea. Even if that is not really solving this problem, maybe it's sparks an idea in someone else, right? So you cannot have an environment that people don't feel safe sharing it. So if you are an engineer that is impacted by this, go talk to your manager, make it a visible problem, make it their problem to solve. And if you are an engineer that sees this happening, be a strong ally and make sure that this does not happen in your team.
Marcus: One of the other pieces of advice that we've written down here in our notes is to write it down because maybe the way you say it, maybe the time you said it at in the middle of a meeting, maybe it was at the end, maybe it was near lunchtime, there's a lot that gets in the way of communication. If you believe in your idea, I would suggest to you that you write it down and then you circulate that written idea in something like a Google Doc or a collaborative document around and ask others for feedback. And I think what that does is it forces you to really think through your idea. I do this a lot and frankly, half the time I throw the idea away because I see the problem with it after I'm done writing it. And I now understand what I'm proposing and the ramifications so it was an important exercise for me, but I'm just such a believer that writing things down is a much better way to convey ideas, both for you and for others to consume than just talking in a meeting.
Anand: To add on that if you still think it's a good idea and if the team's not taking it, write it, present to the team and ask for feedback, right? Because there is something that they see that you're unable to see, and we all are accountable and we help each other in sharing that. I think it is required for all of us to do it. So if you think that, "Hey, this was the idea that I proposed, it seemed like this is not the way we want to go, but I didn't receive the concrete reasons of why it is not a good idea so would you be willing to share feedback on what are some of the flaws that you see with this idea so that it can help me become a better person?" I think we owe it to each other to be open and talking about this one.
Marcus: And I think that any teammates in any company or environment would be responsive to that because it really is an appeal to help the person grow. Sometimes you have to be okay with your idea not being selected, but I think you could always expect if you've taken it seriously enough to write it down that others should take it seriously enough to tell you why that idea is not suitable for the current situation. The more you put into the writing, the more seriously it appears that you're taking yourself. I think that's an important signal to send.
Anand: Absolutely, yeah.
Marcus: We have covered a lot. Let's see some highlights. I feel like one of the highlights I heard is in order to get what you want, the promotion, you may have to be a little braver about entering into some conversations you're not having now.
Anand: Yeah. One thing for me is I think again, do not hesitate to share your ideas. Even if you think that it might not solve the problem, it might spark an idea or people might be able to build on top of that. And feedback. Always, always ask for specific feedback rather than generic. Again, it can be for promotion, it can be for things you want to learn, it can be for an idea that you had that was not selected. Asking for specific feedback has a much higher response rate and willingness from the other person.
Marcus: And Anand, I want to go back to one of the first things we said, you owe it to yourself to understand the career ladder. You cannot allow it to just be vague in your mind. And that may mean you have to go talk to those people that have already reached that level and ask them about how they got there and ask them about examples and stories, what does this one line need? If there's something in the career ladder that seems very hard to demonstrate, ask them how it was demonstrated and ask your boss as well. Your boss, I believe, seriously will want you to be successful because these days, careers are a type of currency. They are so important that employees are considering what their career is going to be and every manager, and I promise you this, would rather help you get promoted where you're at than see you leave to get that promotion.
Anand: Yeah. And one of the other things that I read recently is you are the CEO of your career. So if you are not investing in it, it is really hard for your manager to come and help you with it. But if you have a clear idea, that makes the manager's job a lot easier to help you get where you need to be.
Marcus: As managers, I think we both would agree, people who help us help them are going to be more successful more quickly and more easily, just kind of as a natural effect.
Anand: Absolutely, yeah.
Marcus: Anand, I'm so glad that we could chat today. Thank you for having me on the show.
Anand: Oh, thank you so much for joining Marcus and thank you everyone for joining us and stay safe and take care.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
More episodes from Code[ish]
Robert Blumen and Marcus Blankenship
How can developers learn from catastrophic errors such as airline disasters? Learn how understanding the root causes of failure in complex systems can prevent their recurrence. →
Karan Gupta and Marcus Blankenship
How can applying the right technology choices at the right time impact your coding and business choices? Karan Gupta explains how practicing “pragmatic engineering” can have an oversized impact on business and business efficiency. →
The episode focuses on managing a certificate authority (CA) within an enterprise. The internal CA is compared on many points to PKI on the public internet. →