55
Episode 55 43 min
Ask vs. Guess Culture: Encouraging Disagreement and Praising Courage
Danielle Leong, Director of Engineering at Github
00:00
00:00
“Being validated in your opinion, and being validated in the courage that it takes to speak up, is something that we should celebrate and something that will help encourage discussion in different power dynamics.”
In this episode
In episode #55, Danielle Leong shares how we can improve our emotional intelligence through cross-pollinating our teams.
Danielle has had an impressive leadership career at GitHub, where she’s now the Director of Engineering. Before joining Github, she had previously worked at Twilio as a Front End Web Developer and Diversity Co-Chair.
We talk about the differences between ask versus guess culture and how managers can make it as easy as possible for their teams to express their opinions.
Tune in to hear how Danielle explains how she runs skip-level meetings and goal-setting processes with her team.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review and share the podcast with your colleagues.
02:49
Question everything
10:00
Consent, safety and contribution
11:00
Emotional intelligence and psychological safety
13:13
Cross pollinating your teams
17:08
Ask versus Guess
23:07
Praising Courage
27:49
Hey, let’s reschedule
31:42
Goal setting and measuring goals
38:16
People want to attend good meetings
41:42
Get Comfortable with being Uncomfortable, Say Sorry and Read More
Resources
- Follow Danielle on Twitter
- Ask vs. Guess culture, Katherine Wu at Lead Dev
- The 1:1 Card Game from Plucky
- Danielle on Goal Setting for Engineers
Transcript
Aydin Mirzaee (Fellow.app) 00:09
Danielle, welcome to the show.
Danielle Leong (GitHub) 02:13
Thanks, Aydin. So happy to be here.
Aydin Mirzaee (Fellow.app) 02:14
Yeah, it’s very exciting to have you on, there’s a lot that we’re going to talk about today. What we usually like to do is start at the beginning, I know that you worked at Twilio as a front end web developer, and diversity co chair. And then you join GitHub in 2016. And today, your GitHub is Director of Engineering. So there’s a lot of very interesting things that we can talk about. But why don’t we start with the, in your career who’s been your most favorite or memorable boss, and why?
Danielle Leong (GitHub) 02:49
So I would say that my favorite boss would be Helen. So she was the first manager that I had at GitHub. And the first time I met her, this was the first time I’d ever had a woman of color, who was my manager. In engineering, this was something that was incredibly special to me just to have that sort of experience that I could look up to also literally cuz she’s like six feet tall. So I literally looked up to her. But she also was one of the most amazing coaches that I’d ever, ever had the pleasure to work with. She would ask these questions, and it would really make you stop and think and be like, wait, why am I asking that question? What do I actually need here, and then it would eventually just, you’d come to the conclusion yourself, of what actually needed to happen. And she’s actually the one who inspired me to become a manager, because I saw somebody who looked like me who was doing all of these really amazing things. And she was such an amazing coach that I was like, I want to be like that, like, that’s who I want to be in the future. Really just being able to have somebody like that to look up to and to really show me the ways of like, what management could be. Wooster was really inspiring. So Helen has always had a special place in my heart. You know, we’re still very good friends, we talk, you know, very often, all the time, like every two weeks, we have a call hanging out a lot. But yeah, she’s always been an amazing person in my life. Lynn has been another one and is another one. And Jim, they’ve all been really amazing managers in my life. And I’ve learned something from each and every one of them. That’s amazing.
Aydin Mirzaee (Fellow.app) 04:31
So, tell me about this questioning, like this, this coaching questioning tactic. Like what, what’s an example of how she would use that?
Danielle Leong (GitHub) 04:41
So sometimes I would get stuck, you know, so I was a fairly early career engineer when I had met her, and sometimes I would get stuck on a problem. And I would say, you know, like, I can’t figure out like, you know, why isn’t this person like working with me like, well, what is wrong? With this, like, they should just be doing this. And she was like, Well, what are you looking for? And they’ll be like, well, looking to solve this problem, she was like, What do you need from this person? Like, for them? To fix the problem with me? She’s like, Well, have you tried asking them like, no. So and then, and then we would dive into like, Okay, well, what, what kind of communication styles have I tried with this person, you know, maybe this person talks in a very different way, communicates in a very different way than I do. You know, maybe they have a different understanding of the problem that I do. And so, you know, maybe the solution is I need to just go talk to them and be like, Hey, can I set up some time with you to talk through this problem, and to show you why this is important to me. And it’s a priority for me in order to figure this out. And, and, you know, maybe maybe help them understand why I’m being so insistent on this particular problem. Instead of, you know, immediately going to my manager and saying, like, this person is, you know, so difficult to work with, like, Okay, well, what are the things that you have tried? And what are you actually looking out of? What are you looking to get out of this relationship? And how would you be able to get what you are looking for? From that other person?
Aydin Mirzaee (Fellow.app) 06:21
Yeah. And, you know, this is not an easy thing to do, either, right? Like, I feel like your gut instinct might be to just say, Okay, well, this is what you do. I know that person, like, you know, go do this, and that’ll work. But you always have to hold yourself from doing that.
Danielle Leong (GitHub) 06:38
Yeah, definitely. Um, you know, and especially with social media, and everything, you know, in the past, I had worked in trust and safety. So making sure that the internet is a safe place to be, it’s very easy to jump to conclusions, and to villainize the other person, and have it be a very us versus them sort of discourse. Um, you know, social media encourages that, you know, you make snap decisions based on one single phrase that’s out of context. But if there’s one thing that I have really learned from Helen is that, you know, everybody learns everybody’s living their own story. And so one of the things that she actually used to do is invite other stakeholders from around the company to our regular meetings. And then it’s something that I still try to do today, because everybody has different priorities, you know, support has a different priority, you know, product has different priorities, sales has different priorities. But if they don’t understand what engineering priorities are, then all they’re going to see is their own needs are not being met. And so one of the things that I did learn from Helen is she would invite people from legal, she would invite people from support to our mini summits. So those are in person gatherings where, you know, it’s an off site, we talk about our roadmap, we talk about all sorts of things that we are planning on doing, and she would involve them in this decision making process. So we would do exercises together to say, what, you know, what is it hard to do? You know, as a user on GitHub, what is it hard to do as a community manager at GitHub, and then we read out all these problem statements, and then we prioritize them based on, you know, what do we agree as a group of like, what’s the highest priority item, and because they were involved in the decision making process, they could see, oh, my pet project may not be as important as these other things that are currently on fire. And that helps have this understanding of, you know, we’re not ignoring you, it’s just that these other things are so much more on fire. And so that’s something that I try to bring with me with my relationships, particularly across the company, which is, these are our priorities. These are our fires that we’re fighting. Let me try and understand your fires and try to understand where they slot in together and hopefully we can all understand like, when the work can be done, and like what kind of trade offs we can do.
Aydin Mirzaee (Fellow.app) 09:10
Yeah, I think that that’s amazing. Like, it sounds like you’re just actively going out and building empathy. For me, we often talk about empathy for the user of our products. But this is super interesting to almost look at it, you know, in different departments within the organization, like trying to deeply understand them. But you’re right, like it does bring up a lot of the same sorts of concepts of, you know, what goes on on the internet. I was gonna ask you, as it relates to safety, what kind of safety principles I know, you talk a lot about psychological safety, for example, what does psychological safety mean to you when it comes to teams?
Danielle Leong (GitHub) 09:54
To me, that means that people have the ability to speak up about their needs. And they feel safe being able to do so. And they feel like their boundaries are being respected. To me, consent and safety are incredibly important because that means that people are able to contribute fully to all of the ideas that are on the team, that means that somebody is able to say, Hey, I have an idea, and somebody else could have an opposing idea. But both ideas are heard, they’re respected, we may not go with both of them, we may go with a different one. But everybody feels like they’re able to contribute fully, and that they’re not going to be penalized for who they are, or, you know, a part of their identity or something. But they’re still able to contribute in a safe and effective manner to do anything that’s on the team.
Aydin Mirzaee (Fellow.app) 10:55
Yeah. And how does that relate to emotional intelligence?
Danielle Leong (GitHub) 11:01
I would say that, you really have to be able to understand a lot of different facets about a person, or even be able to learn, you know, if you don’t know something about a person, you were able to let sit down, learn from, you know, their point of view and their lived experience, through that emotional intelligence, so that you can say, you know, I may have had these experiences, but you have had these experiences. And this is how your experience is, you know, contributing to this conversation. And so it’s really important for us to, to improve the emotional intelligence on a team in order to increase psychological safety. Because if you have the emotional intelligence to ask those questions, and to be able to learn from another person’s lived experience, then that means that you become a much more well rounded person, it means that you’re able to adapt to new situations, or new to you situations. And you can learn from somebody and say, like, Oh, I’m sorry, I didn’t realize that that meant that to you. How can I be better. And so that’s something that I really try to do, and really try to emphasize to my team that, we’re never going to know everything, we’re never going to fully be able to experience what somebody else is experiencing. But what you can do is you can say, you can ask questions, and you can ask, How can I be better? or What does? What does this mean to you? How can I learn? And how can I be better, and really just flex that muscle of being mildly uncomfortable and an ability to encourage that collaboration and encourage that relationship with your teammates?
Aydin Mirzaee (Fellow.app) 12:55
Yeah, it brings back the notion that you were talking about it, even bringing people from other teams so that you can expose them to their needs, and like their ways of working, are there other things that you would also recommend or that you can also do to increase psychological safety within teams?
Danielle Leong (GitHub) 13:13
So one of the things that I am currently trying right now is, um, cross pollination, you know, being able to move people from different teams, try moving them on to a different team and see, like, are there? Is there like different cultures that we can merge together? Are there different team processes that we can merge together here? How do we improve communication? How do we improve the collaboration? Yeah, I’ve got a couple of teams right now that report up to me. And something that we’re actually trying to do is we’re, we’re moving to engineers from one team and putting them on to another team, and they’re all pairing together. So everyone has a pair from a different team. And so one team was actually formerly from Microsoft one team is formerly, you know, old time GitHub. And so really trying to like, merge the two teams together and say, like, what can we learn from one another? What are the technology stacks that we can learn from one other? What are the team processes that we can learn from one another? And so far, it’s been going really great. Like, everybody’s really happy with it, everybody’s learning a lot. There’s a lot of free forming, you know, exchange of ideas that are happening. You know, one team is adopting another team’s ways of planning, and planning and tracking projects, and they hit a snag fairly recently, where they said, Oh, you know, it’s going, we just discovered something. It’s going to increase the amount of time for this estimate. And should we status yellow should we say like, okay, like this project needs a little bit of help. We’re going to change the status of this particular project. In the past, this team would, when not quite know how to handle it, you know, there would be a lot of back and forth, it would be hard to say, we need help. And it was hard to be flexible about those kinds of things. But with the merging of the two teams together, even temporarily, I’ve seen an increase in that flexibility, where they have said, Oh, well, here’s the process that we have on this other team, why don’t we try doing it here. And that has actually increased the flexibility of the other team. And everyone seems a lot happier, that they’re able to, like learn from one another and be a lot more flexible and continue to move quickly in this project.
Aydin Mirzaee (Fellow.app) 15:48
Yeah, I think that’s such a cool tactic. I’ve heard leaders sometimes doing this where a leader will take on another team, you know, even if it’s for a day or something. But this is super interesting to just take people from a team and put in another team and the cross pollination, as you put it, I think that’s super interesting. And something that people should experiment with. I think they might be surprised with the results.
Danielle Leong (GitHub) 16:12
Yeah, definitely. I think the I mean, the only thing that I would say about this one is, it’s easier when it’s within an organization, because this way, you know, your, your okrs. And your roadmaps can be adapted to, because you’re all reporting up to the same roadmap. So you know, one team that may have less people now, you know, their roadmap is a little bit smaller now. Whereas the team that where everybody is on where we’re all swarming on, that team, their roadmaps a little bit bigger. And so really being able to make sure that we are balancing the expectations and the roadmap so that we can say, this is the most important thing, this is why we are swarming on this particular thing. But don’t worry, the other roadmap is not forgotten. It’s not less important. It’s just going to be a little bit smaller for a specific amount of time.
Aydin Mirzaee (Fellow.app) 17:08
This is super valuable, changing subjects for a second and talking about something that is tangentially related, which is this concept of asked versus guests culture, you probably said that having an ass culture pays off, especially with distributed teams at the free to explain like what is an ask culture.
Danielle Leong (GitHub) 17:30
So ask culture is something I actually learned from Katherine Wu, her handle is at K Wu on the internet, I saw a really amazing talk that she did for Lead Dev, some time ago, where she explains that ask culture is, you know, I’ll just tell them now, it’s a very like western style of thinking, where if you have a problem, or you have some feedback with me, just tell me and I’ll stop doing it. And that tends to work for a lot of different cultures. But if you are a global company, then that doesn’t always work. Because there’s also guess culture and guess culture is something that is a little bit more stereotypically Eastern culture, where it is seen as a burden to tell or to ask for something, it’s a burden to be placed on somebody that you need something from them. And so there’s a lot of going around a particular question, so that you don’t offend the other person, you’re really paying a lot of attention to, you know, maybe nonverbal cues or cultural cues, or, you know, hierarchy sometimes, it’s something that plays a really big part of this. And so sometimes when you do have two different teams that merge together or you know, two different companies or you know, different grid geographical regions, sometimes when you merge them together, you can see some sort of conflict and friction there.
Aydin Mirzaee (Fellow.app) 18:57
And certainly with diverse and global teams, like this is something to keep in mind. Do you feel like some of this stuff also relates to maybe if you’re working with someone a lot more senior or like this power distance comes into it as well? Because I feel like if you’re more culture oriented, maybe it’s even more of a, it may feel more burdensome? If you are talking with someone a lot more senior than yourself?
Danielle Leong (GitHub) 19:25
Oh, definitely. Um, I would say that power dynamics are huge, especially as you, you know, grow in your own career. So I’m actually going to take it from the opposite direction. I think it’s a lot more important for leaders to if they’re talking to somebody who may be reporting up to them, that you shift to a little bit more of a guest culture standpoint, because as somebody who is looking up to somebody or somebody who is, you know, speaking to somebody who is more senior in their career You know, maybe an early career developer will be incredibly uncomfortable asking for anything. It’ll be too direct, it will be too uncomfortable. You know, maybe they don’t feel like they are worth that person’s time. Whereas I feel like it is very common for more senior leadership, you know, myself included, sometimes I fall into this trap of, well just ask me if you need something, you know, my door’s always open. My DMS are always open on Slack, not on Twitter.
Aydin Mirzaee (Fellow.app) 20:29
Important distinction!
Danielle Leong (GitHub) 20:31
Yeah, a very important distinction. My DMS are open only on Slack, not on Twitter. But I do feel like as we move more up in senior leadership, we expect people to come to us with problems because there’s so much to keep track of, there’s so many things that are happening, you know, we hope that our people will bring to us attention of things that are happening within the organization. But from the inverse side, it is very intimidating to talk to somebody who is that high up that chain? You know, what if you’re wrong? What if, what if you, you know, put a period and the wrongs but what if you use too many exclamation points, you know, there’s a lot of anxieties around talking to somebody who is more senior to you. And so I say, as, as senior leadership or anybody who you know, holds a position of authority, it is our responsibility to make that as easy as possible for somebody to do that, and to, you know, lead by example, and make it as easy as possible to express an opinion, if something is is different, make it easy for somebody say like, ah, I don’t know about that and be like, Okay, great. Like, please tell me like, what do you think about this particular thing? So the way that I like to encourage disagreement or encourage people to talk to me, about you know, what’s going on in their heads? Or like, why they might think something differently of a particular decision is, I will actually ask questions, and then provide a multiple choice. So if it’s particularly with low stakes things, I will often, you know, put in slack of like, Hey, I’m thinking of this. What do people think? Do we think yes? Do we think no? Or do you think I have thoughts on this line? And so just giving people those options of disagreeing on very low stakes stuff or like, offering a different opinion. That means that it’s much easier when it’s a larger decision to say something like, I don’t know about that, because they’ve already had that sort of discourse with me. So sometimes, I’ll be like, Ah, sorry about that, like, I accidentally, you know, forgot to schedule or reschedule our all hands, you know, do we want to try it on this day, or this day or tried asynchronous? And so people will be like, hmm, asynchronous doesn’t quite work, like, what do we think about this day and be like, great, perfect, like, sorry, I forgot to do that. But like, thank you, for your opinion. And then always publicly thank people for speaking up about something. Or if it’s private dm, then like, also, you know, thank them there as well. But always thank somebody for having the courage to speak up to you. Because it’s a really, really hard thing for somebody to go to somebody who is more senior than them, and say, I have an opinion, have you considered this that’s really vulnerable for them?” And, you know, that’s, I still have those sorts of moments as well. And so, you know, being validated, in your opinion, and being validated in the courage that it takes to speak up like that is something that we should celebrate, and something that will help encourage discussion in different power dynamics.
Aydin Mirzaee (Fellow.app) 23:56
Yeah, there is so much to unpack there. I think you bring up a very good point, right? I think a lot of us think that people will just come to us with problems, or if they have feedback for us that they would just come and tell us. And I think you know, and I’ve certainly had this discussion with other guests on the show as well, which is, well, I’m super friendly with my team. And so like, of course, they would tell me, but you know, you start to realize that no matter how friendly you are, the fact of the matter is that you are the manager and there’s just friends don’t fire people, managers can fire people. So it’s just, it’s just different. And so I love those two things. One is that you’re encouraging. You’re asking for feedback, you’re asking for these things, but your idea of like, actually giving people multiple choices to make it easier to disagree is actually very clever. I like that a lot. And you’re also saying that not only will it encourage them in that particular situation, but it kind of builds the muscle of This is okay. And you can do this over the course of time. So, yeah, I like that a lot because it’s very clever.
Danielle Leong (GitHub) 25:07
Thanks. Um, one. One other thing I will say that has been really helpful, especially if you’re not sure where to start in order to get that feedback. Um, Plucky is a company where I just got these really fantastic cards from this beplucky.com. And they are these deck of cards to help you ask questions in your one on ones around different particular subjects. So this is something that I utilize, particularly in skip level one on ones to ask, you know, what is something that you think we should be talking about in our organization, but we aren’t. And that leads to these amazing conversations of things that we normally wouldn’t get to, if I’m just asking for feedback. And I’m just asking, Hey, like, what could we do better? A lot of times, I’ll be like, I hear a lot of like, oh, we’re doing great. Oh, Plucky is really great, to be able to ask more in depth questions, so that you can really start digging into that. And so it’s a little bit easier on the power dynamic there as well.
Aydin Mirzaee (Fellow.app) 26:21
Yeah, I mean, it’s, and it’s also this, where can we improve? I mean, sometimes people have an answer off the top of their head, but like, normally, it’s not the sort of thing that you just like, Well, yes, obviously, all these things. [AD BREAK BEGINS] Hey, they’re just a quick note, before we move on to the next part, if you’re listening to this podcast, you’re probably already doing one on one meetings. But here’s the thing, we all know that one on one meetings are the most powerful, but at the same time, the most misunderstood concept in practice and management. That’s why we’ve spent over a year compiling the best information, the best expert advice into this beautifully designed 90 Plus page ebook. Now, don’t worry, it’s not a single spaced font, you know, lots of text, there’s a lot of pictures. It’s nice, easily consumable information, we spent so much time building it. And the great news is that it’s completely free. So head on over to velo dot app slash blog to download the definitive guide on one on ones, it’s there for you, we hope you enjoy it. And let us know what you think. And with that said, let’s go back to the interview. [AD BREAK ENDS] Speaking of your skip levels, how often do you do them? And like, do you do them in a group setting typically? Or do you just randomly reach out and do virtual coffees? How do you go about it?
Danielle Leong (GitHub) 27:49
So for skip levels, I have them anywhere between one or two, or once a month, or once every two months really depends on the health of the organization. Sometimes they’ll be spread out a little bit more, sometimes they’ll be spread out a little bit less. I have 27 in my organization right now. So it can get a little bit hectic with that many folks. So sometimes you spread them out a little bit more. And then somebody will mention like, Hey, we might want to check in a little bit more like one of my managers said, like, Hey, we’re trying something new. Can we make sure that we check in on all the engineers so that it’s going really well? Like, okay, great. That’s fantastic feedback, let me go ahead and re-up those one on ones to be a little bit more frequent to really check in with everybody. But typically, because we’re such a remote company, I will do a lot of check-ins in Slack as well, particularly if I’ve noticed, you know, that the COVID cases in India are spiking. And I know that some of the folks in my organization have family over there. So you know, check in on Slack and say like, hey, just want to make sure you’re okay. Like, is there anything I can do to help? You’d be like, no, like, thank you for doing that. And then even in between these one on ones, I’ll make sure that I check in on slack a little bit more frequently, particularly if I notice that there’s, you know, world events happening. If there’s a lot of, you know, things that might be happening, that might be affecting people’s morale. I’ll check in and say like, hey, do you want to meet up a little bit more? Do you want to skip this one? Because sometimes, you know, people might be really burnt out and more meetings does not always necessarily mean better. Oftentimes, it’s the opposite, depending on how those meetings are run, but, you know, sometimes I’ll have people I have a skip level who, who recently, you reached out to me about five minutes before our skip level and said, Hey, I’m actually not feeling well today. Do you mind if we reschedule and I was really happy to hear that because something that I am a very big advocate about is mental health. And so you know, I have PTSD. This is something that I have struggled with for a very long time, a lot of anxiety, particularly around COVID. But this is something that I’m very familiar with. And I tried to actively work that into how I manage. And so throughout all of COVID, I said, you know, even from the very beginning, I said, this is a very stressful time, your health and your safety comes first. And I said, there is a minimum floor now for PTO. So, GitHub has unlimited PTO, if you look at the studies, people are companies in America with unlimited PTO, people tend not to use it. And I noticed that people weren’t taking time off during COVID. Because they, you know, we didn’t know how long it was going to be people hoarding their vacation time, you know, to have that big splashy party at the end of summer, which never came. And so I noticed, you know, parents were burning out, people were burning out and I said, This is unacceptable, your health and your safety comes first. And so it’s very important for me, for all of you to take a minimum of one day off every single month. And that has been a refrain for the past 15 months now. It has been worked into our all hands, it is the very first thing that I say to everybody every time we meet. And so because I’m a very big, you know, advocate for mental health. This skippable felt comfortable telling me, I’m not feeling good today. Is it? Okay, if we reschedule? And that is something that is really heartwarming to me that they felt comfortable enough to speak up about their needs, and say they weren’t in the best position to meet today. Can we do this another time?
Aydin Mirzaee (Fellow.app) 31:42
Yeah. And I think like this is evidence also that you’ve done a good job of building psychological safety where people can do things like that. And yeah, I love this concept, and that you’re working it into your own hands and constantly reminding people, I think that stuff does matter. And it makes a huge difference. So one topic I did want to talk with you about Danielle was goal setting. So you have this great article that’s titled setting goals with your engineers that don’t completely suck. And with a title like that, I have to ask you, like, what, what kind of goals? Should you avoid setting? And like, what are some common traps that people fall into?
Danielle Leong (GitHub) 32:27
Oh, man, um, I mean, I would say that a very ineffective parable goal is like a new year’s resolution, where they’re way too broad. And you, you only do them at like the first week of January, and gyms are very crowded, and, you know, everybody’s eating salads and like, basically starving themselves. And then like, two weeks later, everybody has forgotten them. And then, you know, the year comes around again, and you’re like, Oh, I have done nothing to further any of these goals. Um, so I would say that’s an example of a very bad goal or very unstructured goal. For me, I look at goals, kind of like OKRs, or whatever you want to look at that you want to use. But you know, objective key okrs objective key results, there we go. Um, and I really want to make them, you know, scoped, make sure that they are small, make sure that they are achievable, and that they’re measurable. And another thing that I do want to add is I want to make sure that they are in alignment with the engineering ladders that you have, or any kind of career ladders that you have. Because if they are in any way disconnected, then it’s not actually going to further that person’s career, it’s not going to actually be that effective. And so it can be you know, preferably career ladders that are within the company, but if you don’t have them at your company, should probably start building those into your company, so that you can tether your report says goals to that and so really making sure that you make them small, make them measurable, make them you know tethered to your career ladders within the company, and also making sure that you are reviewing them on a regular basis. So when I had a smaller team, we would do this every month. Unfortunately, I can’t really do that anymore. So we review them more on a quarterly basis and we take a look and we say you know how we have we achieve this for you and your goals because I do feel like that’s what one on ones are really for. That is something that I am very passionate about, is that one on ones are for your direct reports. career. It’s not about the status of projects, although sometimes you can go over them. But it’s really about their career, and are we making sure that we are supporting them in a way that helps them grow. And the way that we measure that they are throwing is we have these goals, we regularly look at them, we have artifacts for them, we have all of that documentation that’s written down. And we can really measure, you know, you’re doing really great in these particular areas. But if we look at the career path, there are some of these other areas that we could use some improvement on. So a really great example for this is senior engineers who are looking to get promoted to staff engineer. And so this is something where I find goal setting is really, really helpful. Because when you’re a senior engineer, you’ve been doing this for a while, you understand, like the rules of the game of being a senior engineer. But a lot of the times I see there’s a big struggle in making that jump over to staff level engineer, because a staff level, at least here is at the same level as a director. And that means you have the same level of influence, you have the same level of communication skills that are required, the same level of influence already. Influence again, and and you have to be able to, you know, talk to a roomful of people and bring them along on a decision that you’ve made on a technical piece of, you know, software. And so one of the things that I do find, when I take somebody from senior to staff, is really working on those leadership and those communication skills, those delegation skills, those are incredibly important when you make that jump. And so without these goals, you can get somebody who is very frustrated, and they say, I’ve worked on these projects, I’ve, you know, put in so many hours of working really, really hard doing all of this old stuff that I’m very good at, why am I not at that other level, then I can point to these levels, these career levels and say, well, you’re you are really strong on a technical portion of this, but the leadership and the communication is where I need you to improve. And here are some measurable ways that you can improve so that we can get you from senior to staff level engineer.
Aydin Mirzaee (Fellow.app) 37:26
Yeah, that’s awesome. So you’re basically I mean, I like that these goals, goals are very measurable. It’s coordinated with the career ladder, like you said, and, and people can see themselves advancing, and they can kind of see down the tunnel, and they can see where it’s going, and that it’s possible to get there. And like, what are the steps? I like that a lot. So one thing that we should also talk about is, and you kind of mentioned it in passing, how you, you know, are a fan of productive meetings. And so some of your meetings are synchronous, and some are asynchronous. I’d love for you to just tell us I mean, we’re huge fans of productive meetings, here at Fellow. And so I wanted to ask you, what have you learned about running really good meetings?
Danielle Leong (GitHub) 38:16
Oh, man, I have learned that if you run a good meeting, and if you run an effective meeting, people want to be there, people will show up and they’ll contribute. There’s nothing worse than a meeting that is way too long that rambles on for way too long. And people are obligated to be there, they feel like they are not able to say no to this. So I actually wrote an article fairly recently on how to, I’m pretty sure the title is how to run meetings that don’t suck as much. I’ve got a theme in how I write a lot of my articles, there’s no guarantee that they will be better, but hopefully, they will suck less. And so one of the things that I’m really passionate about is, you know, if you are spending the company’s money, to bring people together in a synchronous meeting, then it better be important. And you know, we are all taking time out of our day to be in this meeting. Our job as leaders is to move things forward. And so if we are attending meetings where things aren’t moving forward, then what are we doing here? Why are we wasting time, you know, resources and energy on something that doesn’t matter or something that is, you know, for somebody’s ego, maybe. But why are we doing this? What are we all doing here? And I’ll feel like a lot of the times when you do have a toxic meeting culture, culture, people don’t know how to answer that question. So be like, well It just is like, Well, why? You know, we’re in tech, like, we’re supposed to ask this question, right? We’re supposed to, you know, question why we are doing things, we’re supposed to improve upon things that, you know, have been there in the past, disrupt the meeting culture, if you would. And really, you know, ask ourselves, what are we doing here? What are we hoping to achieve? And so, if I’m in meetings that don’t move the needle forward, am I really doing my job? I’d say No, I’d say that my job at the end of the day, is to unblock people and unblock projects and to move people’s careers forward. That’s what I’m here to do. And so if there is a very inefficient meeting that is just there, it’s reoccurring, it’s way too long. There’s no agenda to it, there’s no you know, action items that come out of it. What are we really doing here? Are we just doing this for appearances, because if that’s the case, then we have some bigger problems here. And so that means that there’s something that we need to take a look at, and we need to improve. That is symptomatic, in meeting culture. But it might be something that’s deeper within the culture of the organization.
Aydin Mirzaee (Fellow.app) 41:16
I couldn’t have said it better myself, Danielle, this has been super insightful, so many different things, so many different takeaways, and tactical tips as well. One of the questions that we ask all of the guests on the show is for all the managers and leaders looking to constantly get better at their craft, are there any tips or resources or words of wisdom or just parting advice that you would leave them all with?
Danielle Leong (GitHub) 41:42
Oh, I would say try learning something from somebody with a completely different experience from you to get comfortable with being uncomfortable, because that’s where a lot of growth comes from. And so I think we are used to doing that from, you know, maybe from a technology standpoint, but we may not necessarily be there 100% with our own personal growth. And so, I have learned a lot over the last couple of years. I’m learning about social issues from people who are different from me who have different lives and lived experiences. And so really being able to dive into other people’s lived experiences, learn how to say, I’m sorry, is incredibly important. And just reading a lot more and being able to put those things into practice. If you go to my GitHub repo, I have one for manager resources. I have a list of recommended readings that I have of things that I personally have learned a lot from and really grown from. And so that’s something that I would definitely recommend checking out.
Aydin Mirzaee (Fellow.app) 42:55
Yeah, and we’ll definitely include that in the show notes. Danielle, thanks so much for doing this.
Danielle Leong (GitHub) 43:00
Yeah, absolutely. Thank you so much, Aydin. I really enjoyed being here.
Latest episodes
-
Albert Strasheim, CTO at Rippling, on Embracing Rapid Iteration and Setting Goals for Accountability
Episode 6
Albert Strasheim
-
The Outcome-Driven Engineer: Navigating Hiring in an AI World
Episode 164
James Carr
-
Follow the Leader: How to Be the Example and Transform Engineering Teams
Episode 157
Jossie Haines
Fellow Newsletter
Get exclusive interviews and leadership best practices directly into your inbox.
-
Episode 80
Are You a Micromanager or a Coach? Why Leaders Should Avoid Giving Advice and What To Do Instead
Dr. Julia Milner
Leadership Professor at EDHEC Business School
-
Episode 1
Top 10 Leadership Lessons From the Supermanagers Podcast
-
Episode 10
Empowering Your Team to Lead Fulfilling Lives
Vlad Magdalin
CEO AT WEBFLOW
-
Episode 3
Mark Frein, COO at Oyster on Being a Multifunctional Executive and Harnessing Pattern Recognition in Leadership Roles
Mark Frein
COO at Oyster
-
Episode 4
Rob Khazzam, CEO at Float on Building a Culture of Urgency, Customer Obsession, and Risk Tolerance
Rob Khazzam
Co-Founder and CEO at Float
-
Episode 33
Balancing Challenge and Care at Work: The Radical Candor Approach
Amy Sandler
Chief Content Officer at Radical Candor
-
Episode 87
You Won’t Have All the Answers: Why Being Intellectually Honest and Disassociating from Ideas Makes You a Better Lead
Rémi Guyot
Chief Product Officer at BlaBlaCar