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:
Two valuable rules that will save you from concocting stories and creating unnecessary drama around a project. How to prevent ideas from being shot down instantly, and instead share them in a way that will pique your teammate’s curiosity and foster an effective dialogue around them.
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.
