In Episode 11, Denise Yu (@deniseyu21 on Twitter or check out her website http://www.deniseyu.io/) shares specific actions engineers can take to grow their effectiveness. A small sample of the ideas Denise shared:
- Schedule time to learn from people on other teams
- Bring a buddy to learning sessions with you
- Be curious how others feel about what's going on around you
- Share the impact of others' work with their managers
Transcript
JENNIFER: Welcome to Storytime with Managers, a podcast by Cohere.
Hi, I’m Jennifer Tu, and I’m here with Denise Yu to talk about going between engineering and product. Denise, can you say a little about yourself?
DENISE: Sure. Thanks so much, Jennifer, for having me on the show. I’ve been working in the tech industry as a software engineer for about five years, coming up on five years now. I currently work as a Software Engineer at Pivotal. I’m based in Toronto. The current project I work on is Concourse CI which is an open source CI/CD tool. But before that, I worked on lots and lots of different projects, mostly in the Cloud Foundry ecosystem, if you’re familiar with that. Yeah, I think that’s the short version. There’s a much longer version that I can tell you if you’re interested in learning more.
JENNIFER: All right. We’ll make sure that people can learn more about you at the end of the show.
DENISE: Sounds good.
JENNIFER: Awesome. I’m really excited to talk with you today because you’re one of the very few people I know who has gone from working on the engineering side over to the product side and then back again to engineering. And one thing I’m wondering about is when you most recently returned to the engineering side from product, I’m kind of curious what kind of things you found yourself noticing or thinking about as you were doing your engineering work that maybe you hadn’t when you first started in engineering, before you started working in product.
DENISE: I think the biggest thing that I struggled with was when you spend time in product management, you start to look at the team as a whole unit and the stream of workflow as a complex system, I guess, where a team’s ability to deliver features or perform refactoring or whatever it is, the team’s ability to deliver is not just about like having clearly defined stories or having a well maintained code base or anything like that. It’s actually, flow is a much more – there are a lot of different contributors to flow. And one of those is process. Process is a huge thing on the team and also things like psychological safety.
So I guess when I went into product, I started looking at all the different ways that I could speed up my team and unblock them. And I had to take a sort of 500-foot view of everything that was happening on the team. And once you start doing that, you kind of can’t unsee it. But when you’re in engineering, you’re sort of operating closer to the ground. So engineers tend to think in terms of what’s my work that I’m trying to do for the next week, what’s the next story right in front of me or the next ticket or whatever project management system you use. Whereas for product managers, you’re always thinking, what are our outcomes for the next month, for the next quarter or the next year? And what pieces do I need to start putting into play to enable that?
It was difficult going back into engineering because I was still thinking about everything in terms of these bigger systems and I was trying to advocate for a process changes as if I was still the product manager. And that sometimes led to some friction with the people whose job titles actually were product manager on the first team that I went back on to.
JENNIFER: Oh yeah, that does sound kind of rough. Hopefully it turned out really well for your team in the long run.
DENISE: Yeah, in the long run, it was good for the team to have those hard conversations around who should do what kind of work and how do we reason about outcomes as a team rather than only having one person, only having the product manager sort of own that thought space.
JENNIFER: Yeah, I really like that about how now you’re able to look at it both zoomed in and zoomed out because of your experience in product. And I like what you described as transforming your team into one where everyone was starting to think about that in a similar way and in a way that could support your product person. And I’m kind of wondering what you found effective in helping the other members of the engineering team learn to start changing their zoom in, zoom out perspective so that way, they could better support the product person.
DENISE: Yeah, that’s a really great question. For me, the question that I was always trying to get the engineers on my team to engage with when I was doing product management is why are we building this thing and why are we building it now? And I think once you start framing things, your work, not in terms of what, but why, it prompts people to start thinking about who are your customers? Who are your users? Is this the right time to be working on this particular feature or are there other shorter paths to a quick win that we can look at? I think that in terms of how I encourage other people on my team to start thinking about the work that we do in those terms when I went back into engineering, it really was modeling behavior strongly and bringing people along. So, for example, one thing that I try to impart to the team was, did you know that engineers are “allowed” to schedule meetings with people on other teams in order to talk about this upcoming feature or to collect feedback on this thing that we did a month ago? Things like that. I also take a very strong ‘don’t ask for permission, ask for forgiveness’ approach.
I’m really proud that Pivotal has been having this conversation over the last few years about psychological safety, because I think that you really need that in order to have the space to experiment and to push the boundaries where you sort of know that forgiveness is your safety net. That will be there if you need it. But I basically just started doing things without asking permission. I just started scheduling meetings with people on other teams. For example, my team was working on a feature around certificate rotation, which I knew was a workflow that another team – we have other teams within the company who would do work more oriented around operations and maybe what we call like site reliability engineering. And I knew that those teams are doing certificate rotation every week, if not every day. So, whatever we decide to do for this workflow, we definitely need to talk to them first. They are the domain experts. So I just set up a calendar invite, optionally invited everyone on my team and pulled in the people on that team that I thought were the main complex holders or the main stakeholders, in product terms.
JENNIFER: That makes so much sense. I was wondering how you modeling going off and making meetings would show other people. But if you’re optionally inviting other people, then they really see it. And maybe a few people are – did anyone end up joining you?
DENISE: Yeah, some of the engineers on my team came along. We have a pattern called Anchor at Pivotal, which is a term that we – it’s basically a lead engineer, the person who, if you need an engineering representative from the team to be in a meeting, that person de facto is the one who gets pulled in. So, I wasn’t the anchor of the team at that point because I just joined. The anchor of the team came, some of the longer serving members of the team came, and we actually were a split team between Toronto and San Francisco. So some of the longer serving people in the San Francisco side also came. So that was cool. It ended up being a really productive conversation. And the other team, the SRA team, was really grateful that we had approached them early in the process, because I think it’s really common to sort of fall into a pattern where you realize, “Oh, we probably should have consulted these people and then throw something over the wall at them at like the 23rd hour.” And that’s not a very nice feeling. And I think you also miss out on productive conversations and insights that could have guided your design process. So, I was trying to avoid that.
JENNIFER: And I bet that means that the people who went to the meeting with you saw the gratefulness of the other team in having that meeting happen, and that was a response that really influenced them in thinking about how they should approach this in the future.
DENISE: Yeah, absolutely. I’m generally a fan of if it’s more than a simple yes or no answer from another team, you might as well just schedule a quick 10 to 15 minute call just to start laying the groundwork for empathy and start building human relationships because we are all people and we are all here to achieve the same thing. I always try to set up face to face, like a remote company, but Zoom to Zoom, I guess, calls whenever possible.
JENNIFER: Did you find modeling that behavior to be sufficient or did you find it sufficient to get people thinking about how to make these connections and how to start thinking about not how to build something, but while you’re building something? Was just modeling sufficient or did you find you also had to talk with people individually, one-on-one or in small groups to start shifting that thinking?
DENISE: Yeah, I don’t think that modeling works in itself, especially if this is a brand new behavior that you’re trying to socialize out to a team. I think you do need to set up stronger feedback loops. So one-to-one, I will go get coffee one-to-one with various people on the team. I try to make that a habit every time I roll on to a new team. So during these sort of coffee one-to-ones, you can casually chat about what do you think is working on the team? What do you think can be improved? And I try not to frame things like this as feedback, because sometimes feedback sounds like professionally scary. People think that, “Oh, God, I’m doing something wrong and I’m not going to get promoted or considered for this thing if I don’t change this behavior.” So, it’s not anything like that. I try to frame it as like, “Hey, in this last conversation that we had, what did you think about what this other team said,” and try to just suss out where people are feeling about the process change. And if I get a sense that not everyone is on board, I might actually just pull back and just go into observation mode for a little while and try to figure out what are the fears that this team has? Is fear a factor for why this team is being slow to embrace process change? Or maybe I haven’t convinced them of the value of doing things in this different way, which is kind of on me to figure out a different way to show that there’s value in this process experiment.
I also will sometimes give positive reinforcing feedback to people’s managers, actually. We try to have managers collect feedback for their reports every quarter or so. Sometimes it’s higher or lower, depending on that person’s career growth goals. But if someone helped me out with – so for example, in that meeting, there was another person on the team who really drove the conversation because she was the primary context holder on how to design a certificate rotation process. And I sort of sense from this person, “Hey, do you mind sort of driving this conversation a little bit? And later on, I made sure to say to her manager, “This person was super helpful in the meeting. This is the impact of her participation.” And I think that having more interactions like that is a good way to evolve this team’s understanding of how we deliver value for our customers, but how we get stuff done together.
JENNIFER: I really like two things that you said just now. One of them was the idea of telling people’s managers when you really appreciate the work that that person is doing. The other thing that I thought was really neat was the way that you do your temperature checks of using the phrase, “What do you think about X?” I really like that. So, I wanted to quote it out as something I liked.
One thing that I’m wondering about is you mentioned fear and sometimes you get the sense that individuals across a team, and so the team as a whole is afraid of something. And I’m wondering, how do you dig into that fear and how do you uncover it and how do you learn more about it?
DENISE: That’s a really great question. I think from what I’ve seen so far, a lot of the times, fear is rooted in a disconnect between the activities that that person is currently spending their time doing and the perceived set of activities that they need to be doing to grow in their career. I actually kind of had an ethical dilemma when I was product managing because I think many, many engineering organizations level and promote people based on a banded career ladder or there’s other models, but we use a banded career ladder. And within each band, there’s a set of criteria that describe the impact that you’re meant to be having if you’re a senior engineer or you’re a staff engineer. Those are like different bands.
And so, one thing that I worried about a lot when – and I still kind of worry about this, to be honest, although I’m back in individual contributor land – there isn’t really a clean way to measure someone’s impact when the things that you’re doing are so experimental. So if you’re going off and spending your time – say, for example, the team as a whole. So it’s a community facing team, like my current team. And let’s say that we identify that the biggest problem that we have today is that we are not engaging our contributors well enough and it’s taking us too long to do things like close pull requests, respond to issues, things like that. This is hypothetical. The problem is that if we decide to try to close this gap, even if we come up with all the metrics in the world around why this would be great for the open source community and why this would be great for the customers, for the paying customers, there still is no line item in the skills matrix that actively participates in open source contributions because not every single team at a company is open source spacing. So if that’s the case, then as someone who is in the position of team leadership, whether you’re the product manager or the anchor or just a more senior member of the team, if you recognize that this is the path the team has to go down. But individual contributors may or may not have that time investment be reflected when it comes to promotion time, then that’s a really tricky situation that you put yourself in and you put the team in.
I kind of felt weird, like when I was product managing, I knew that I needed more support because the technical domain was new. And I knew that it would be good for the team to be more involved with cross pollination and cross team conversations. But there was no clean way for me to make the case that this person should be recognized because they came to this conversation with a customer and contributed these insights.
JENNIFER: I really like that. So, when you notice people being resistant or showing fear, one thing to look for is examine what their individual goals might be and whether those individual goals are aligned with what you’re trying to do. I’m kind of wondering, kind of still on the topic of feeling resistance, but switching off a little bit. I wonder if you’ve ever encountered resistance to engineers learning to switch their mentality away from how do we do this thing, what should we be doing to why are we doing this.
DENISE: Yeah, for sure. I’m actually trying to sort of like work in progress or maybe a future blog post that I’ve been spinning on for a while is I think that people have obviously different goals in their careers. And also people have different opinions about how they want to spend their time to get to their goals. So one source of resistance that I saw a few times is when you have a very senior engineer or a perhaps like someone who actually is called lead engineer on a team, but they don’t actually want to do so much context switching, they’re not ready to let go of their engineering means. They want to be the person architecting a cool new feature. They want to be the person thinking about difficult engineering challenges. But what they don’t want to do is be pulled into meetings, interrupted every few hours because they are the context holder on some technical problem. My informal name for this archetype is the expert consultant. They want to solve engineering problems and they want you to pull information from them about engineering questions. So having an expert consultant on a team can be very useful, but it can also make process experimentation very, very difficult because that person views their role as providing engineering insight rather than parachuting into whatever random conversation you need them to be part of.
So I think part of how I deal with encountering resistance is I try to mentally categorize people into a couple of different archetypes. Maybe this is a bad thing to do. So you have sort of like your expert consultant archetype, and then you also have – I don’t have a name for this archetype – but someone who is willing to just jump in. They can just be dropped into anything. They’re just as happy being asked to facilitate a design sprint as dropping into a customer conversation or a support call. Those are the people that I really, really value working with. And when I encounter one of those people, I try to build a very strong relationship and build trust with them because I know that they’re going to be my allies when it comes time to push the harder questions around process change. And I rely on them to help me think about how to reward individuals on the team who are supporting, who are willing to play ball with process experiments and things like that.
JENNIFER: This might still be a work in progress for you. I’m wondering, have you found anything to be effective in shifting how your expert consultants are thinking about how they relate to the team?
DENISE: I don’t have any great answers there. It’s something I’ve been thinking about for a while, and my inclination at this stage is probably figure out how you can restructure the role so they can spend more of their time doing the expert consultant activities that they love to do. So that asking them for the occasional non-technical activity doesn’t feel like such a big ask. But I’m not 100% sure.
JENNIFER: I think we’ve got time for one last question and then let’s swing all the way over to the other side. And I’m wondering, if you were returning to product or more likely, if you were coaching someone who was starting off in the product managing side, what advice would you give about how they can help engineering teams shift their thinking away from ‘what do I build’ to ‘why am I building’?
DENISE: This is the advice that I think I would give to someone else, but also to myself a year ago, when I was starting, when I was doing my rotation, I would say choose some things to measure and be diligent about measuring them because running things or making decisions based on, I don’t want to say gut feeling because that sounds so nebulous. But based on qualitative data, it’s harder to get buy in for that than it is for quantitative data. And I know that not everything can be quantified, but data driven decision making is going to generally lead to more compelling evidence than the alternative.
So I would say, start measuring early. Iterate on the things that you’re measuring, obviously. You might choose the wrong metric in the beginning. And if you never, ever change that, then you’re just going to be optimizing towards the wrong things. A lot of research out there written by people who are far, far better versed than [inaudible]. But I would say like try to be as data driven as possible and keep one eye on team health. Keep an eye on things like psychological safety. If you haven’t encountered the term psychological safety before, it’s definitely worth reading the Google online resources around it, because I think without spending a little bit of energy on cultivating that space for people to give genuine and difficult feedback, it’s going to be really, really hard to do anything else.
JENNIFER: Wow, this is amazing advice. Denise, thank you so much for taking the time to talk with me about all of these different topics today. If our listeners want to talk with you more about this, what’s a good way for them to get in touch?
DENISE: I probably spend way too much of my life on Twitter. You can always add me or DM me at @deniseyu21 on Twitter and my website with my email and other contact information is DeniseYu.io.
JENNIFER: All right. Thanks so much.
DENISE: Thanks so much, Jennifer. This was super fun.
JENNIFER: Thanks for listening to Storytime with Managers by Cohere. Our theme music is by Kevin MacLeod and we’re edited by Bryant from Zinc. If you like this episode and want to hear more, tell us on Twitter. We are @wecohere.
