Have you been in your current role for a while, and are eager to try something new?
Perhaps you’ve thought about transitioning from being an individual contributor into a leadership role, but you’re not sure if it’s the right move for you?
You worry about being qualified enough, leading people, being an authority figure, and what your day-to-day will be like.
While it sounds exciting and maybe a great opportunity to grow, you worry about your existing skills getting rusty.
Well, all this month on Build we’re going to be exploring the tradeoffs that aren’t talked about when we choose to transition from being an individual contributor to a leader. In today’s episode, I’ve invited Jean Hsu who was formerly an Engineering Manager at Medium and is now an Engineering Leadership Coach.
Here’s what you’ll learn in this episode:
In the episode Jean mentions the book: The Manager's Path, check it out here.
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
Transcript for What Stops Us From Transitioning Into A Leadership Role
Poornima Vijayashanker: Have you been in your current role for a while and maybe you're considering a transition from being an individual contributor to a leader, and you're not sure if it's right for you? Well, in today's *Build* episode, we're going to explore some of the tradeoffs that aren't talked about, so stay tuned.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now one myth that I came across early in my career was the transition from being an individual contributor to a team leader. I struggled with this transition because I worried about my skills getting rusty and whether or not I had the skill set to actually lead people. So if you're grappling with this, we're going to cover it in today's episode. To help us out, I've invited Jean Hsu, who is an engineering leadership coach. Thanks for joining us today, Jean.
Jean Hsu: Thanks for having me.
Poornima Vijayashanker: Yeah. You and I met a couple months ago at a event. I'm really curious to know a little bit more about your background. If you can walk us through what drew you into tech and ultimately led to what you're doing today.
Jean Hsu: Sure. I went to school for computer science. I actually went to a liberal arts school. A few years in, I started trying to figure out what I wanted to do and what I really enjoyed was the coding and the projects and the—I didn't really know anything about applications, what the applications were going to be, or what software engineering was as a job, but I really loved the classes. I think that when people talk about how to attract women to tech, a lot of the conversations are actually, they don't seem as relevant to me because I really loved the actual coding itself, and I didn't know anything about what I would do after I graduate.
Poornima Vijayashanker: So where did you land after college?
Jean Hsu: I had interned at Google the summer before I graduated, and then I ended up taking a full-time offer at Google that started right after I graduated. I moved up to Mountain View and I was there for about a year and a half. Then I quit and wanted to see what else was out there, and kind of had the sense that Mountain View and the Google campus is a little bit of a bubble, and so I started to dabble in Android development. I ended up at Pulse and did some of the Android development there. Then after that—I was there for about a year and then I ended up at the Obvious Corporation, which later became Medium. I worked on their first prototype. Then I was there for about five and a half years.
Poornima Vijayashanker: Oh, wow.
Jean Hsu: And then I left about six months ago.
Transition from engineer To engineering manager
Poornima Vijayashanker: So what catapulted you to strike out on your own?
Jean Hsu: It was kind of the right time to make a big change. I don't know if it's like, I have two kids. I have an almost two-year-old and a four-and-a-half-year-old and that's very, it's not stable, but there's sort of a monotony in taking care of them. I had been at Medium for five and a half years, so I think there was a part of me that just really wanted a really big change and I was ready to kind of jump in the deep end again and figure something out that was completely new to me.
Poornima Vijayashanker: Now when you're at Medium, that's when you did your transition, right, from being an engineer to an engineering manager.
Jean Hsu: That's right, yeah.
Our perception of who or what we think it takes to be in a role
Poornima Vijayashanker: What kind of prompted you to even consider this transition? Because a lot of people just think, “I'm happy kind of coding away. Why rock the boat?”
Jean Hsu: Yeah, I mean for me I was pretty happy coding away, but I think I wanted to see where I could be more impactful. I don't know that I really chose it for myself. I was sort of, I wanted to have more impact and influence. Sometimes I was stepping into tech lead or project lead roles. I think at some point it was like everyone kind of knew that this was kind of the path I was headed and I was almost the last person to know. It was interesting because when I made that switch and started to take on a few direct reports, I think everyone was like, “Oh, it should have happened like a long time ago.”
Poornima Vijayashanker: What do you think they saw in you that maybe took you a while to see in yourself?
Jean Hsu: I don't know. I guess I didn't really know what a manager did. Even at the time at Medium it wasn't called manager. I think they still call it a group lead, so it was very much this mentor, advocate, coach role, which is sort of, what I'm doing now is very similar to that. I think it was that people saw that in me, that they felt like they could talk to me about things and that I would help them solve their problems. I was never very much of a command and control, top-down type manager, which is maybe what I thought managers did.
Poornima Vijayashanker: Yeah, so maybe it was your perception or, “My misperception of this is what a manager is, so clearly I'm not a manager because that's not what I want to do,” when really you've naturally been doing a lot of great tasks or I guess things that managers would do.
Jean Hsu: Right, yeah, like when you, if you ask me like, “Oh, do I want to help people and support them and help them solve their problems,” like, “Yeah.”
Poornima Vijayashanker: Right, but not maybe the “I want to enforce strict process or—”
Jean Hsu: Right, like I'm just going to tell you what to do every day.
Why we think we aren’t capable of leading
Poornima Vijayashanker: Got it. Tell us some of your concerns, then, going in, aside from this “I don't know if I'm capable of being a manager or what a manager role entails.” What were some concerns with that?
Jean Hsu: I mean my transition was pretty gradual. But as I got more and more in it, I definitely had this concern that it was too early to go 100% in that direction.
Poornima Vijayashanker: Why?
Jean Hsu: I mean I think a lot of it is the tech industry. I sort of have this sense that people who don't look like me, specifically white males, if they are, they look young and they're in a management position, people tend to give them more the benefit of the doubt and think, “Oh, that's someone who is like so talented that he got promoted into management.” I sort of worried the opposite would happen to me where people would look at me and say, “Oh, she doesn't even have that much technical experience,” or like, “She looks really young. She came out of a boot camp,” or something, whereas I really had like a decade full of experience. I definitely had that anxiety of how will I be perceived once I leave this company.
Poornima Vijayashanker: And how did you handle that perception, kind of get over it?
Jean Hsu: That’s a good question. I think that a lot of it was sort of—I mean I also had the sort of struggle of do I then count as someone who's like nontechnical anymore. You see these statistics of like, “Oh, 70% of women leave their technical roles.” I’m like, “Am I contributing to that?”
But I think what I landed on is sort of like the whole point is that you should be able to do what you feel, like is your calling, and that you want to do and not that I'm contributing to the statistic that we want to go down, not up. I think that's part of how I kind of came to terms with it. Then when I was thinking about how to, like if I was leaving the IC work too early, what my manager helped me focus on was what would I get out of doing more of it.
He's like, “Well, if you want to do VP eng or a head of engineering type role, I feel like you've already demonstrated that you can do that. Even if it's areas that you're not familiar with, you can work with engineers to figure it out, you've done that before, and so what would you get out of it.” I was like, “Oh, I guess I just…” It's sort of this feeling of like I should do it, I should do more technical work, not that I really wanted to or that I was drawn to do more of it.
Poornima Vijayashanker: It's interesting that he led you down that path of what would it look like in your current role if you were to do more of maybe the same, or where would that kind of take you longer term, and is that the kind of work that you want to do.
Jean Hsu: Right, and he was very open with me and saying like, “OK, well, you know what? I understand that you may want to go, kind of like shift back a little bit, but for this quarter we really need you here and let's reassess.” It felt very like a temporary, not temporary, but it was like an ongoing conversation. It wasn't like if I wanted to go back into IC work, I'd have to leave the company. I always had that advocate in him.
How long it really takes to transition into a leadership role
Poornima Vijayashanker: So you ultimately decided to take the choice and go from being an individual contributor, an IC, into a leadership. What were the first few months like in that transition?
Jean Hsu: It was kind of a long transition. I'd say it was like over maybe two years. The first few months I mean I definitely had this sense of like, I don't have time to get my work done because when you're responsible for both the coding work and being responsible for teams or people, it's really hard to have that, like make your time.
Poornima Vijayashanker: Right, contact switching.
Jean Hsu: So I definitely felt like it was easy to just say, “Oh, I had a day full of meetings. I didn't get any work done.” That’s a very, very common mindset to have when you make that transition.
When we don’t have something tangible to point to we feel unaccomplished
Poornima Vijayashanker: I think for me when I went from being an engineer to a founder, the hardest thing was I'm no longer going to have something to point to at the end of the day because before I could build something and deploy it and be like, “Look, what I built,” and at the end of the day I was like, “Yeah, I talked to five people.”
Jean Hsu: Yeah, I started keeping, in the times where I felt like the transition was the roughest I started keeping a log of what is the one thing that I felt was most impactful that I did that day, and sometimes I kind of had to make it up. I was, “Oh, I had a one-on-one with this engineer, and maybe she thinks about herself fundamentally differently now and is now going to interact with people in a slightly different way.” You kind of have to take those where you can get them.
Poornima Vijayashanker: It's squishy and you don't see the results immediately and it’s developing a level of comfort with that. I think that's one of the harder pieces and where people get demotivated when they're not seeing their results fast enough versus with code it can be very instantaneous.
Jean Hsu: Yeah, and I think management success or being a leader is a little bit more subjective and the feedback loop is a lot longer.
Poornima Vijayashanker: Yeah, let's talk about that. Yeah.
Jean Hsu: I mean it could be, I mean if you're just talking about actual feedback that you get, that's, I don't know, at companies that kind of have—can I curse on here?
Poornima Vijayashanker: Of course.
Jean Hsu: —have their shit together, it’s like six months. Every six months you get some feedback on how you're doing, the official formal feedback loop. But beyond that you have the one-on-one. That's a very individual relationship. I think for a lot of people they don't really see the impact of their work. One of the things I've been thinking about is for engineering work for the most part your impact is somewhat proportional to the work you put in. If you spend two months building a system with a team, that's two months that you put in. Hopefully it's an important thing that you've done. Then the management work sometimes you can do some tweaking or some restocking up front that can have really big impact that people might not trace back to you, and so you sort of have to see that loop, that feedback loop for yourself.
Managing and leading your peers
Poornima Vijayashanker: Were you ever in a situation where you also went from being an engineer with a bunch of teammates to then being their manager and having them as direct reports?
Jean Hsu: Mmm-hmm. Most of my early direct reports were new grads. In some ways that was sort of easier. I had just been there eight years ago and so I had a very good sense of like, “Oh, this is kind of where you are now, and here's the type of support you need.” I'd say as a tech lead it was sometimes a little bit more difficult, especially when I was suddenly responsible for managing the work of people who were more senior than me, that I feel like I kind of took a very hands-off approach, which sometimes was like, there’s just miscommunication. But it is something I feel like especially as a manager you have to navigate, like how, it's OK to be friendly with people. I mean obviously you want to be friendly with people in the workplace, but how much you can be like good friends outside of work.
Poornima Vijayashanker: And how to be authoritative.
Jean Hsu: Right, and navigating that was a little bit tricky to me. Figuring out if someone invited me to something, “Should I go?” I’m like, “What? If I did something, who should I invite?” In some ways I just didn't hang out with people at work who were on the engineering team because it was like, I felt like I had to invite 30 people. I don't want to invite 30 people.
Poornima Vijayashanker: Right, so you want to be careful about playing favorites and stuff like that.
Jean Hsu: Right. I think I was especially sensitive to that, because I had seen it, I'd seen it happen. People who are friends go to Vegas together and then you're just like, “Whoa, I understand you’re friends, but it's hard to say that that's completely separate from your work.”
Poornima Vijayashanker: What about the boss factor? I know for myself as an older sister bossiness is just totally normal for me. But did you have a sense of like, “How do I go and be more of an authoritative figure or disciplinarian” sometimes?
Jean Hsu: Yeah, most of my—that kind of stuff was in one-on-ones. I feel like one of the areas that I kind of grew into was to bring that to a more group setting and a lot of my feedback would be around like, “Jean has,” like, “We want to hear more from her, like we want…” People wanted to hear more from me. They knew that I was, kind of like, I had an opinion but I wasn't like—
Poornima Vijayashanker: Voicing it.
Jean Hsu: Voicing it. Actually after I had to figure out that I was going to leave and do my own thing, I kind of became more unintimidated. I was sort of just saying whatever I wanted to say in meetings, which probably actually made me better at my job.
Poornima Vijayashanker: What do you think kind of got you to that level aside from putting in your notice? Did you have a mentor that kind of helped you see these were hurdles or things that were holding you back as you were doing the transition into a leadership role?
Jean Hsu: Yeah, I mean I had a lot of peer support and my own manager was very helpful and kind of providing that feedback in an ongoing basis. I think for me it was also seeing that when I spoke up in meetings, because one of my pet peeves is like inefficient meetings and—
Poornima Vijayashanker: I agree.
Jean Hsu: One of the things I would start to do a few years in was like, “OK, I'm just going to get up and start to facilitate the meeting and get people on track and kind of cut people off,” and that came out of a facilitation role that we had at Medium, but sometimes there’s unstructured meetings so I kind of just take that role. The first few times it was like, “I don't know if this is OK. Do people think I'm being overbearing?” But once I started getting feedback of like, “Oh like, thank God you were there to do that,” or people would start electing me to be the facilitator—
Poornima Vijayashanker: You're doing the things they’re thinking of doing, yeah.
Jean Hsu: Right. I was like, “Why do I just sit here with this sinking feeling of like, ‘Ugh, this meeting, why don't I do something about it.’’”
Poornima Vijayashanker: Oh, that's great, so you were, yeah, naturally gravitating towards taking the reins and steering people in the direction. It wasn't as if you were having one-on-ones with your boss, your manager every week and saying, “I have this problem. How do I deal with it?” You naturally saw opportunities and thought, “I'm going to dip my toe in and see what happens.”
Jean Hsu: Yeah, I think there was probably a long way I could have gone before. One of my goals—actually I never achieved this—was for people to tell, for my manager to get feedback about me that I was over the top because I knew there was a long way to go.
Poornima Vijayashanker: Oh god, yeah. I always push people for that. It’s like yeah, push to a level of aggressiveness and then they’ll know.
Jean Hsu: Yeah, because I could tell that it was really myself holding me back and there was so far from where I was and where that was really going to be a problem, and so I kind of wanted to see what was the range there.
Poornima Vijayashanker: Did you ever hit the—
Jean Hsu: No I did not, I left before.
Poornima Vijayashanker: Something new to aspire to then.
Jean Hsu: Yeah, maybe.
The choice to stay with the known path
Poornima Vijayashanker: What do you think you've gotten out of the—now, what is it, a year, two years since you've been a leader—what do you think you've gotten out of that experience that maybe you wouldn't have gotten had you stuck to your individual contributor role?
Jean Hsu: I think there's equal—I was going to say impact and influence, but I feel like even in the IC track there's ways to achieve that and to lead also.
Poornima Vijayashanker: Yeah, we’ll get to that. Let’s talk about the leadership.
Jean Hsu: As a manager, I felt like it's definitely pretty exhausting to be the person sort of taking care of people and supporting them, but there's a lot of rewards there too, which is like you know that these people have someone who they feel safe coming to and there's issues. I don’t know. It's just like a level of influence that, what I had from my manager, just being able to extend that to everyone else, that was really, that really meant a lot to me.
Poornima Vijayashanker: Any impact on the product or the company that you can speak of?
Jean Hsu: In terms of the company a lot of my role was also doing engineering operations work, so kind of like team-wide processes, taking what was working on my team or other teams and kind of expanding them to be part of, more of the whole engineering team’s processes. Then something I also saw at Medium was engineering was the largest team. A lot of times engineering would pilot something and then it would work really well and so we’d expand it to the rest of the company. That was kind of cool too, to see that level of like, “Hey, like what's going on over there? They seem to be like pretty well supported.”
Poornima Vijayashanker: Then coming back to the question that you proposed. If you had stayed in your individual contributor role, how do you think it would have manifested itself?
Jean Hsu: I don't think that was ever really for me, but I think that once I could see that I was capable of doing it, that also made me much more comfortable to switch to the management track, because I really felt like for a while that I wasn't cut out to do the hardcore infrastructure platform work, and they're kind of going that way as my career route. Then I did spend like a quarter or two, really diving deep into platform work, and I could see the path there. Once I could see the path and I was like, “OK, I can see this, if I don't do people management and some of the other things I'm doing and I just focus on this, I could see how I could get to where this person is in five years or 10 years.” It was interesting because just seeing that helped me kind of be comfortable with moving to the management track more fully.
Poornima Vijayashanker: You mentioned there being opportunities for leadership for individual contributors. So for folks who might in our audience choose to stay as individual contributors for the long haul of their career, what do those opportunities look like?
Jean Hsu: I mean there's a lot of different, even in the individual contributor, I mean some people include tech lead as part of that track. I think in the more purely individual contributor track you can still expand your influence and you can be the architect of larger, larger and larger things or just be able to coordinate. I mean it becomes less individual even though you're still doing the work.
Poornima Vijayashanker: Sure, you’re just divvying it up or directing people, but maybe not responsible for their career.
Understanding the path of a new role
Jean Hsu: That's right, or you're thinking more about the high-level technical strategy of the company or—I mean, that I think eventually leads to architect or CTO type roles, whereas once I had kind of figured out the paths, I didn't really have a sort of canonical like VP eng, like, “Oh, this is what a VP eng does, and this is what a CTO does.” Had worked at Google where you have no visibility, to those people, Pulse, which we were just all kind of figuring things out, and then Medium where my manager was the head of engineering and it was very much like a hybrid VP eng/CTO role. But once I had figured out what that actually meant, it was pretty clear to me that the path that appealed to me most was sort of the VP eng route.
Poornima Vijayashanker: Yeah, it's nice when you have a little bit more transparency.
Jean Hsu: Yeah, because otherwise it's just like, “I don't, I don’t know,” like, “I don't know where I'm going because I don't even know what the options are.”
Poornima Vijayashanker: That's a good final set of words for our audience, is getting a sense of what the various tracks look like before you pre-select or make the decision to not participate, just kind of get your facts straight, get a sense of what each role is like.
Jean Hsu: Yeah, the book *The Manager’s Path* was really good for that because she, Camille, the author, she lays out a lot of the—I like how she lays it out because at the end she talks about all the core things that a company needs and then the different combinations of roles that they use to achieve them, because VP, eng, and CTO can actually mean very different things depending on the company you’re at.
Poornima Vijayashanker: Nice. We'll put a link to it in the show notes. Thank you so much Jean for sharing all this awesome information. I know our audience out there is going to get a lot out of this. For those of you now in the audience, Jean and I would like to know: have you recently done a transition maybe from being an individual contributor to a manager or a leader? What were some of the concerns you had, and how did you go about handling that transition? Let us know in the comments below this video.
That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode, where we'll dive in a little bit deeper and talk about how you want to manage your concerns around your skills, getting rusty when you go from being that individual contributor to a leader. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
A redesign is a great way to reinvent your brand, get a leg up on the competition, and revisit those clunky and outdated workflows.
While we may be eager to jump right in, we have to be careful about what is actually going to help us accomplish our business goals.
In today’s Build Tip, I’m joined by Leslie Yang who is a Senior Product Designer at Pivotal Labs. Leslie and I are going to talk about how much to include in a redesign and what you need to do before you start a redesign.
You’ll learn:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
Transcript for Product Re-design: What To Do Before You Redesign Your Product
Ronan: I'm not sure about this, Poornima.
Poornima: What? What? What's going on?
Ronan: We've redesigned the entire landing page, the onboarding workflow, and the customer checkout experience. From the analytics, I can't tell which of these redesigns actually moved the needle.
Poornima: Did you redo them all at once?
Ronan: That's what I thought I was asked to do.
Poornima: I think we're going to need to talk about how much to redesign in today's *Build* tip.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker, and I've got a new *Build* tip for you. Today, I'm joined by Leslie Yang, who is Senior Product Designer at Pivotal Labs. Leslie and I are going to dig into how much to include in a redesign and what you need to do before you start a redesign. Thanks for joining us, Leslie.
Leslie Yang: Thanks for having me.
Poornima: Let's first talk about why teams even want to do a redesign.
Leslie Yang: Totally. The ones that I can think of are three. One is you have your company and you really want to have brand refresh. You want to be out there in the market and you want people to get excited. The second thing, as a company, you want to get a leg up on the competition so you really feel like if I defined myself in the market against our competitors, we will have a winning advantage. The third thing is maybe you put your product out for a few years and you're feeling like all these workflows are pretty clunky, so we want to make sure we simplify it and take a step back and look at that, too.
Poornima: I know companies are really eager to do a redesign. What happens if they jump in too fast?
Leslie Yang: Totally. There is a lot of hidden risks involved. The number one thing is that companies can invest a lot of money and time into the visual design and improving that at the detriment of the user experience and that's always a bad call.
Poornima: Got it. How can they avoid doing that?
Leslie Yang: Sure. One of the things they can do is take a look at your workflows. If they're already doing really well for your company, don't change them. Don't fix what's already working really well. Definitely do user research to test to make sure that a redesign is something that people actually would find value in. Then you want to make sure that your design patterns are consistent across web, and mobile, and everywhere else, people are able to use the app.
Poornima: What does it mean, like design patterns are consistent?
Leslie Yang: Design patterns are the interactions are going to be the same ones you would experience similar in mobile versus web.
Poornima: What's an example of that?
Leslie Yang: For example if you're using Yelp. My experience on Yelp for mobile, if I'm going to see a list of search results, I'm on web, I should see something very similar to that.
Poornima: Got it. Consistent user experience.
Leslie Yang: Absolutely.
Poornima: What else?
Leslie Yang: Let me think. You should definitely work on developing a style guide that will work across all parts of your app.
Poornima: Great. If you have those four things nailed down, then it makes sense to start the redesign?
Leslie Yang: Yeah. It's definitely worth looking at it from that point.
Poornima: You mentioned a lot of times you want to revisit those clunky workflows. How can you do that in a way that's not going to end up causing you to go down a rabbit hole?
Leslie Yang: Oh, definitely. What you really want to do is work with product to look at your metrics. Find those areas where there's some hidden pains and work on improving those areas first.
Poornima: You look at the drop-off points and then go from there.
Leslie Yang: Absolutely. Yeah.
Poornima: One new insight that I learned in this conversation is a lot of people spend time doing visual design versus actually investing in the workflows. How can you make sure that that's not what's happening?
Leslie Yang: Well, a big thing is you need to look at your data. You look at your qualitative data and your quantitative data. From looking at that, you can figure out where in the user experience you want to improve that experience. Then you work on the visual design last.
Poornima: It's definitely the priority of workflow first, visual design second.
Leslie Yang: Yes.
Poornima: Now, let's go back to our initial example where Ronan had, bless his heart, changed a lot of things all at once. He redesigned the landing site. He redesigned the onboarding and finally the checkout and sometimes it makes sense to do them all at once if you've got the resources. But, in his case, things just weren't working out.
Leslie Yang: Yeah, totally. I think what would really help Ronan in those moments is if he had permanent metrics for each of those different experiences that he was looking to test and understand.
Poornima: For example, like the landing site, the metric for the landing is—
Leslie Yang: It's just checking to see how many people have had signed up for the site.
Poornima: Then for the onboarding—
Leslie Yang: It's improving the user experience from signup to becoming an active user.
Poornima: Right. Then the final checkout is monetize.
Leslie Yang: Monetize.
Poornima: For Ronan's case, I think where he probably did a lot of redesign within each, like changing a number of elements in the landing site, changing a number of elements within onboarding, and finally checkout. He doesn't know within each what's working. But then overall, not having those metrics siloed also made it confusing.
Leslie Yang: Exactly. In a specific workflow, if you're going to change something, change one thing at a time and then have some good metrics to test to see if it's successful or not.
Poornima: Well, thank you so much, Leslie, for sharing these tips with us today. I know our audience out there is going to get a lot of benefit when they consider doing a redesign next.
Leslie Yang: Thanks so much for having me.
Poornima: Yeah. Now, Leslie and I would like to know if you've done a redesign recently, what did you consider redesigning and how did it turn out? Let us know in the comments below this video. OK. That's it for today's *Build* tip. Be sure to subscribe to our YouTube channel to receive more episodes of *Build* and *Build* tips like this one, and special thanks to our sponsor, Pivotal Tracker, for their help and support in producing this episode. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
All this month on Build, we’ve been talking about project management. First, we shared two ground rules you need to set for yourself to get through a software project successfully, and in the last episode, we shared strategies for handling new ideas and unexpected challenges that may derail your project.
But you’re probably left wondering, what do you do to get through the last 20% of a project? Especially when the deadline changes, and it’s clear that teammates are starting to burn out and become demotivated? Is it even possible to get through it and successfully ship?
And if you are able to get through those hurdles and successfully ship, what next?
In today’s Build episode, Jen Leech who is the VP of Engineering at Truss, and I are going to share proven strategies to get you through that last 20% and successfully ship!
You’ll learn:
- Why the last 20% of a project is really a lie!
- How to avoid the complacency that comes with a deadline that are very far away in the future.
- What to do when the deadline gets pushed up or back.
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
##Project Management: How To Keep Your Team Motivated And Successfully Ship transcript
Poornima: We've been talking about how to manage your first high-stakes project. We started by alleviating some of your anxieties, and then we talked about how to manage situations where people want to change course or bring up new ideas. In today's final episode on this topic, we're going to talk about how to keep your team motivated to help you ship your product. So stay tuned.
Welcome to *Build*, brought to you by PivotalTracker. I'm your host, Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions when it comes to building products, companies, and your career in tech.
So finishing that 20% of any project can be challenging. People get burnt out and demotivated. In today's episode, we're going to talk about how you can keep them motivated and get them to successfully ship. And to help us out, Jen Leech is back. You'll remember Jen is a VP of engineering at Truss, a software consultant. Thanks for joining us, Jen.
Jen Leech: Absolutely. Thank you for having me.
Why people get demotivated and burn out during the last 20% of a project
Poornima: So you've done a lot of projects throughout your career, and you know as well as anybody out there that that last 20% is the hardest. People get demotivated, they burn out. So let's talk about why this happens to begin with.
Jen Leech: Yeah. So really the fundamental reason that this happens is that the last 20% is never actually 20%. It's the 20% that you imagined when you thought about the project. But in terms of the amount of work involved, it's usually the most tedious and painstaking tasks that are reserved towards the end. When you get towards the end of the project, that's when new stakeholders start showing up and having ideas about things that need to happen on the project that weren't already there. So the final 20% ends up being like another 80%. So four times as big as you thought it was going to be. So that can be demotivating for people. And people who thought—if they really thought they were towards the last 20%, then it's especially demotivating because they suddenly see the work explode in front of their eyes when they hadn't really thought that it was going to be that much more.
How to handle project scope creep
Poornima: So there's a number of things that are causing the project to get bigger towards the end. One of them you mentioned, scope creep. How do we handle the situation?
Jen Leech: Yeah. So this is the point in the project at which you need to get really aggressive about defining exactly what you're trying to deliver and why, and for whom, and digging into every request that comes in and understanding how that impacts the final project. So the process of digging into that involves really having a good sense of who the users are, who the stakeholders are, and talking with those people as much as you possibly can. If a person comes in and wants to see a particular feature, you need to really understand why they want that feature, whether it's something that they dreamed of as part of the project from the beginning. That's something that they thought would be really wonderful for users, or whether it was something they determined through recent user's testing is going to actually dramatically impact the target market for this product.
Understanding where those ideas come from, the business impact of those ideas, how well vetted the idea is in terms of hard data, and then from there you can parametrize whether, "OK. This has been vetted. It's really clear how it connects to our business interests. It's a great path towards our goal. We need to get this particular thing in. Do we need to cut any other features? Are the other features irrelevant now?" You know, how does that change the whole scope of the project? So that's one angle.
Another angle is, "This idea is something that sounds pretty great. I love the idea. We haven't tested it. What's the quickest path to create a test to try to validate this hypothesis. Can we create a little feature? Can we create a mini version of this thing? Do we need to have a fully fledged version of this thing. How do we gather information to inform our direction so that we can make sure that we're going on the right course?"
Poornima: I really like what you said about being aggressive with pushing back, especially when it's going to expand the scope and it's not something that has a clear business goal versus the thing that has a very clear direction. The challenge though for many of us, is if that is an important stakeholder coming in then we worry about what will happen if we push back. So how do you navigate that conversation?
Jen Leech: Yeah. So I feel as though many of the tactics that we described in the last episode apply here. So when someone comes in and they have their idea, how they want to see something go, they're not going to be happy if they feel like you're shooting them down without having thoroughly considered the idea. And if you begin to really investigate that idea with them by asking questions to reveal assumptions about the idea, following the idea through to its ultimate conclusion. That can clarify both for you and also the other stakeholder at the same time, the aspects of that idea that are things that you should run with that are going to improve the product and that are maybe relatively low cost. And maybe there are aspects of that that you can leave on the table for now, and you can tease those things apart.
And if you go through that process collaboratively with the person who brings the idea in, then at the end of the conversation they're going to both feel like they've been heard, that you have really fully considered their idea, and very likely they will be glad at the things that you pulled out and left on the table. And you have facilitated the process of helping them see what the most valuable nuggets of that idea are and that's a huge value to bring to a project.
What to do when you’re burnt out working on a project
Poornima: But here's the deal. I am so exhausted. It's been three weeks on this project. I don't even have the energy to facilitate that conversation because I'm borderline burnt out and this is maybe the second or third request that this stakeholder has done. What do I do?
Jen Leech: Well to be honest, you should probably walk out of the room.
Poornima: Yeah, OK. Politely maybe?
Jen Leech: Politely. Politely walk out of the room. When you truly are burnt out, and you truly exhausted your emotional reserves, that's when it's time for somebody else to step in and take that role. And you should expect that that may happen some point in time and prepare for it. And so the preparing-for-it process is all about sharing your load with other people on the team, teaching other people on the team to do what you do. So on this particular project I have been referring to from last year, one of the things that I did on that team is I asked individuals from the team to rotate through the team facilitator role.
So I would ask everyone from the team, whoever they were, to run sprint plannings, to run retrospectives. We would have design discussions where we would have design exploration, and then design critique. We would pair discussions where we...they weren't exactly brainstorming. Not like the “everyone puts sticky notes up” kind of brainstorming thing. It's not like that. But the exploration and exploding of an idea to gather as much as you can. Then somebody would go and write those ideas up, and then we would get back together to make a decision.
All those processes have some kind of facilitation involved. And we would have everyone from the team facilitate those processes. Then when it came time, such that somebody was out sick, somebody needed to take a break, or was on vacation, those processes continued to occur without interruption and they vary a little bit and that's fine. And each person who has taken that role then is also much more invested in the team, and a much better contributor to the process. So essentially you need to produce your best factor. I'm sorry. Improve your best factor by increasing the number of people who have that skillset.
Poornima: Now the challenge with doing this though is there's a lot of handoffs. Which means a lot of setup and tear down, right? Like if I'm handing something over to you, I might say, "Here are the things we talked about before." I mean, like you said it's great for the bus factor, but it is not so great when it comes to that added investment of, "OK. Now I need to talk to Jen, and then Jen needs to talk to so and so." And each time they're doing that, that's an additional time cost.
Jen Leech: So you're referring to handing off responsibilities. So one thing that I discovered is that...so part of the handoff process involves creating a set of really simple, well-defined processes that are easy for anyone to follow. And each time a new person stepped into the role, they would refer to those processes and say, "Hm. I don't fully understand X." And then we would augment the process to cover, "OK, so somebody didn't understand and need an explanation for ..." And we use these process documents to hand off the roles. So eventually it didn't really require a conversation.
Poornima: OK. But what about people who might game the system? Like, say somebody is a stakeholder, right? They know, "OK, Poornima. She's kind of a pushover. So when she's the facilitator next time, I'm going to make sure I get my ideas in because Jen, she's really good and aggressive. I'm never going to get my ideas passed through her." How do you handle those kind of—
Jen Leech: Well you know, what ends up happening is that although one person is designated to make sure the processes are happening, everyone in the room eventually becomes a facilitator. And the facilitator role is really just about setting the stage. And if everyone in the room has rotated through that role, everyone in the room is trying to make it happen. And you no longer have a single point of failure. Let's say that facilitator doesn't show up that day, or they're not feeling very well. Someone else just does it because everyone's done it.
Poornima: OK. So do you feel like there's a level of accountability then where people wouldn't necessarily be able to come in and game the system?
Jen Leech: Yeah. Because the more people who...every time someone steps up and begins running the system, that really clarifies why there's value with facilitating a collaboration in a way that includes everyone's opinion, for example. The more people facilitate it, the more they understand the value in it, and then the more they reinforce it whenever they're in a discussion.
How to handle changing deadlines for a software project
Poornima: So there's that dreaded deadline. And sometimes it gets moved up or it gets pushed back. In the event that it gets moved up, we're kind of scrambling. In the event that it gets pushed back, we start procrastinating. So how do we hold ourselves to that deadline?
Jen Leech: I actually think that the case where it's moved up is the easier case. Yeah. So when a deadline gets moved up, assuming that you're working with humans, you have resource constraints. So the first thing that I look at is the project scope. And if you have defined what your deliverables are, the things that you absolutely have in your project, then you can look at those and think, "Well are there ways that I could deliver that in a way that is slightly simpler, or in a way that maybe doesn't handle quite the data throughput that we're going to need to handle?" Because maybe in the first week maybe we don't really need to handle that data throughput.
So having the deadline moved up can actually reduce you to be more aggressive in pairing down what you're delivering in a way that can actually really help. And if the pairing down process is something you bring to stakeholders and they say, "Oh, but we really need all these features." Then you have hard data that you can point to and say ... Especially if you're using a project tracker system like PivotalTracker, which is what we use, then you get estimates for the amount of work that the team can do in a sustainable basis, and projections for how much they'll be able to complete by a certain amount of time.
And those are real data-based estimates. So, didn't intend to pitch Pivotal here, but I actually, I love their company. They do some great things. So then you can bring that to the table and then have a really clear, honest discussion about, "Here's the what the team can do. Here's the features we can deliver. What do you think? How do we solve this problem?" Again, trying to solve it together. When the deadline gets moved out, that's when it gets more difficult.
Poornima: Right. People start procrastinating.
Jen Leech: Exactly, exactly. You already have people who are thinking of the last 20% as 20% when it's actually 80%. And then all of sudden when you move the deadline out, then it's so easy to—
Poornima: Check out.
How to manage a software project when the deadline is far away
Jen Leech: Relax a little bit. To think, "Oh, well. That feature isn't so big," and not realizing that you're misestimating the amount of work that's involved. So one of the things that I try to do, especially...so this works for both when deadlines are moved out, and when a deadline is being set for you that's actually really far in the future.
So as an example, we had a deadline last year that was nine months in the future. So we...what I did is I created an internal milestones document. So I created a bunch of internal deadlines for the team that we should be aiming to hit, and if we weren't hitting those things then we should be reconsidering what we're doing. That helped a lot to focus the team and to keep us on track. And then when you build out intermediate milestones then you can set an internal deadline for completion that's even months ahead of when you think it's going to be. And create that paired-down, really lean version of the product that is going to maybe validate the hypothesis you have about what you're building and why you're trying to build it, and add extra business value to the project for the company by saying, "OK, so you asked us to build this. You want it by December. How do you know that's the right thing to build?"
So you get to then have a version that lets people play with it enough so that if you're building the wrong thing, you can change it before the real deadline, and even though the business has told you they want X by date Z, if you give them a smaller version earlier and discover they were wrong, they will be singing your praises to high heaven. That's what they really want. What they really want is the answer that's going to serve their customers. And if that's what you're keeping in mind, then you're going to have a really successful project.
What to do after you’ve successfully shipped your software project
Poornima: Awesome. So you've done these kind of shorter shipping dates with the milestones. So you're kind of doing it iteratively, you're shipping periodically. What do you do though, right after maybe that first or second time that you've shipped? Because I think a lot people forget. They're like, "Ship. Time to go on vacation." It's like, "Hold up here." Right? Because you've broken it into milestones, there is another one coming up. There's another sprint, release, whatever you like to call it.
Jen Leech: Right. Right. Well it depends on what you've shipped. I mean if you really shipped your true milestone, you should probably go and have a party. Like celebrating your results has real value to it. Aside from that, you're getting ready to collect data about what you've built. And this is part of the process that I think is sometimes...although we talk in our industry a lot about gathering research and being product driven, and making sure that we're building for the actual users, however I think that...I've seen fairly often that people feel as though they've built a great product. "Great, let's move on." And they can sometimes forget who all the users are. Can sometimes forget what it means to be successful.
And as an example...and then maybe not gather enough data. And that's a huge failure mode that I'm constantly trying to correct for. The one example is, I talked about a validation system that somebody might build in one of your earlier episodes and we came up with an idea for this validation system which was based on real user experience from the previous system the company built. We built this new design, we rolled it out, and it was basically working. It was basically...it was allowing us to quickly and easily specify checks on data that we had generated. It was doing it in a way that didn't cause us to repeat ourselves too frequently in the code. It was doing it in such a way that people who were not engineers could author the validations and look at the results. We were able to say with a higher degree of certainty that the data was correct.
However, at the end of the day, because it was serving these fundamental use cases that we knew we had, that maybe the previous system had not solved these use cases well. So it was already better. We knew that. But we could have dug in a bit more. And we could have dug in a bit more by going back to the users and saying, "OK, do you want to use this? When you use it, what are the things that really irritate you?" And dig into those and get a good sense of why your baby's ugly. It sometimes is painful to do that.
Poornima: Yeah. Because you just shipped and you just had that party, and nobody wants to have a downer after that.
Jen Leech: Yeah. Exactly. That's exactly right. Yeah and you want to celebrate. But then after that, kind of pull your boots back on. Get back out there and be like, "OK. We were wrong. How were we wrong?" And that's the thing is that every time I ship a product, my first question is, "OK. Let's assume we're wrong. Let's find out how."
Poornima: Make it a game a little bit.
Jen Leech: Yeah. Well, you know, and if you come from the assumption that you're always going to have it wrong, then that's how you get it right. If you ever come from the assumption that you were right, it's guaranteed that you're going to miss how you're wrong.
Poornima: Or maybe that situation, but there's a new situation you can't apply that same assumption.
Jen Leech: It's new. Situations change. There's going to be data left on the table if you don't go back.
Poornima: Right. Yeah that's fantastic. Well thank you so much, Jen. I know I can talk to you about project management forever. But I think this is a great place to stop and I know you've given our audience a lot of awesome strategies. So thank you.
Jen Leech: Absolutely. Thank you for having me.
Poornima: So any final words for our audience out there?
Jen Leech: Yes. So I...Poornima mentioned that we run a consultancy, Truss. And we do consulting so we build all sort of different kinds of software, we do infrastructure, we work with big data, we work with highly sensitive data for the government including healthcare data, things that are highly regulated. We solve a lot of different kinds of problems and we would absolutely love to help you solve yours. So if you have a hard problem to solve, please come hit us up. You can find us online at Truss.works, and we have a form that you can fill out there to request a quote. Thank you.
In the last Build episode, we talked shared two ground rules you need to set for yourself to get through a software project successfully. But we know that managing our own anxieties is only half the battle to keeping the project on course, the other is navigating new ideas or unanticipated challenges.
Many of our teammates have ideas and solutions that can help. They are eager to have their ideas heard, so they speak up. While others are shy and worried about speaking up. But their insights and ideas can save the project!
As the project lead you know it’s important to hear your teammates out to uncover challenges early on and prevent them from derailing your progress. But how do you encourage and instill confidence in the introverted ones, and is there ever a point where you can stop entertaining new ideas and start building?
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
##Project Management: How to Respond to New Ideas in the Middle of a Software Project Transcript
Poornima: In the last episode, we addressed a number of anxieties that come up when you're managing your first high-stakes project. If you missed the episode, the link to it is below this video.
Today we're gonna tackle how do you handle getting blindsided by your teammates when there are new ideas or challenges on a project you're working on. So stay tuned to find out more.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, I host innovators, and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech.
We'll continue our conversation about managing your first high-stakes project with Jen Leech, who is the VP of Engineering at Truss, which is a software consultancy. Thanks again for joining us, Jen.
Jen Leech: Sure, absolutely.
How to respond to brand new ideas that may cause you to miss your software project’s deadline
Poornima: So, Jen, based on our conversation last week, I know you're awesome at listening to people, incorporating their feedback, and putting a plan into action, but there comes that time usually in the middle or towards the end of the project where somebody's got a brand-new idea and you are worried about the deadline and making progress. Do you have any rules or mantras for how to handle this situation?
Jen Leech: Yeah. In general, I love it when people bring new ideas to the table. That's what I want. That means that they're engaged, they're thinking creatively, that they feel some investment in the project. I wanna encourage that as much as possible.
If the idea that they're bringing to the table is a simple one, it's great. It's pretty easy to think about, pretty easy to reason about, and you can go with it or not go with it and move forward. The complexity comes in when the idea they're bringing to the table is something that is a much larger idea, or it has implications beyond the implementation of that idea itself. In those cases, I don't always know what the results would be of implementing that idea. As someone who's experienced leading projects, I may have an intuition for it. I may be wrong, following along from my last episode.
How to teach teammates to think through their ideas and the impact it will have on a software project
But the thing that I do in that situation is I ask the person who's presenting the idea to take their idea and follow it through to its ultimate conclusion. So that means asking them to say, "OK, so..." Using the example from our last episode, of a microservices architecture, I say, "Well, we have problems A, B, and C, and D in the system. And I think that a microservices architecture is gonna solve it." And then, as a project lead, I can say to them, "OK, well so let's say that we move forward with that. What are the implications for the project? Does it mean that we're gonna have more service support? Does it mean that we are going to have to have a different team structure? Does it mean that we are going to have new work in our backlog that wasn't there already? What is that work?"
And then ask them to think through their problem. In the case of microservices architecture, that might go something like, "Well, that means that we have to make sure that these units that we're turning into microservices are independently deployable, they're independently testable, that they have a well-defined interface, that that interface is versioned, that we have someone who is keeping track of what all of the requirements are from consumers of the interface." So you might need to have a product manager. The list of potential implication gets bigger and bigger, and then all of a sudden you need an entire team to manage this one component.
And then, we can look at that and say, "If this does solve the things that you're saying it solves, it's the cost of potentially increasing our headcount by x. Justify that benefit. Or are there other ways we can get the same benefit?"
Essentially asking the person to walk through all of the implications from the leadership perspective.
When it makes sense to adopt a new idea in the middle of a software project
Poornima: From their idea that they're putting out there.
Jen Leech: Correct. Think about what that really means for the company as a whole. Then it facilitates them realizing assumptions that they have made or costs that they have envisaged, and when you get to the end of it, either you're on the same page and you say, "That was a great idea, we should totally do that." Or you're on the same page and you say, "We should not do this." And you've gotten there together. So that means that the person who's brought these ideas to the table both feels like their idea has really been heard, and if it was an idea that you should not move forward with, they've convinced themselves. Then you can both move forward with whatever you agree is the right course of action.
How to instill confidence in teammates who are shy or reluctant to share their ideas
Poornima: I think some people would be up to that challenge, they may even think through their idea, but you've got a lot of people who are, just say, eager beavers. They may be new to the team, maybe they don't know this whole process or policies and just kind of blurt out in a meeting, like, "I've got an idea." Is that an appropriate time to say, "That's fantastic you have an idea, here's how we operate. We do X, Y, and Z. So let's have you walk through the implications, etc.?"
Jen Leech: That's a really good question. Sometimes a meeting is the right time to walk through that—depends on the meeting.
Poornima: Sure.
Jen Leech: A lot of times it's not. And in those cases then I'll usually say, "Oh, Kimmy, let's take that offline. Can we talk about that later?" And talk about it independently. However, through failure I have discovered that when bringing new people onto the team, they often need a little bit of intro. In this particular project that I was describing from last year, there were some new people that came into the team, stepped into these processes, started presenting new ideas, and then all of a sudden were blindsided when people started really probing into their ideas, and they weren't expecting it.
So then I had to take a step back and then I realized that I haven't given them the appropriate context. And I sat them down and I said, "Hey, I realize I didn't explain this, but in this team you should expect that we're gonna really thoroughly look at new ideas that are brought to the table, and we're gonna investigate them."
Poornima: I'd imagine it takes a lot of confidence even to just put an idea out there, so having it be shot down is going to impact people.
Jen Leech: Yeah, absolutely. What I started doing is I started having onboarding conversations, essentially, with new people who came onto the team to explain that we investigate ideas that are brought to the table really thoroughly, and that we do that with everyone. And it's not any particular person, there's not good, there's no bad, we just wanna understand what this idea means.
The particular person who I was talking to in this case hadn't yet seen somebody else go through the same process. Later on as we went through the process of exploring new ideas then it became more normalized. But I began having onboarding conversations with new people on the team to help them understand that we really investigate ideas really deeply, and that that's normal, and it's not to be taken personally.
When do you stop entertaining new ideas, building a consensus, and get to work on your software project
Poornima: So it's great that people are proposing ideas and that you're investigating them, but you remember from last time, we told our audience we would tackle this question. There's gotta be a point where you stop investigating, you've gotta stop consensus building or talking about the ideas, start making decisions and put a plan in place. So let's pick up that question.
Jen Leech: It depends on the problem but there are a few different approaches that you can use. One approach that I enjoy using is that of framing whatever question that we're looking at in terms of a hypothesis. And saying, "Well, right now we think we're trying to solve problem X." And then when you really target the problem you're trying to solve, it's easier to hone in on the specifics of does this solve that problem. Then, either it does or doesn't, then you can move on to the next thing.
When you're dealing with something more complex, let's say you're dealing with a system that is sufficiently complex such that you can't really say for sure what the result is gonna be, and furthermore, maybe you're trying to solve problems A, B, C, D, E, and F. Then there are a couple approaches I use in that circumstance. One is to say, "Let's build a quick and dirty prototype. Let's try it. Give it a limited amount of time, and see what happens." So you build out something very quickly. Ideally, you could do it in under a day, but it depends on what it is. And hopefully you've got your tools in place so you can do that. Maybe a week, but time box it.
At the end of it you then bring it back to the table and say, "Does it look to us like it's gonna be solving these problems? And what did we learn from the process?"
Poornima: So constraining the problem will hopefully constrain the conversation, and then creating a time box around when something is due will also create those constraints so that you stop that consensus building and get down to work.
Jen Leech: Yeah. And finding every piece of work you do, in terms of here are the problems we think we're trying to solve, here are the solutions we think might work, and make everything an experiment, a discovery of new information. And the discovery, at the end of the day, might be does this work for our customers.
As you frame it in terms of exploration and discovery, then it becomes natural to not have to have 100% solution. Because what you're doing is finding out.
Poornima: It's fantastic that you're making this a discovery and that you wanna get out there and explore more, but there's always that time where we think we've done a lot and still something comes up. Maybe even a customer says, "You didn't think through this enough." Or somebody on your team brings it up. What do you do in those moments?
Why it’s OK to constrain the problem space in your software project
Jen Leech: Right. I think of this as the curve ball question. You think that you have the right hypothesis, you think you have a good solution, and then all of a sudden something comes up that you didn't expect and you find that maybe what you've put together does not satisfy a certain circumstance or certain constraints.
In that circumstance, I think of it as having a new problem to solve. And when you have a new problem to solve the first question that I ask is, "How can I learn more about this problem? Who is on the team that knows about this? Who is in the organization that knows about this?" Maybe there's somebody in the finance department that can answer a question that we have. Who in the community can we talk to about this?
It's interesting because I find that taking a problem and expanding it beyond the scope of the team is something that I don't see nearly as often as I would expect, considering the fact that you have, clearly, a limited amount of information within the team.
Poornima: Limited brains.
Jen Leech: Limited brains, limited experience. And so it would seem completely natural to open questions up to a larger audience. And yet, it's easy for people to stay in their own little group and not necessarily bring in outside opinions.
This tactic is all about seeking new information. One example of this is when building this system that I was building last year. Some of the people who are gonna be using the system were data scientists. Some of them were experts on the data that we were processing.
Whenever a new component or a new feature came to the table as something that we needed to come up with a new design for, the first thing we would do is have kind of like a brainstorming session, but really more like an information gathering session where we would bring in everyone from the company, who might potentially have a real interest in the result or be a potential user of the product, and say all of the problems that they've ever had in this area that they want solutions to.
As an example, we were designing validations on data and we needed to understand a validation system existed before at this company. What did we like about that? What did we not like about it? And we had people who were not engineers, but who had to understand the correct use of the data, come to the room and tell us what their problems were.
This is a lot like user research. And then that led to a collection of problems that we eventually may have realized existed, but hadn't really framed as the problem that we were trying to solve here. And it dramatically impacted the design that we came up with.
Poornima: Let's do another example for our audience kind of playing that out.
Jen Leech: Another really, really good example is that we were using a tool for building the system that wasn't an open-source tool that had been built by Airbnb. It turned out that we had some questions about the right usage pattern, the right deployment pattern, some questions about how they manage the flow of data between nodes. And, coincidentally, it turns out that Airbnb was in the next building over.
Poornima: Oh, great. That's a great building by the way.
Jen Leech: Yeah, lucky. We contacted the maintainer of the co-depository and asked him if he would be willing to come and talk with us. And he said sure. So he came over and had an hour long conversation about how Airbnb uses the tool and various critiques and pluses and minuses of using it one way or another. And at the end of the conversation we had a much better idea of what things we were doing with it were good and we should keep on doing, and which things we needed to change. And it was about an hour of time for a huge improvement.
Poornima: I feel like this also helps you from causing more bugs because you know how to use the tool, or going through that drama of, "I don't know how this works."
Jen Leech: It saves you an immense amount of time to just ask the right questions to people who know things.
Poornima: That's fantastic. Thank you again for sharing these rules with us, Jen.
Jen Leech: Absolutely.
So you got tasked with managing your first high-stakes software project? Like handling tech debt, breaking up a monolithic code base into a microservices architecture, or something else?
Congratulations!
Are you excited?
Maybe a little nervous?
Or maybe you’re really nervous because you need to deliver on a tight deadline, and there is a lot on the line like your relationship with customers, revenue, and most importantly your job!
Fear not because all this month on *Build*, we’re going to be tackling the topic of how to manage your first high-stakes software project.
In today’s episode, I’m joined by Jen Leech who is a VP of Engineering at Truss. Jen and I dig into some valuable strategies that will address and alleviate your anxieties around managing your first high-stakes software project.
Here’s what you’ll learn in this episode:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Project Management: The Ground Rules You Need to Set to Get Through a Software Project Successfully Transcript
Poornima: You got tasked with your first high-stakes project. Are you excited? Maybe a little nervous? Or maybe really nervous because you're worried about the tight deadlines, the revenue, and your job? Fear not, because we're going to cover a number of ways to address and alleviate your anxieties in today's episode of *Build*, so stick around.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. One misconception I had early on in my career, when I was managing my first project, was that I was the only one who was a nervous wreck. I worried about meeting deadlines, budget, and shipping it. I thought everyone else had their act together and it was just me. Well, it turns out it was all a façade and some people were just better at hiding it than I was.
In today's episode, we're going to be addressing a number of anxieties that come up when you're managing your first high-stakes project. In future episodes, we'll talk about how to keep your team motivated to stay on course and successfully ship. To help us out, I've invited Jen Leech, who is the VP of Engineering at Truss. Thanks for joining us today Jen.
Jen: Absolutely. A pleasure to be here.
Poornima: You and I met a few months back when we were both speaking and I remember you talking about your first high-stakes project last year, but before we dive into, that let's start with your career. What got you interested in tech and eventually inspired you to start your own company?
Jen Leech: I wouldn't say that I ever got into tech; I would say I started there. I have always really, really loved math and science. I started coding when I was 10 and it was the natural place for me to be, that's where I was. However, I found that in industry I didn't always find the things that I wanted in my work environment, so I started Truss to create the work environment that I wanted to be in.
Poornima: What kind of environment where you looking to create?
Jen Leech: I wanted an environment that would enable me to ride for the leadership positions that I felt that I wanted to be in. I also wanted it to be an environment that was really empowering to all employees to arrive to their greatest potential, to bring to bear the greatest contributions that they could to the business, rather than necessarily trying to constrain or confine them to some limited pigeonhole of what the business thinks is best for it, which often limits the business potential itself.
Poornima: Nice. Tell us what Truss does.
Jen Leech: Truss is a consultancy. We do various software projects; our capabilities range from infrastructure and dev ops through to application development, to architecture, and we also do some management consulting. Really what that is, is a representation of the fact that our staff have a really broad skill set and we rotate roles on any project that we are on up and down the stack and across the stack. We feel as though that's one version of dogfooding that enables us to provide better service for anything we build.
Poornima: Maybe some of our viewers out there don't know what dogfooding is—what's that all about?
Jen Leech: Dogfooding is an industry term for if you are building a product you had damn well better try it yourself. Let's say that you put out a bowl of food for someone and you've never tasted it; it might actually be completely awful but if you make yourself eat it, then you have a sense of, "Oh, I should make that better," and the customer gets the benefit.
A day in the life of a VP of Engineering
Poornima: What do you do on a day-to-day basis as a VP of Engineering?
Jen Leech: As part of the dogfooding principle, I do the same work that our engineers do on a day-to-day basis insofar as I do client work. About three to four days a week I work onsite with clients. Then, what I do with the rest of my time is really the VP of Engineering kind of work. I define processes that dictate how the engineering organization operates, including things like our leveling process for how we help engineers move forward with their career, how we do peer reviews. We implemented a salary transparency policy at our company, and rolled that out in association with doing market analysis, and making sure that we had equal pay across our organization. I do all of those things as well as institute client engagement processes for making sure that we set expectations properly, making sure that we learn from our experiences with clients, etc.
Poornima: Last year, you got tasked with managing your first high-stakes project. Let's dive into that. I know you were initially pretty excited about it, right?
Jen Leech: Sure. I love a challenge.
Poornima: Who was on your team with you?
Jen Leech: This is where a client project, the project had been attempted a couple of times. It was for a V architecture of a big data-processing pipeline. The pipeline that they had, that they were already using at the company, was an MVP version of the pipeline and it had proved to be very difficult to change. It was very monolithic and it was slow to test any changes, slow to make any changes, very difficult to understand the code.
Poornima: Let's break that down. MVP is?
Jen Leech: Minimum viable product.
Poornima: Like a prototype?
Jen Leech: That's correct.
Poornima: Then, you mentioned that it was monolithic. What does that mean?
Jen Leech: Monolithic, that means that the code base that was used to process the pipeline was, in this case, two very large code bases that had become highly interconnected and so large in number of lines of code and the amount of time that it took to test any changes that it became very difficult to make any changes at all for fear of breaking the system.
Poornima: Probably like a lot of interdependencies?
Jen Leech: Correct.
Poornima: You fix one thing something else breaks and so on.
Jen Leech: Right and you would have things like a part of the code base had several-thousand-line-long python scripts essentially that you make one change in the middle and it wasn't really clear what would happen further down.
Poornima: Got it. What was the suggested course of action to fix that?
Jen Leech: When we came in—I didn't answer your earlier question—
Poornima: Go ahead.
Jen Leech: I should do that. The team that they pulled together, they asked me to lead the team and the people on the team included the company CTO, a director of engineering, a senior engineer, a data scientist, and one other Truss engineer, so a relatively small team, but a crack team. Our early discussions were attended by the COO and the VP of Engineering, so you can tell this is something they cared about.
Poornima: Very nice. How did you corral all of them and give them a sense of, “Here's what our prescription is to fixing this monolithic code base?”
How team dynamics impact the quality of the solutions
Jen Leech: I've read a lot of research on collaboration. I care a lot about building the best product that you can with the team that you have. The research that I have read talks a lot about the dynamic in the team, and how conversation occurs between people on the team, and how that impacts the solutions that the team comes up with. One really interesting result from that research is that if you have a team of, let's say, five people, one person on the team has a really high IQ, they're a genius, that team does not do as well as a team of five people who all have average IQs but who all listen to each other really well.
Poornima: Interesting. Why is that?
Jen Leech: Good question. The research did not necessarily try to explain why that was the result. However, what it did was they said repeatedly if you take a team and you measure how well they take turns in conversation, how well they integrate in all the ideas from everyone who's participating, that those metrics will predict the quality of the solution much more strongly than average IQ, as an example.
Poornima: Now, I'm not a mind reader but I assumed you were excited but also maybe a little bit nervous because you said there were a lot of C-level executives there, a lot of senior folks on the team that had a vested stake in it. How did you get over that initial hurdle? Did you set any ground rules or a framework?
Jen Leech: We had a really tight timeline and I wanted to try to get the best I could from the team, and we actually had to have a working prototype within four weeks. We're talking about working prototype, which was deployed and running real data, and on a big data processing pipeline.
Poornima: Why such a tight timeline, by the way?
Jen Leech: That was because for two reasons. One business needs, the company needed to increase the number of clients they had per, essentially, deployed resource. There we have a cost, scale at cost-scaling issue here. Then also, they had tried to do this project a couple of times already. They had given themselves, let's say, maybe six months to do it but burned away five of those months so this was last—
Poornima: Got it, they came to you. How did you take on this project or why did you take on this project? It's pretty tight.
Jen Leech: I didn't have a choice insofar as I showed up in a meeting room and they said, "Hey Jen, you're leading this project," which to be honest I don't mind. I think that's fun. That's part of why I do what I do. It became clear that I needed to make sure that the team was going to be extremely productive and simultaneously come up with a really good solution to the problem. I came up with some little tricks that I did internally to make sure that the team stayed on the right track and that I was facilitating the collaboration process toward the most effective result.
Poornima: Now, did you share these tricks with the other people on the team or are these just for yourself?
Jen Leech: I did not, actually. I didn't even fully coalesce them into a collection of things until hindsight 20/20, then I flipped back and I said, "Oh, I did these things. That was effective, that worked."
Poornima: How are you consistent about enforcing them? That's another thing, right? We make these rules, these tricks for ourselves, but sometimes we don't ever hold ourselves accountable.
Jen Leech: I found that whenever I deployed them, the conversation was more effective and so in a way it was really easy—
Poornima: The feedback to you.
Jen Leech: To enforce them because everyone in the room felt the effect and I found that people would come up to me after the discussions and say, "Wow, that was such an effective discussion. Like, that was great. I don't know what you did but ...," that kind of thing. It was self-reinforcing. When stress levels increased or when people were tired then sometimes I would forget and things would degrade a little bit. Then I'd step back and be like, "Oh yeah, I should do that thing again." It was easy to try to keep doing it because it was better.
Poornima: Let's tackle the first rule that you had for yourself.
Rule #1: State facts not opinions
Jen Leech: The first rule that I came up with was, for me, personally one of the biggest changes in how I participated in these discussions it was to say, "State facts not opinions."
Poornima: That's a great one. Can you give us an example of what that looks like in practice?
Jen Leech: Sure. Really this is about separating your ego from the ideas that you're putting forth. It's a mechanic that allows you to shed light on an idea without becoming so attached to it that if it's a bad idea, you have difficulty letting go. As an example, let's say that you want to suggest to a team that maybe a micro services architecture is the right solution for a problem that you have. You could walk into the room and say, "Hey, a microservices architecture, that's going to solve problems A, B, C, and D for us. We should do it. I think it's totally going to work. What's the next step?" You're excited, that's great. Being excited is great; however, you've immediately just jumped into that idea with your full heart and soul in a way at the get go. If for some reason your idea isn't necessarily the best idea, then if someone comes back to you and says, "Ah, maybe that's not the best idea," then all of a sudden your hopes are dashed, that's not so great.
You could take the same idea and you can walk into a room and you could say, "I think that a microservice architecture could be interesting to look at. My understanding is that it should give us A, B, C, or D, or maybe all four. Does that sound right? Do you think that we would actually get those things from microservice architecture in this situation? And would there be any problems introduced by pursuing a microservices solution to this problem?" Then, in that situation you are saying, "Here's some information. This is something we should examine. Let's examine it together." Then, when someone comes into the room and says, "Well, you know? I think that maybe it won't do C for us because in this situation that condition doesn't apply." Then you have a dialogue and when you investigate that problem, it's no longer your idea or their idea, you're trying to find the truth.
Poornima: I know our audience out there is going to be really curious to know how do you go from that conversation to making a final decision so that you're not stuck consensus building. We're going to cover that in the next episode, so stay tuned for that, but let's move on. What's another rule that you gave for yourself as you were managing this project?
Rule #2: Say to yourself, “Maybe they’re right”
Jen Leech: Another rule that I created was...that first rule was for your bringing an idea to the table, that perspective. The second one was the same thing...similar idea but from a listener's perspective of saying—it was a mantra I used and it was, "Maybe they're right."
Poornima: I love this one because it does a lot of good for you in that you're not concocting stories and a lot of drama, I think, around a project also gets dispelled because you're giving people the benefit of the doubt but it's so hard to do in practice.
Jen Leech: That's why it's a mantra.
Poornima: Let's talk about some examples that you had to use it in or that our viewers would have to use it.
Jen Leech: In this microservices architecture example, so someone comes to you and says, "Hey, you know? I think that a microservices architecture might solve our problem." Let's say, you as a listener have built microservices, you've transitioned from a monolithic code bases to microservices 20 times and you have a lot of context. You could say, "Hmm, nah. No, I don't think so." You could just say, "Based on my experience, I think you're wrong."
This tactic is about putting that on its head and saying to yourself, "Maybe they're right," puts yourself into their shoes. Once you're in their shoes and saying, "Well, maybe they're right," then you can say, "OK, well why do you think that a microservices architecture is the right solution to this problem? What specific problems does it solve for us?" Then it leads you in a path of thinking through their suggestion and as you do that it may reveal things that maybe you didn't realize they were trying to solve. Maybe they have a different problem in mind to solve than what you do. When you realize that they're trying to solve a different problem you're like, "Maybe it does solve that problem in a way I hadn't thought about. Maybe if we use it in this one particular instance it will solve a different problem that I thought we had."
Poornima: That's great. It helps you get over the assumptions of the problem that you thought or it gives you more context to see how deep of a problem it is.
Jen Leech: It reveals your assumptions, it reveals the other person's assumptions, and it opens you up to be a much better listener, and simultaneously also validates the other person's ideas, which may be one of the more importance of that interaction, in fact.
Poornima: I feel like both these mantras, rules, whatever you like to call them are great for like 99% of the situations we have when we're managing that high-stakes project, so thank you so much, Jen, for sharing them.
Jen Leech: Absolutely.