I don’t know about you, but I cringe at the thought of having to commute. The traffic, road rage, not to mention having to find parking… it was enough to make me throw in the towel 7 years ago!
Since then I have been managing remote teams around the world, and as I continue to scale my team I learn best practices from companies who have been doing it for longer than I have like Olark.
But, I know there are a lot of people out there who just don’t know if they can do it.
Maybe you’re one of them. You worry if you’ll be productive, able to communicate effectively and fit into the company culture.
One of my employees, Meghan Burgain felt the same way about a year ago. She had a number of reservations having never worked remotely before.
In today’s Build episode, Meghan and I are going to dive into some of these reservations, how you can get over them, and of course the wonderful benefits aside from working in your jammies ;)
You’ll learn:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Transcript for Remote Working: How To Succeed In Your First Remote Working Position
Poornima Vijayashanker: Hey, guys. I'm hanging out here in beautiful Bordeaux, France, and taking you behind the scenes this week to show you what remote working is like at Femgineer. If you've been on the fence about taking a remote position, stay tuned for a number of tips in today's *Build* episode.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. For the past seven years, I have been managing remote teams around the world for my startup as well as other companies. Today, I'm joined by Meghan Burgain, who is the mother of twins and expat who lives here in Bordeaux, France, and is Femgineer's community manager. For the last year, Meghan has been working remotely and she's going to share some of her favorite tips to help you get over any reservations that you might have when it comes to taking on a remote position. Thanks for joining us, Meghan.
Meghan Burgain: Thanks for being in France, Poornima.
Remote Working Reservations
Poornima Vijayashanker: I know a year ago when I approached you about remote working, you were on the fence. Let's talk about what some of your reservations were.
Meghan Burgain: Yeah. My education and a lot of my experiences are in education. I was actually a teacher before I moved here. I was a little concerned about getting up to speed, getting trained at Femgineer. That was one of my concerns was getting trained.
The other one of course was that Bordeaux is nine hours ahead of San Francisco. I knew that there was going to be some difficulty there. Would I have to stay awake at night to get all of the work done or not? Those are my two concerns.
How To Handle Time Zones When Remote Working
Poornima Vijayashanker: While you got over the hurdle and joined the team, I know there was that first hiccup that you had where you missed a meeting due to the time zone. What did you learn from that experience?
Meghan Burgain: Time zones are really tricky. I learned that basically communication is paramount, especially when you're working remotely. You need to be explicit, very clear, search for the clarification, ask the questions that you need and really just be polite when you're dealing with people through email. With chat, it can be difficult to maybe misread something so just to be polite and that avoids 90% of the issues.
Poornima Vijayashanker: Then you eventually got over that and learned a number of things over the last year. Let's start with the first thing that you learned.
Recommended Tools And Processes To Stay Productive As A Remote Worker
Meghan Burgain: Right. The first thing I learned basically was the importance of the tools that we use. Being that we're not in proximity, we use the tools like Trello and Slack. Trello is great because obviously for communication you can see who's doing what, if it's done or not, but also allows for transparency. You can see the bigger picture: what we're focusing on at Femgineer, what the priorities are, and how that should affect how I prioritize my own tasks as well.
Poornima Vijayashanker: Now, I know another thing you've learned that is even though we're a remote team we still do weekly check-ins where we sync up. Walk us through how weekly check-ins have benefited you.
Meghan Burgain: Weekly check-ins are really important. In startup plans, especially, products change, priorities change, and the weekly check-ins really help me, us both I feel, to stay focused and to stay in the same page working towards the same goal.
Training New Remote Hires
Poornima Vijayashanker: Now, I know the third thing is that you were concerned about training, getting trained, training other people. I know as we've scaled the team, you had to train others. How have you gotten over that hurdle?
Meghan Burgain: It's funny that that was one of my reservations and that's actually something that I've been doing at Femgineer. Well, I've realized that training someone via Zoom or Slack, it's not that much different than training someone in person and, in some cases, can actually be better because we can record the training and use it in the future which is what we've done a lot. I've also been relying a lot on our handbook.
Poornima Vijayashanker: What's our handbook?
Meghan Burgain: Our handbook is basically a recipe book for anything that's recurring at Femgineer so whether it's daily or just a certain time of the year, if it happens more than once, it's in the handbook. It's outlined. There's helpful tips and there are links to any outside resources that we might need.
Remote Working Benefits
Poornima Vijayashanker: Great. Walk us through what a typical day is like for you.
Meghan Burgain: A typical day I wake up. We get the girls ready. Send them off to daycare. Then I have the majority my day to do the daily tasks that I need to get done, answer emails that came through to do all of my tasks. Towards the end of the day, when the States wakes up, I'm able to schedule phone calls, have meetings and that sort of thing. It's where I base the first part of my day, I didn't have any of those interruptions. I was able to just do whatever I wanted at my own pace. At the end of the day, I have all the things that I need to interact with people. Then I do my to-do list for the next day and it's off to get the kids.
Poornima Vijayashanker: Nice. It sounds like you have a lot of flexible hours.
Meghan Burgain: Oh, yeah. Well, for sure. I have deadlines just like anyone else, but I do have a lot more flexibility with how I get those things done.
Poornima Vijayashanker: What do you think are the key benefits that you've experienced by remote working?
Meghan Burgain: You mean besides being able to work anywhere in the world and in my own kitchen and in my own sweatpants?
Poornima Vijayashanker: Yes. Those are great benefits, by the way.
Meghan Burgain: I would say that the biggest benefit of working remotely is that I've really been able to find a work-life balance that works well for me. I'm able to not only be there for my kids and my family but to provide for them as well. I think that that's just an invaluable thing. It's a win-win.
Remote Company Culture
Poornima Vijayashanker: I know for some folks out there they might be on the fence about remote working because of the culture. They might feel like, oh, it's isolated or distant. How have you managed to manage that?
Meghan Burgain: I could see how it could be lonely. You don't have someone just next to you to talk to or whatever but I haven't felt that way and I think to go back to the weekly check-ins, that that's really one of the reasons is that we do get that face time. Also we have Slack which we can talk to all of our team members. I would say when it comes to the culture and the team feeling, you get what you give. It can be tempting in any working relationships, especially in remote working, whenever you find someone that's available within your timezone to just ping them with the 20 questions that you have or to ask a hundred things of them. But, I would suggest to all of you that the first thing that you do to someone should really be to ask them how they're doing, to find out what their interests are. It goes a long way towards creating the spirit and creating a team.
Poornima Vijayashanker: Building a rapport maybe through a water cooler channel on Slack.
Meghan Burgain: Yes. Yes. That's what we have.
Poornima Vijayashanker: Wonderful. Well, thank you, Meghan. This has been really helpful. I know our audience out there is going to benefit from these tips.
Meghan Burgain: It's been my pleasure.
Poornima Vijayashanker: Wonderful. Well, that's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where you'll get more helpful tips like this.
Meghan Burgain: Ciao for now.
Poornima Vijayashanker: Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Hey, guys. I'm hanging out here in beautiful Bordeaux and I'll just start again. All right.
In today's Build episode, we're going to talk to you about ...
Meghan Burgain: Remote working.
Poornima Vijayashanker: Yeah, I know. I forgot what I should introduce you before I ... I think I do need to. OK. Take two.
Did you share last week’s Build episode on product design sprints with your teammates?
Wait! Give me two chances to guess what the outcome was...
… you did and you faced some pushback? Well, kudos to you for putting it out there!
… or maybe you didn’t because you were afraid of the pushback you’d get? That is OK too!
Charbel Semaan and I are back this week and prepared to help you get over the pushback you received or will receive once you bring up the idea of product design sprints to your teammates.
You’ll recall Charbel Semaan has been a product designer for the last 20 years and recently launched his brand, Made in Public.
Charbel and I have built a lot of products, and we know that even if our teammates hate the current process and the outcomes it produces, they will still find comfort in it and resist adopting a new one because there’s a lot of fear when it comes to change.
But no one is going to willingly admit to being scared, so they’re going to couch their fear in remarks that are skeptical, just say no, or create excuses like: “Now is not a good time.” “We just don’t have the money to run extra experiments.”
Then there’s my personal favorite: “Prove to me that this is going to work!” But the whole point of an experiment is to test assumptions by following a process, and then seeing if they were right or wrong. You can’t prove anything until you do the experiment! #chickenegg
Because we want you to be really prepared for all the excuses and pushback around a design sprint, here are a few more excuses that you’ll hear when it comes to product design sprints from our friends at Invision. There are also some guidelines and prerequisites that we recommend you consider mentioned in this post to make sure a product design sprint is right for your team.
By the time you finish watching today’s episode you will have learned how-to:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Transcript: Product Design Sprints: How To Get People To Adopt Product Design Sprints
Poornima Vijayashanker: In the previous episode of *Build*, we shared how you can use design sprints to help you test ideas out faster and get that much-needed feedback. If you miss the episode, I've included a link to it below this video. And of course, anytime you want to institute a new process in your organization, there's going to be some pushback, so in today's *Build* episode, we're going to tackle how you can evangelize design sprints within your organization. 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 related to building products, companies, and your career in tech. Today we're continuing our conversation with Charbel Semaan, who has been a product designer for over 20 years, and most recently launched Made in Public.
How To Handle The Pushback When It Comes To Trying Out Product Design Sprints
OK, Charbel, you and I have built a lot of products, and we know that even if our teams hate our current process, and we give them a new one, they're still going to be reluctant to adopt that new one because there's that fear of change.
Charbel Semaan: Sure.
Poornima Vijayashanker: And we're going to get pushback. So how do we handle that pushback?
Product Design Sprints Aren’t Meant To Replace Existing Product Development Process
Charbel Semaan: I think one of the ways I found to handle it successfully is to emphasize it's not a replacement to your existing process. It's a way to supplement, complement, or augment. And if you can run a design sprint in parallel and you're really doing it as a side branch to what you're already doing, and it gives you an opportunity to learn quickly in five days, and then be able to integrate that back into your existing processes. It's super helpful.
Poornima Vijayashanker: OK. So that's great in theory. But I know having to run a parallel process oftentimes for either a small team or even in a large organization can be a lot of setup. It can mean trying to carve out that time, so one of the key things to consider is what are going to be the benefits. Someone's going to come and say why should we do this, how is it going to help?
The #1 Benefit of Product Design Sprints: Speed of Execution
Charbel Semaan: Great questions. Why should we do it, how is it going to help. I think there are two key areas. One is speed of execution.
Poornima Vijayashanker: OK.
Charbel Semaan: And what comes along with that, with the sprint, is constraints. And through those constraints you get clarity. So you're moving quickly, you're going from thinking to action in a quick way, and you're also constraining yourself so you don't have an infinite amount of time to decide what features, what angle, should we try it this way or that way, so you get to move quickly and you constrain yourself, so you get to clarity faster.
Poornima Vijayashanker: OK. So I'm sure for our audiences out there, there's probably going to be some pushback around, ah that's great on like a nimble team of maybe five, six people—but I've got 10, 20, 30 decision makers or stakeholders. I'm not going to be able to mobilize my team fast enough. So how do we get to handle those folks?
Can product design sprints work for larger teams?
Charbel Semaan: Yes. I think you can work with those 10 to 20, or even 30 people to understand what are some big problems that you're facing, that you'd want to solve, that are top priority, or they're really affecting and impacting your productivity and your flow, your ability to ship.
Poornima Vijayashanker: Even if they're conflicting?
Charbel Semaan: Even if they're conflicting. I think you first start by gaining an understanding. So with a team that large, I've got 20 to 30 product managers and squads of teams of PMs and developers and designers, etc. You gain an understanding, if you're that org leader, gain an understanding of what are some of the top big, immediate problems that are affecting the team and affecting shipping and product and affecting the business. And prioritize those. And then think about if I can run a sprint, if I could run something within five days and gain clarity and be able to unlock some blocker that's going on across those 10 to 20, then who of that large group, who would make most sense to bring into this sprint.
We're not going to stop the presses on everyone's workflow. But we can at least prioritize, run a sprint with some key players, see how that goes. In some ways it's a look at like an 80-20 perspective of 80% of the orgs, when you continue going as-is, there's going to be this 20% or even 90-10, there's going to be this small experiment we're going to run. And if that's successful, then we can see if we can apply it to other areas or aspects of the org, no matter how large.
Poornima Vijayashanker: Of course there's fragile egos. So some people are going to want to be in that special pool.
Charbel Semaan: Sure.
Poornima Vijayashanker: Why wasn't I picked?
Charbel Semaan: Sure.
Poornima Vijayashanker: So how do you message that?
How To Convey Who Does And Doesn’t Needs To Be Involved In A Product Design Sprint
Charbel Semaan: Not easily. Not easily. It's not always easy. I think one thing I've found a bit helpful is to communicate openly that we understand we have X-Y-Z challenges. We're all clear on that. And there's...hopefully you have consensus, you have agreement. And from there it's...we can't tackle them all at once. We all agree to that. And so I think you're gaining that consensus and that understanding. That mutual understanding. And then communicating, we want to try something that might help us start to chip away at the stack of challenges that we have. We're going to run small experiments. As those turn out to be successful and we learn from them, we want to continue embracing and permeating through more teams and more people in the org.
So it's coming and if it's going to work, they know it's coming, if you have a deep interest and you have a really...you're raising your hand and you really want to be a part of this, please come to tell me. If you're the org leader or the business leader, whoever you are. I think that kind of openness and communication starts to also be a signal for you to understand who are the people who, as you mentioned before, who are the people who can become those evangelists and those change agents in your organization as influencers to adopt something new like design sprints, and then be able to take it to their parts of the org as well.
Poornima Vijayashanker: I think it also serves as a signal to see how open your organization is, right?
Charbel Semaan: Absolutely, absolutely.
Poornima Vijayashanker: So I think maybe some people may get disheartened as they do this exercise and find out that they're not getting a lot of interest, so how should they take that? It's not a reason to send in your resignation letter.
Charbel Semaan: No, no, not at all. Don't do that yet. I think one thing though, is just discussing with a CO of a global manufacturing business, is people need to feel involved. In my experience, in org development and innovation with an organization, especially large ones that no one really wants to have something just told at them, and that this is the way we're doing things now. So introducing something like a design sprint into your organization, that can foster and cultivate innovation throughout all your people. Doing so by involving them.
So first it just starts with communicating that. We're thinking of doing something new. Who has some initial interest? They're like you said, you'll start to see if there is or isn't. That might be an indicator that are you really getting that kind of engagement from your folks, and as you test and as you do small experiments and you see who continues to raise their hand and want to be more and more involved. And when you're not seeing that engagement, it may actually be an opportunity to run a design sprint on internal communications.
Poornima Vijayashanker: OK, yeah.
Charbel Semaan: So that's the beauty of it for me is, I think you can sprint on any kind of challenge you have.
Poornima Vijayashanker: Right.
Charbel Semaan: It may not always be a business challenge in the product sense, or in the service sense. Sometimes it may be about your internal organization.
Poornima Vijayashanker: And what happens if you get too much interest? Everyone's like, “Oh yes, I want to participate,” and all of a sudden you've got your 5,000-person organization and it's like, “I've got things to say. I see things that are broken.” Yeah, I get this a lot when I go into places.
Charbel Semaan: Sure, sure. I think for starters, I think that's a great problem to have. I think you want that level of engagement, that employee engagement, and your people care about solving challenges in your business. It's far better than the opposite. Two, there is such a thing called mega sprints, and Jake Knapp actually runs mega sprints, which were pretty interesting, where there's simultaneous sprints happening in one large room.
Short of that, the—to your point about the question is to get to a place where there's an opportunity for people to raise their hand, have a voice, to be able to add to the mix and add say, “Here's the challenge I'm facing,” and then it's really, I think, an opportunity to create a culture of that mindset. So I go back to design sprints not just being this rigid five-day process, and the irony is it's...it can be viewed as some rigid five-day process even though it's a sprint, it's meant to move quickly. The reality for me is that when you embrace it as a mindset, and that people in your organization, no matter if you have 5,000 people with 1,000 problems each, it's an opportunity to think, “How could I solve this problem or test a new idea quickly, and can I use the framework of the sprint, can I use the elements of the sprint to take action faster?”
And I think anybody who's leading an organization, no matter how small or large, would love for their people to have that type of empowerment and to be able to feel enabled and equipped to take action.
How Product Design Sprints Different From The Lean Startup Methodologies And Agile
Poornima Vijayashanker: Now there's also a lot of skeptics out there who might say, “Yeah, you know, I hear what Charbel's saying but I've tried something like this a year ago, or like five years ago we tried lean or agile—how do I know that this is the new thing?” So a lot of times the concern is how is this going to be any different from what we tried in the past that failed miserably, and in the wake of it, caused a lot of destruction.
Charbel Semaan: Yes. Great question. This has actually been coming up recently for me and I've been doing more and more review and research on this. I think for starters it's valid. It's absolutely valid to be wondering, “Great, this is just the methodology du jour. This is now the new thing, and everyone's going to jump on this bandwagon.” I completely understand that.
Product Design Sprints Are All About Constraints And Speed Of Execution
What I come back to though is the corner about the mindset. Lean can be thought of as a mindset. Agile can be thought of as a mindset. It's a way to knock down blockers that otherwise impede you from trying something, learning from it, and iterating on it. So whether it's this model, that model, or this or the other. I think the nice thing about sprints is that for me as a designer, because it's rooted in design thinking, and it provides this construct to float through five days—and again I mentioned clarity through constraints and that speed of execution—it gives you an opportunity to go from empathy all the way to testing the idea. And prototyping is of course in there, inside of that.
Whereas lean is focused on build, measure, learn. So you just start out by building and you're going to put it out and then learn from the reactions. As a designer I am a big believer in that initial upfront step of empathizing and understanding. When you understand what that problem is and who you're solving it for, and it carries you through that initial slice of the prototype that's just enough to get in front of users, and I have a hard time imagining folks who wouldn't want to move faster and learn more, and be able to then iterate.
And this is one way of doing it. It's a methodology that I've embraced that I...it gets me out of my own decision deadlock as well.
Poornima Vijayashanker: Yeah. So in the wake of that kind of feedback around, “Hey, how is this going to be any different, you're saying treat it as a mindset,” hopefully people are willing to adopt a new mindset or at least test it out. But there are also those who start to get kind of nitty gritty, right? They might say something like, “Oh, I don't even know where to get customers to test this prototype,” or, “I don't want to bother our existing customers.” How do you get over some of those more practical hurdles?
Charbel Semaan: Sure. That's a great question. On the customer front, I think, on one hand, you hopefully have a pocket of customers who have a major interest in everything you're doing. They want to be those early adopters. They want to test new features. They're your biggest fans. And so on one front you can always start with them and then treat them right, treat them in a way where you have this open communication that we appreciate coming to you because you're such a fan of ours and we're a fan of you, and we want to come bring you our latest and greatest to see are we doing right by you. Are we solving the problems that you need solved, are we getting the jobs done that you need done through our software or through our product or service?
So I think on that front you build those ongoing and sustainable relationships with them.
Poornima Vijayashanker: And if it's a new customer base?
Charbel Semaan: If it's a new customer base, I think going back to that understanding the problem and understanding who. When you understand those two things, it's surprisingly simple to find where they are. If you understand their habits, you understand their desires and their pains and their struggles, you understand where they seek the solution to this problem elsewhere, you can go to those places.
Poornima Vijayashanker: So do you have an example of a situation where a lot of these practicalities started to add up and people just completely lost sight of making a decision on design sprints?
Case Study of A Product Design Sprint
Charbel Semaan: Yeah. Great question. There's an example where...come back to the internal learning development team at Medallia. We had big needs, we had problems to solve in terms of scaling, training, especially for the growing sales team, the growing engineering team, which are very common teams that start to spark and grow quickly. And especially globally. So how do we scale the training? And practicalities like, well, video's going to be expensive. Getting all the equipment. Having the studio. Do we even have time to shoot video and do that. People don't watch online learnings. A lot of the common...what might be common sense or these truths that we think we have in our businesses, and the reality was when we ran a sprint, it was actually a colleague of mine and we ran a sprint.
Poornima Vijayashanker: So how did you get over that hurdle to actually get them to run the sprint given these practicalities?
Charbel Semaan: That's a good question. There were a couple of people who were advocates. They wanted to embrace it.
Poornima Vijayashanker: OK.
Charbel Semaan: And the challenge was showing that running the sprint and the output of the sprint...the output of the sprint was actually more important than the sprint itself in a way. So because the output...and first they wanted to embrace the approach. They embraced the approach. They wanted to try it. And they wanted to get to that output. So we shared that video with the entire HR organization, and the output, the video itself, was what people focused on. Then when they wondered, “Well wait a minute, when did you do this and how did you do it so quickly?” That's when we were able to say, “Well, we ran a sprint on it.”
Poornima Vijayashanker: Interesting.
Charbel Semaan: And we just shortcut a lot of the decision deadlock, a lot of the concerns and a lot...we did it with an iPhone on a makeshift tripod in this corner office that we blacked out the windows and we were able to just run with it. And it's not the greatest-looking video but it's a prototype. Then people realized, “Wow, we can go this quickly and this nimbly, why don't we embrace this and actually try to do more?”
And the greatest part about that—I love the outcome here—is that, the head of the team said, “Great. Here's a budget to go get the equipment you need, on a reasonable amount of money, and why don't we use this corner room more frequently for these videos and let's run with this.”
If All Else Fails: Show People The Output of The Product Design Sprint
Poornima Vijayashanker: So that's pretty cool. You basically turned design thinking on its head. Instead of trying to get people to adopt the methodology, just show them the output, tell them about the outcomes, and then when there's a curiosity for how did this all come about, then you can say, “We used design thinking.”
Charbel Semaan: That's right.
Poornima Vijayashanker: Cool. And I think then people are going to start to embrace it in more sections of the organization, or on more projects.
Charbel Semaan: That's right.
Poornima Vijayashanker: Well, that is an awesome insight, Charbel. So for those of you out there who are stuck, feeling a lot of pushback, maybe instead of trying to get people to adopt the methodology, present them with the output and the outcomes and use that to strike the conversation.
Thank you for joining us, Charbel, and for our audience out there, how can they get in touch with you?
Charbel Semaan: Great. Thanks for having me on. This has been blast. You can reach me at charbel@madeinpublic.com, and visit madeinpublic.com, and see the projects that I'm working on, the sprints that I run publicly to help teach and empower to run sprints themselves. And sign up for the newsletter as well.
Poornima Vijayashanker: That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more great episodes and short build tips. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
How many times have you and your team spent countless hours building, bug fixing, finally releasing a new feature only to hear feedback from a customer that it’s not what they wanted?
Or worse, they don’t say anything…
Why?
Because they aren’t even using the new feature!
Back to the drawing board…
Yet again it again takes weeks or months to build and tweak and nothing changes. You just keep missing the target, asking for more time, money, and resources.
But it doesn’t help, and people just end up burning out building the wrong thing.
What if I told you that the problem in your product development process is that you are spending too much time, money, and resources and need to cut back?
OK, I’ll give you a minute to shake your head at me...
Sometimes when we have too much it causes us to go in a lot of different directions. Or worse no direction at all because we’re stuck in a decision deadlock!
We lose sight of our customers and end up building just for the sake of building, thinking that we know what problem we are solving, but we don’t.
As a result, our product debt keeps growing and a redesigns don’t help.
So how can we stop building the wrong thing and solving the wrong problem?
We can start by constraining the amount of time we have to help us focus on uncovering and solving one problem at a time.
And in today’s episode, we’re going to dive into the framework behind this new approach called product design sprints.
To help us out, I've invited Charbel Semaan, who has been a product designer for the last 20 years and recently launched his brand, Made in Public.
If you’re eager to get an idea out, worried about how long it’s going to take your team to execute, and concerned about wasting time, money and other resources, then you owe it to yourself to watch today’s episode!
Here’s what you’ll learn:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
## Product Design Sprint: How a Product Design Sprint Fast Tracks Testing Your Ideas Transcript
Poornima Vijayashanker: Eager to get an idea out there but worried about how long it's going to take you and your team to execute? Well, in today's *Build* episode, we're going to show you how you can embrace design sprints as a way to test your ideas and get your prototype out there faster. 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 a lot of us fall prey to is this need to do a massive build out before we launch a product. The results, unfortunately, are that we end up spending a lot of time, money, and energy possibly building the wrong thing. As a result, customers don't want it, teams burn out, and companies lose sight of their business goals. In today's episode, we're going to tackle this misconception, share with you how you can embrace design sprints to help you iterate faster and get your prototypes out there, and in future episodes, we'll talk about how you can evangelize design sprints within your organization and handle any pushback that you might get from your teammates or stakeholders. To help us out, I've invited Charbel Semaan, who has been a product designer for the last 20 years and recently launched his brand, Made in Public. Thanks for joining us today, Charbel.
Charbel Semaan: Thanks for having me.
Poornima Vijayashanker: Yeah.
Charbel Semaan: I'm excited to be here.
Poornima Vijayashanker: Yeah. For our audiences out there, let's start by digging into your background a little. I know you've been a designer for the last 20 years and recently started Made in Public, but walk us through that evolution.
Charbel Semaan: Sure. I started out as a designer, self-taught, when I was 15 and fell in love with it. I continued to design through college, would dabble with side projects, and never formally studied it and was formally trained, but continued to develop my skills as much as I could. I've had this interesting blend of design specialties throughout my career. I've done product design, brand design. I've done curriculum design for training programs. Bringing all of that together, I've realized I've broadened my career or widened my career. What I enjoy most is using design as a way to solve problems as a methodology, and I also enjoy teaching it. I enjoy teaching designs so people can embrace it in whatever area of work they do.
Poornima Vijayashanker: Yeah, that's great. Now, what does Made in Public do?
Charbel Semaan: Made in Public now combines all of that and I get to run my own side-project design sprints. I run sprints publicly so people can see what it's like to go through the process of going from idea to action in a very short amount of time.
And then in that way, as well, I use it as a way to teach. I really like to teach design through live experiments.
Poornima Vijayashanker: Let's dive into today's topic of design sprints. Before we talk about what design sprints are, let's maybe start with that product design background that you have and showcase what you saw was broken and why the need, maybe, for a new process.
Why Do We Need A New Process For Designing Products
Charbel Semaan: Sure. I think part of it is...there may not always be something that's broken, per se. I think design thinking has influenced my career heavily, and I've learned a lot through what IDEO has put out into the world and other great design firms out there. I think design sprints, in some ways, is a derivative of design thinking. It's another way of thinking about the design process.
What it can help guard against or help avoid are things like decision deadlock. Or it helps guard against overthinking what the big thing should be and helps you pair down because of constraints. You have five steps, and according to the Google Ventures-inspired design sprint and Jake Knapp and the author, the co-authors, the five-day approach constrains you so you're not trying to build something that could take you five months.
Poornima Vijayashanker: Right.
Charbel Semaan: Really, you're trying to create something in five days.
What Does A Product Design Sprint Look Like
Poornima Vijayashanker: Let's talk about what that looks like. What is that design sprint over those five days?
Charbel Semaan: Sure. The first step of the five steps, or five days depending on if you want to compress it even further, the first step is to understand. Map and understand and unpack the problem you're trying to solve and for whom you're solving it.
I think for anybody who's creating any kind of product, it's always essential to get down to: what problem am I solving, and who has the problem?
Poornima Vijayashanker: Yeah.
Charbel Semaan: And do I understand that person and their journey and how they first might interact with my product all the way through to the interaction and to the end result, or what I like to call the desired outcome? What's the desired outcome that they want after using your product? What is it solving?
Poornima Vijayashanker: It's one person. A lot of times, we have multiple users or multiple personas, but in this design sprint, we're going to limit ourselves to one persona.
Charbel Semaan: You can. It's important in that unpacking and understanding to understand: who might the other people be?
Poornima Vijayashanker: OK.
One Key To A Successful Product Design Sprint Is To Pare Down The Problem And Who You Are Solving It For
Charbel Semaan: If there are multiple people, acknowledging that and having an understanding and awareness of that is great. Then you might, through the rest of the course of the sprint, you might say, "We're only going to focus on this one particular person or particular user of the product, because that's basically the breadth that we have." We can't really do much more. We know we've got other folks, but we're at least going to focus this sprint on this person.
Poornima Vijayashanker: Got it.
Charbel Semaan: And then that leads to, when you understand the problem, and you understand that person and how they're facing that problem, then the second step is to sketch. This is a fun part where...this is where most people want to get into brainstorming and get a lot of ideas on the table. One of the things I like to say—and I borrow this from what I've learned through IDEO—is to think with your hands.
Now you get to actually get pen to paper, pen to Post-its, and you get to sketch a variety of solutions. If you've got about six or so people in this room with you, even if you're running it with a co-founder or you're running it solo, this is where you get a chance to get a number, a variety of sketches out on the table or out on paper.
Poornima Vijayashanker: OK.
Charbel Semaan: The third step is to decide. You go through all the sketches that you've laid out, and through a number of exercises, like noting and voting and dot voting. There are a number of different ways to approach it...you actually decide: what will the blueprint be for your prototype?
Poornima Vijayashanker: Yeah.
Charbel Semaan: And then the prototype is the fourth step.
Poornima Vijayashanker: Yep.
Charbel Semaan: That's where you actually get to create a realistic version of what you want this product to be, or the service, for that matter, and you get it out to real users by the fifth step or the fifth day. That's where folks get to interact with what you've created, the prototype, and then you can learn and observe and understand what you can improve, or did you—and this is a key part—did you validate your hypothesis? Did you validate or invalidate what you had sought out to figure out?
How Dot Voting Works In A Product Design Sprint Gets Rid Of Decision Deadlock
Poornima Vijayashanker: There's a few things going on. Let's kind of unpack them in more detail. The first is, you mentioned this concept of voting and dot voting, which I like the concept a lot. I've started implementing it. But maybe for our audience out there who's not familiar, we can shed some like into what that is.
Charbel Semaan: Sure. One of the exercises after you've gone through sketching...let's say you're in a room with about six people. You're running the sprint with six people.
All six people have generated really interesting ideas and really interesting concepts or mock-ups of what the product might be. Dot voting and noting and voting, especially if you've decided ahead of time—and hopefully you have—who the decider is. There will be one person who's going to be the decider, and they get the majority vote, or they get extra votes.
Poornima Vijayashanker: Right. Two votes.
Charbel Semaan: Or extra dates. Exactly.
Poornima Vijayashanker: Yeah.
Charbel Semaan: One of the things that's fun is doing what's called a museum gallery, where everyone's mock-ups on their 8-1/2 x 11 sheets of paper and Post-its go up on the wall. Everyone has a chance to review everyone else's mock-ups. You can vote with dots, like a marker and dots, on the elements or aspects that you find compelling or you find interesting. When it comes to decision time after the voting and whatnot, you actually get to distill the best ideas from the entire group. That's one of my favorite aspects of the sprint, is that...some people say, "Oh, I'm not very creative."
Poornima Vijayashanker: Right.
Charbel Semaan: Or, "I'm not the designer." Or, "I'm not the engineer. I'm a technical person."
Poornima Vijayashanker: Yeah.
Charbel Semaan: What I have found is when you bring a collective creative together like that, then sometimes the best ideas come from someone you might not expect to come from.
Poornima Vijayashanker: Right.
Charbel Semaan: Then the voting allows for decision making, because you can't do all the features. The voting helps you distill it down to some of the key elements that you want to focus on for the prototype.
Who Needs To Participate In A Product Design Sprint
Poornima Vijayashanker: Let's talk about who needs to be involved in this process. We've already kind of mentioned that designers, engineers are great, people who are going to be building out that final prototype, but who, aside from them, needs to be involved?
Charbel Semaan: Great question. I found what's very important is to have someone who is part of the overall decision-making process. That can either be one of the founders or any of the founders or all of the founders, someone who's at a VP level or a C-suite level, depending on the structure of your organization and how large your organization is.
Poornima Vijayashanker: So maybe whoever understands the business goals?
Charbel Semaan: The business goals, for sure, and anyone who is even involved in sort of the direction and vision of the overall business.
Poornima Vijayashanker: OK.
Charbel Semaan: Certainly the people who would be doing the building itself and the designing itself, and definitely folks who are involved in the business side of things.
Poornima Vijayashanker: Why? I mean, doesn't that feel like they're micromanaging? Shouldn't they just trust their designers and engineers and let them run free?
Charbel Semaan: Yeah. It's a great question. One of the key principles of design that I've embodied and believe in so much is this two-part or two-fold aspect of inclusivity and collaboration.
You want to be inclusive and collaborative, and that avoids this waterfall effect where...if just the engineers and the devs and the designers are in the room, and the so-called business folks are out of the room, then it becomes this, "Now let's go back and take it to them and show them this, get approval, and then..." But when folks are in the room together, that's when those ideas can come out. More often than not, an idea gets sparked from one person, and especially if you embrace this yes/and approach.
It's like, "Oh, that's a great idea. You know, what if we also did this." Or, "Could we also try this?" "I didn't think of that. That's great. OK." And then you get back to that voting and say, "Great. We can't do it all, but let's distill them." You actually have a richer conversation and a richer collaborative experience when you include more aspects of the business.
Poornima Vijayashanker: Yeah. I think that's great that you're bringing all these people to the table, involving them in the process. Now, that's obviously a lot of overhead, right, for a founder or for a VP or some of these people to come in and sit in on a five-day design sprint. I'm sure there's going to be some pushback around it, which we're going to get to in the next episode. But for the purpose of this episode, how do we kind of constrain the time so that they don't feel like they're sitting in on a whole-day session?
Charbel Semaan: Right. I think there are a couple of ways of approaching it. One is to think about design sprints more as a mindset, or an approach. The pushback I hear a lot is this five-day—"We don't have five full days to have six critical members of our team..." I completely understand that. It makes a lot of sense. The response I often share to that is, "Would you rather invest up front in those five days, where all five or six of you or seven of you can come in, and you're investing that time, which is money. I understand. Would you rather invest that and have the opportunity to come out with something that yields you a real opportunity to engage with a real prototype with real people in five days instead of five months?"
Poornima Vijayashanker: Yeah.
Charbel Semaan: Instead of five months of a bloated product that you're not even sure is actually something that the people want or are going to use or pay for.
Poornima Vijayashanker: Right.
Charbel Semaan: You haven't validated. You may have those silos that you mentioned earlier. There tends to be tension. I mean, we've experienced it where there's tension between engineering and design and product and marketing and sales, etc. And you mentioned earlier about the business folks. It can be the founders. It can be the head of sales. It can be anyone who's involved in key elements of the business. When you bring them together for those five days, you tend to circumvent a lot of wasted money, wasted time, and I come back to decision deadlock. That's a key thing I've noticed, is the inability to get through that decision, that blocker, that keeps them from—
Poornima Vijayashanker: Yeah. Let's talk about that. Yeah.
Charbel Semaan: Sure. The key thing about the sprint...and whether it's five days...sometimes it can be compressed to three if done well. I've tried one. It's very hard.
Poornima Vijayashanker: Yeah.
How Having Constraints In A Product Design Sprint Leads to Clarity
Charbel Semaan: It's extremely challenging to do it in one day. I don't always recommend that. But the key part about the decision deadlock in the sprint—when you're using the sprint as a methodology, as an approach and a mindset, as opposed to fixating on the number of days and time—is it's going so fast, and there are so many constraints, that constraints lead to clarity.
You don't have a whole lot of time to spend on, should it be this way, or should it be that way? You're simply saying, "Here are the ways. Let's pick one, and let's try it. We're going to find out if it's validated or not—”
Poornima Vijayashanker: Right.
Charbel Semaan: “—and then we can run another one again."
Poornima Vijayashanker: I see. That's great. Yeah, because I think that's actually...I was going to ask the question around scope creep, but it sounds like if you're whittling things down, it becomes very obvious what that particular thing is that you're building, whether it's a feature or whatnot, and what the problem is that you're solving versus all these other problems that might be tangential.
Charbel Semaan: Right.
Poornima Vijayashanker: Yeah, you get that real level of focus, but I'm sure unifying people around what that one thing is is a challenge.
The Role Of The Facilitator In A Product Design Sprint
Charbel Semaan: It is. That's why it's important at the start of the sprint for me, as a facilitator, to first get permission and to get that commitment from everyone that I'm here to facilitate. I'm here to guide the process and really help extract or be able to foster and cultivate their ability to create and to go validate what it is they're trying to find out. The second part is having that decider in the room. When everyone agrees and commits to who the decider is...and for that decider to be convicted in their decisions and to truly commit to, "Lot of these things are great things we can do. We could save them for another sprint. We're really going to hone in on and focus on this particular aspect."
Poornima Vijayashanker: I could imagine that whoever the decider is needs to have done their homework and be really wedded to the customers, the problem. Are there ever times where they're not sure? They may need to say, "Oh, you know what? It's two problems here. Not really sure which one. I need another day to go back and do research, or a week," in which case, now you're holding up the sprint.
Charbel Semaan: Yes. Great point. Again, the beauty here is, because you're aiming for that fifth step or that fifth day to get the prototype in front of users, to take another day, which will turn into a week, as you said, is not helping anyone.
Poornima Vijayashanker: Yeah.
Charbel Semaan: Instead, note that you've got this second thing that you might want to do, or you think you have a hunch that maybe that's also a problem. It very well could be, and that's perfectly fine. Just let it be there.
Poornima Vijayashanker: Yeah.
Charbel Semaan: Pick one and go with it, and get to that fifth day or get to that fifth step. Get the feedback. Learn from it. And observe how folks are interacting with it, whether it's a feature, like you said, or it's the entire mock-up of a product, and then iterate and do it again.
Poornima Vijayashanker: OK. Yeah, so then there's not a lot of leeway for ambiguity, and you have to get comfortable making those firm decisions to keep the sprint moving forward.
Charbel Semaan: Absolutely. I think that's the key part, is to be convicted in your decisions and to keep moving forward, because this is a sprint.
Poornima Vijayashanker: Yeah, yeah.
Charbel Semaan: You're just getting to that finish line.
Poornima Vijayashanker: We've talked about these five days. Day one is sort of this brainstorming session.
Charbel Semaan: Day one's actually unpacking and understanding.
Poornima Vijayashanker: OK.
Charbel Semaan: You want to have a good understanding of the problem and who has the problem. Then you go into sketching a variety of solutions. The third day, you decide what you're going to prototype. The fourth day is the actual prototyping. And the fifth day is getting that prototype in front of real people.
How To Measure Success For A Product Design Sprint
Poornima Vijayashanker: OK. How do you know, once you've done these five days and put something out there, whether or not the sprint was successful?
Charbel Semaan: That can vary sometimes from team to team and people to people, and depending on the product and service. What I like to anchor to, though, is, did you get some level of a lightbulb moment or an a-ha moment?
Poornima Vijayashanker: Yeah.
Charbel Semaan: Did you learn something? If you didn't learn anything by the end of the sprint, then you may not have understood the problem as deeply as you thought you did, and you may not have understood the person for who you're solving it for.
Poornima Vijayashanker: Nice.
Charbel Semaan: I like to measure it in terms of, on one hand, there's the analytical side.
Poornima Vijayashanker: Sure.
Charbel Semaan: Like, do we get buy-in, or do we get people who are turning into customers saying, "If you're going to launch that and that actual product in the next two weeks or month, OK, here's my preorder"? Great. On the other side of it, have you learned something from it?
Poornima Vijayashanker: Mm-hmm. Even if it's an epic fail here, nobody likes it, they thought the feature was just crap, there's insight there where it's like, "Hey, we're not going to be building that."
Charbel Semaan: Right.
Poornima Vijayashanker: Or, "We're not going to flesh that out in greater detail."
How Product Design Sprints Help You Fail Faster And Cheaper!
Charbel Semaan: Like the majority of my products and ideas. I've learned something, though, or the team has learned something. If it's an epic fail, great. And this goes back to what I mentioned earlier. Would you rather have the epic fail and realize that in five days, or five months later after you spent tens of thousands of dollars or more? If you're outsourcing it, tens of thousands or more. If you've got an internal team, and you've got all your engineering and design and development time and dollars, that a-ha moment can go on the positive. Let's keep moving forward with this. We're onto something...or it's the, "OK, start over. But at least we only spent five days doing it."
Poornima Vijayashanker: Right. Yeah. I think that time investment is great. I think even in those epic failures, a couple things develop. You now have a process with your team. There's some comradery and some communication barriers that have been broken down. Then there's still some interesting customer insights. A customer telling you, "Hey, I didn't like this feature. What I was really looking for was X, Y, Z," that's a valuable conversation to have.
Just kind of developing, like you said, that confidence around, "OK, I'm going to practice active listening for what it is they're looking for."
Charbel Semaan: Great point. There are two things that...
Poornima Vijayashanker: Yeah.
How Product Design Sprints Bring Teams Together And Improve Communication
Charbel Semaan: You just triggered a couple of thoughts for me. One is on the team communication and bonding front. What I've noticed is the team ends up developing a common language and a common baseline or foundation to work with. The next time, I'll hear something like, "Well, why don't we go sketch this? Let's go sketch some...we're talking about a lot of ideas or a lot of ways that we could do this feature. Let's just sketch them out, and let's vote on them." Right? "And let's make sure one of us is the decider," or whatever it might be. The other part that you mentioned around the lessons that you'll learn from the actual people who are interacting with is, more often than not in my experience, folks don't simply say, "I don't like that feature."
Poornima Vijayashanker: Yeah.
Charbel Semaan: Or, "That didn't solve my problem. Thanks. Bye."
Poornima Vijayashanker: Right.
Charbel Semaan: They're usually walking through. And if you're facilitating that empathy interview and that observation time, you're asking questions like, "Could you walk through, think out loud, while you're engaging with this?" More often than not, they're going to say something like, "Well, this confuses me. I'm not sure what this does. I kind of wish it would do this."
Poornima Vijayashanker: Yeah.
Charbel Semaan: Or you could ask, "Well, what do you wish it would do for you?" You're going to learn so much more. It's not a binary: they didn't like it and you're going to walk away.
Poornima Vijayashanker: Right.
Charbel Semaan: You're still going to learn so much, like you said.
Poornima Vijayashanker: OK. We've run a sprint. We got some feedback. Maybe it was successful. Maybe it was not successful. But what's the next step?
Charbel Semaan: The next step, I think, is to understand: what did you get out of this? What was the yield? Did you learn something about what's working, and you want to double down on that?
You can double down on that in your existing product development methodology, whatever you have. Maybe it's agile, or whatever it might be.
If it's something that turned out to not work out so well, it was a failure—if you want to call it that—then you could think about, "Well, could we run a sprint on one of those other ideas that we sketched out?" Or taking what we learned from the people who interacted with it, it turns out, we had that in some of the sketches. Why don't we incorporate that next?
Poornima Vijayashanker: Oh, nice. Yeah.
How Product Design Sprints Help With Your Existing Product Development Process
Charbel Semaan: You may not run another five-day sprint the following week, but you now are so much more informed about your existing product development cycle that you could start to pull in some stories, if you run agile, or whatever your approach is.
Poornima Vijayashanker: OK. The idea is to use design sprints for moments where you've got a lot of ideas, you're not sure which one to execute on, and really for that quicker design feedback, but not as a standalone methodology for every week, we're doing a design sprint.
Charbel Semaan: I don't think so.
Poornima Vijayashanker: Yeah.
Charbel Semaan: Yeah. I think it works out better in the way you described it. I think, particularly, sprints are great when you start to notice a little bit of that clog.
Poornima Vijayashanker: OK.
Charbel Semaan: You're getting to that decision deadlock, or you've got a problem you want to solve, but you're just grinding on it.
Poornima Vijayashanker: Right.
Charbel Semaan: The sprint allows you to just get moving. It allows you to go from thinking to action.
Same when you have a new idea. You've got lots of new ways that you think...well, we think we might be able to roll out a feature that could generate another hundred grand in revenue. Or we think we could branch off the product. There's this whole other market, and that could be a million-dollar product on its own or more. Well, run a sprint on it instead of thinking about it or figuring out, “could it be? Should it be? What do we do with it?”
Poornima Vijayashanker: I'm sure other teams—maybe marketing, sales, customer support, all these other teams out there—are probably going to start embracing design and using it. Have you seen the design sprints used for other things?
Charbel Semaan: Yeah. Actually, this is my favorite part.
Poornima Vijayashanker: Yeah.
Why Product Design Sprints Aren’t Just For Product Teams
Charbel Semaan: It's not just for product teams, at least anymore. Two favorite examples of mine, where teams that you might not expect have used design sprints and they've used them successfully: learning and development team at Medallia used a design sprint. We ran a design sprint to think about: how could we start scaling training across the entire company through video and through online learning? We ran a sprint where we had a scrappy video set up in one of the small corner offices, and we got out an example, a prototype, of a training video on a completely low, tight budget. It showed a proof of concept to the team and the entire organization what's possible.
My other favorite example is my friend Brian Bautista at SoundHound. He's the customer support person and customer success for SoundHound, and he's been transitioning, actually, and has officially transitioned to the product marketing team because of a prototype and a sprint that we ran.
Poornima Vijayashanker: Cool.
Charbel Semaan: Not necessarily on the product itself, but he was helping educate on the product and wanted to ensure that people were using SoundHound and Hound in the best possible way. What he wanted to do was test a new type of video. It was more personable. Could showcase a little bit more of the humanity of the brand and the personality of the brand. In eight hours, believe it or not—
Poornima Vijayashanker: Oh, cool.
Charbel Semaan: —ran a prototype on what that video could be, takes it to his VP of marketing, and she loved it and greenlit more videos.
Poornima Vijayashanker: Well, thank you so much, Charbel, for teaching us about design sprints today.
Charbel Semaan: My pleasure.
Poornima Vijayashanker: Yeah. For all of you out there who are watching and listening, Charbel and I want to know, is there something that you've been stuck on? Maybe a decision deadlock when it comes to a product or a service, or even something in your personal life. Let us know what it is 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 into how you can evangelize design sprints at your organization. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Transcript for What Is Product Debt And Why You Need To Prioritize Paying It Down
Poornima Vijayashanker: Did you recently show your designs to an engineer and hear this?
Ronan Dunlop: It is going to be challenging to implement in time for the next release.
Poornima Vijayashanker: Why?
Ronan Dunlop: They're pretty complex.
Poornima Vijayashanker: Why are they complex?
Ronan Dunlop: This slider alone is new functionality that is going to take at least two days’ worth of time to implement on the front end, maybe more.
Poornima Vijayashanker: OK, what else?
Ronan Dunlop: To do these visualizations we're going to need to pull in a lot of data, and that's going to slow down the performance of the app. Some of these new workflows require changes to our current APIs, which have already accrued a significant amount of tech debt.
Poornima Vijayashanker: OK.
Ronan Dunlop: It doesn't seem doable for the upcoming release. I'd recommend changing the designs.
Poornima Vijayashanker: I think we should go talk to Leslie about the importance of paying down product debt in every release.
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. Remember we talked about tech debt with Jay Hum from Pivotal? If you missed that *Build*, tip I've included a link to it below this video. Today we're going to explore product debt. To help us out, I've invited Leslie Yang, who's a Senior Product Designer at Pivotal Labs. Thanks for joining us, Leslie.
Leslie Yang: Thanks for having me.
Poornima Vijayashanker: So Leslie, tell me what's product debt?
Leslie Yang: Great question. Product debt is the debt that a product incurs when the UX is really starting to change and cease to be as successful and helpful as it used to be.
Poornima Vijayashanker: Can you give some examples?
Leslie Yang: For example, you'll hear someone say, "Hey, I want to test this new feature. Where should I put it? Let's put it in the tabs." You're like, "Should we put in the tabs? Let's go figure this out."
Poornima Vijayashanker: What else?
Leslie Yang: Let's see, so you can say that our workflow is complicated because our users have gotten so used to it, so we just end up annoying them or losing them if we change anything.
Poornima Vijayashanker: Anything else?
Leslie Yang: Another one is we just added a new feature and we want to promote it, so can we just add a button next to everyone's name and just highlight the hell out of it? No.
Poornima Vijayashanker: These are all great examples I think of product debt that we have experienced both as consumers of a product, but also folks who are designing products?
Leslie Yang: Absolutely.
Poornima Vijayashanker: I'll have to admit, as an engineer I have been guilty of ganging up on those designers responsible for deprioritizing product debt, and no, it's not a good practice. How can we help people in our audience who are designers avoid being ganged up on and making sure that product debt remains a priority?
Leslie Yang: Absolutely. As a designer it's great to be able to focus on the research, to focus on the user experience, but you should also focus on being a really good facilitator. Control the dialogue around feedback. Focus on the product vision and the product strategy and the business strategy and then connect that design feedback to it.
Poornima Vijayashanker: What does that look like in practice, as an example?
Leslie Yang: Let's say, for example, a business strategy is to improve the number of active daily users for monetization reasons. You want to make sure that the user experience is focused on building up to that and meeting that metric. One more thing. You can totally work with PMs on this as well.
Poornima Vijayashanker: OK, so as a designer approach a PM? How would that help?
Leslie Yang: You can work with product on this by pulling the data and looking at it together and then figuring out where the areas you want to improve on.
Poornima Vijayashanker: Great, so it actually provides some evidence for why you need to
pay down that product debt?
Leslie Yang: Exactly.
Poornima Vijayashanker: What about engineers? I'm sure they want to contribute and make sure that the conversations are useful.
Leslie Yang: Absolutely and I love that when engineers are in those conversations on product with us. What someone like Ronan could do if he was concerned about data visualization, he could come up to one of us as designers and say, "Hey, how does this idea of introducing data vis tools really fit in with the product vision? What do you think?” Just coming from a place of curiosity is really helpful. That creates this really positive dialogue.
Poornima Vijayashanker: He's probably going to learn more and not jump to, “Oh my gosh, this is going to cause a performance issue and a bottleneck” and all this stuff.
Leslie Yang: Exactly, and I think riffing with, I love the riffing that happens between designers and developers because you can come up with some really creative solutions you otherwise would not have come up with separately.
Poornima Vijayashanker: What can teams do to continue to prioritize and pay down product debt?
Leslie Yang: What my belief is is that developers should be brought into work early and often. They should be in the feature ideation process. I will have devs sketch with us on UIs.
Poornima Vijayashanker: Oh, great. How does that help?
Leslie Yang: It makes a huge difference because by being involved early and in frequent times they're able to contribute ideas and also understand and have user empathy. The work that we create together is not going to be overly complex. It will be well thought out and by the time that the work comes to them it's not a surprise. They know what to expect.
Poornima Vijayashanker: These are fantastic tips, Leslie. Thank you so much for sharing them with us today.
Leslie Yang: You're so welcome.
Poornima Vijayashanker: Leslie and I want to know, how do you handle product debt at your company? Let us know in the comments below this video. That's it for today's *Build* tip. Be sure to subscribe to our YouTube channel to receive more episodes of *Build* and great *Build* tips like today's. Special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Transcript for Should You Worry About Your Skills Getting Rusty?
Poornima Vijayashanker: In the last episode, we talked about what it's like to transition from being an individual contributor into a leader, and explored some tradeoffs. If you missed the episode, be sure to check it out in the link below this video. In today's episode, we're gonna talk about one of the major concerns people have that holds them back from doing the transition, which is the concern that their skills are gonna get rusty. 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. One myth that often holds us back from transitioning from being that individual contributor into a leader is the fear that we're gonna get rusty when it comes to the skills that we've worked painstakingly hard to craft. If you're an engineer, you're gonna lose the ability to code. If you're a designer, you lose the ability to design. And if you're a salesperson or a marketer, you lose your ability to close. Well, in today's episode, we're gonna debunk that myth and more. And to help us out, Jean Hsu is back, who is an engineering leadership coach. She's gonna help us dive into this myth.
Thanks again for joining us, Jean.
Jean Hsu: Thanks for having me again.
Poornima Vijayashanker: Yeah. Last time we talked about the benefits of going from being an individual contributor to a leader, especially in engineering. And not to shy away from it if we feel worried that we're not capable of doing it. But I know another concern that people have is not about their capabilities of doing the future work or being a leader, but, "Oh my gosh. I'm no longer going to be capable of doing my current job," whether that's coding, designing, marketing, or so on. Why do you think people have this fear?
Jean Hsu: I think it's something we touched on last time, which is they don't see the path of the leadership role. So of course you're going to hold onto what you know, which is the technical skills, the coding, all that stuff. A lot of the times when I have this conversation with people, what I say is, "As a coach what I'm gonna do is I'm gonna illuminate that other path, the leadership path." And for most of the people I'm talking to, it's not as much of a technical leadership path. It's more of a people management path, which are both leadership paths. But part of my role is to illuminate that, so that they then...then the question is, implies that you don't want those technical skills to get rusty, right?
Poornima Vijayashanker: Right.
Jean Hsu: Which I often feel like it's a symptom of they're not getting enough investment in seeing the rewards of stepping into a leadership role and having a more broader impact.
Poornima Vijayashanker: Yeah, or learning new skills.
Jean Hsu: Right, or learning new skills.
Poornima Vijayashanker: Yeah. Is this a legitimate fear, though? Do our skills become rusty as we go into a new leadership position or any new role?
Jean Hsu: I mean, for my technical skills, yeah for sure, they're rusty. They're definitely rusty because I'm not practicing them. I think you do have to get to a point where you feel comfortable with that. I definitely was at a point when I wasn't comfortable with that, when I was in transition. I remember one morning, I woke up and my calendar was back-to-back, 9:00 to 5:30 filled with meetings. I pulled out my laptop and I opened up three pull requests, just delete code that I had found that was unused. It was like 15 minutes. I was like, "OK. Good. I've done something today."
Poornima Vijayashanker: Well, sometimes throwing out trash is helpful.
Jean Hsu: Yeah. And when I told my manager this, he was like, "Is that the best use of your time?" He asked me this. Like, OK clearly you know the answer to that. It's a rhetorical question. It's not the best use of my time, and it's actually indicative of something else, which is that I haven't really transitioned my mindset to the actual work that I'm doing in this new role, is work. And seeing the impact of it. That wasn't clear to me yet. So that's why I was holding onto this thing that made me feel good in my past role.
Poornima Vijayashanker: Yeah. How can you figure out what the new work is? I think that's a big problem for people, is they're thrust into this role, or it's a nice promotion, or maybe they genuinely want it, but then in that first week, month, even year, they're not really sure what to do on a day-to-day basis.
Jean Hsu: Yeah. I mean, I think adding to that is that a lot of companies have founders or managers who also haven't done it before. They're not getting that model of, oh this is who I want to be as a manager. As an engineer, you see all sorts. Oh, this person went to Android or front end, they're more of a tech lead. This person's more of a Ten-X engineer type. And you don't really get to see that as much if you're talking purely about the people side of leadership, the people management.
One of the ways that you can do that is, I mean it's a little bit self-promotional, but working with a coach like me, who can help you see that path or help the people on your team see that path. There's books. There's definitely resources. There's a lot of Slack teams, that I think just being in the Slack teams is lurking. You kind of absorb what are the topics people talk about. And what are the things that come up. When you're not managing people, you don't see the things, like performance reviews, performance improvement plans, how to reward people, how to give them positive feedback and incentivize them and motivate them. You don't see that as a post lead.
Poornima Vijayashanker: Yeah. I think you're onto something, the concept of shadowing. Actually it can be really valuable. For me personally, I got to do a lot of that, having been at a very early stage startup and not as the founder, but rather as a founding engineer. Seeing how marketing and sales and engineering and product all operated and the leaders in those was valuable because when you're on the ground floor, you see how people develop, but not everybody has access to that. And not every manager enjoys being shadowed. What are some other ways you could simulate that kind of behavior?
Jean Hsu: You know, I think if you have a close peer group at your company, that can be a good place to start to have these conversations. Someplace that's trusted and confidential. If you're a tech lead or you're a first-time people manager, to have someone you can say, "Hey, I have this situation," and you don't have to be alone in figuring out a strategy to deal with it, but you can go to your peer and have this peer mentoring or coaching relationship. I found that that's useful just in seeing what other people are doing and their perspectives.
Poornima Vijayashanker: Yeah. What about setting expectations? I think some managers are good at setting expectations and some are more carefree and want you to discover it yourself. What have you seen in your experience?
Jean Hsu: What do you mean by the expectation?
Poornima Vijayashanker: So the expectation of, hey if you're a hiring manager, for example, you're gonna hire 30 direct reports.
Jean Hsu: Oh, I see.
Poornima Vijayashanker: Or if you are the team manager, you're gonna push this product. Whatever the goals are of the organization. Some people are better at delineating and having a clear set of expectations, along with standards. And others are like, "Well, here's the company motto. Do no evil and ship." So you're like, "Within the confines of that, what do I do on a day-to-day?"
Jean Hsu: Yeah. I think having some quarterly or monthly alignment and expectation setting is useful. It's the same as the first time you become a manager or a tech lead, it feels really awkward to not have...most people start off with like no stand-ps. Then they're like, "Well, I don't know what this person's working on. I haven't heard from them in three days." It's like, well maybe you should have standups, or maybe you should have some sort of weekly or bi-weekly, every other, twice a week meeting where people say if they're on track or not. I think that's generally a good strategy, is to set the high level expectations and then report back on those. Am I on track to hit those goals? Because then it feels like it's set up beforehand, so it's not, "Hey I noticed things aren't going well, so that's why I'm checking in on you."
Poornima Vijayashanker: Sure. Then it feels like am I getting reprimanded or am I getting guided.
Jean Hsu: Right.
Poornima Vijayashanker: So, coming back to this concept again of the skills. And as somebody who is either technical or has a craft, and moving away from that into this more amorphous, squishy leadership role, are there actual skills that you acquire as a leader?
Jean Hsu: Oh yeah, for sure.
Poornima Vijayashanker: Yeah, what are those?
Jean Hsu: One of the ways that I was told to think about it, for me, I was sort of like, "I don't understand. I have these technical skills and now I'm being asked to do this thing where I feel like it's a completely different skill set. I'm talking to people one-on-one all day and dealing with the things that are coming up there." The way I was told, or asked to think about it, was that it's still problem solving, it's just that the interfaces and the APIs are people and teams, rather than code and services and the systems. They're still systems, but it's people and teams, and you have to think about how do these teams, what's the API between them and it's more like that.
Poornima Vijayashanker: What are some skills that you can point to now on your resume or LinkedIn?
Jean Hsu: How to give difficult feedback.
Poornima Vijayashanker: That's important.
Jean Hsu: How to debug teams that are not working efficiently. There's the low-level tweaks, like, oh, email once a day. The low-level things. But then taking a team that's not working very effectively and making a bunch of high-level changes in staffing, and then have them actually be able to execute because of the changes you made. That's something you don't get to see. Rather than the little refactors, you're doing more of a full rewrite or something.
Poornima Vijayashanker: Yeah, a re-org, right?
Jean Hsu: Re-org, yeah.
Poornima Vijayashanker: Yeah. Anything else?
Jean Hsu: Yeah. There's a ton. As many technical skills there are, there are as many in leadership and people management.
Poornima Vijayashanker: Yeah. I think it's important for people to understand that. What about writing? Do you feel like that's a valuable skill?
Jean Hsu: Yeah. I mean, Medium was very much a writing culture. Everything was written internally, the internal version of Medium. I feel like that's something that—I consider myself also still in a leadership role, even though I just work for myself, but I work with a lot of people and I feel like all the time I spend in writing has come back. It's a huge investment for me. Yeah, it pays off.
Poornima Vijayashanker: Yeah. So in being a leader, investing in writing is good, whether or not you're actually comfortable doing it or you feel like you're particularly good at it.
Jean Hsu: Yeah. I think it's something that's really valuable to get better at. Even if you're not publishing. Whether it's writing emails. I'm sure you've all had this experience where you get this massive email and you don't even read it. And then whoever sent it is like, "But I sent you all the information." It's sort of this brain dump, over-communication strategy. I think writing is just a part of communication and figuring out what's the right level of communication because you can under-communicate, and most people in engineering teams tend to under-communicate. And then there's this tendency to over-communicate, to try to correct for it. And then people just tune you out. Figuring out what do people want to hear. What do they care about. That's all part of the writing, too.
Poornima Vijayashanker: Nice. Now what prompted you to transition to being an engineering leadership coach?
Jean Hsu: In reflecting in my time at Medium, I realize that I had a lot of peer support. A lot of peer support and my manager's support in making that transition. And even then it was hard. So I started talking to people at different companies and realizing that that transition, most people don't have any support. They have their direct reports and they have to keep it together, so they seem like things aren't falling apart. And a lot of times, they have the absent, whoever, CEO or CTO, who's not really helping them and they don't have that peer. And so I really wanted to...I saw how the benefits of having a really people-centric and caring engineering manager, because that's really the type of team we built at Medium, and thinking about how to expand my own impact. It was like, "Oh, what if I worked with a bunch of different companies and tried to help them level up their engineering management game?"
That's kind of how I landed on that. I also really enjoyed the one-on-one work that I was doing at Medium for the team.
Poornima Vijayashanker: Nice. So that's what you're doing now? You are a leadership coach for engineering teams.
Jean Hsu: That's right, yeah.
Poornima Vijayashanker: What's your sweet spot in terms of a team size?
Jean Hsu: See, it depends. I work with some companies that are like six people. I work with some companies that are like 3,000 people, but the teams themselves are smaller. I really enjoy the 10 to 50 people engineering teams, because I feel like there's still a lot of malleability in what they're doing and how they're building out their management structure. I like to work with first-time managers, because I feel like there's no bad habits to break. You can just be the one who is like, "This is what management is." They're like, "OK. Yes.” That's where I initially started when I created my business, but now I'm working with anyone from trying to figure out whether they want to go in the people management direction or stay in the technical side of things, or all the way through directors and VPNs.
Poornima Vijayashanker: That's awesome. What are some questions or problems that you help them with?
Jean Hsu: A lot of it is honestly the mindset. A lot of it is as people move into leadership roles, or they don't have leadership roles, but they are expected to step up so they can get the explicit role. A lot of it is seeing that they don't really need the permission or they don't need someone to be like, "I bestow on you this role. Now you may do these things." So just getting people to see that. As a coach, I'll push them like, "Hey, what do you need to try? What are some things you can try out this week or next week?" Then they report back and I'm like, "OK, cool." It's really cool when you have a whole team of people just all experimenting with their behavior and you just see everyone just stepping up a bit more and taking initiative.
Poornima Vijayashanker: Awesome. Well, thank you, Jean. For our audience out there who may want to get in touch with you because they have an engineering team or an organization that could use some of your coaching, how can they do that?
Jean Hsu: They can go to my website at [jeanhsu.com](jeanhsu.com) and I also have a link to my writing, too, there as well.
Poornima Vijayashanker: Great. Well we'll be sure to include the link right below this video.
Jean Hsu: OK, thank you.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
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.
As if preparing and delivering a presentation to your peers isn’t nerve-wracking enough… you also have to worry about the Q&A period at the end of your talk!
You’re worried about people asking not one but TWO questions! Having to decipher those questions that are really just comments. Then there is THE dreaded question: the question you don’t know the answer to.
You don’t want to appear stupid in front of your audience!
Truth is that the Q&A period can leave many first-time public speakers feeling like they need to know everything before they give a talk!
But you don’t, and we’re going to debunk this myth and more in today’s Build Tip.
I’m joined by Lara Hogan who is the VP of Engineering at Kickstarter and Author of Demystifying Public Speaking. Together we’ll be sharing a number of strategies to help you get ready for ANY question you receive during your next Q&A session after a presentation or team meeting. You’ll also learn some techniques to calm your nerves, engage your audience, and keep them wanting more!
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
Episode Transcript
Poornima: Whether you're new to public speaking or you've been doing it for a very long time, there's gonna come a point at the end of your talk, and right before that Q&A, where your nerves are gonna flare up.
You're gonna be thinking, "What questions are people asking?" Or, "How do you respond to a question that you don't know the answer to?"
Well in today's *Build* Tip, I'm gonna cover answers to these questions and more. Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. And today I'm joined by Lara Hogan, who is the author of *Demystifying Public Speaking*, and a lover of donuts.
Lara: Absolutely.
Poornima: Yeah. So Lara, you and I have given a lot of technical talks through our careers, and gotten to this point where maybe we're not as nervous giving the talk. But at the end, there's that Q&A period. Right?
Lara: Right.
Poornima: Where we can't anticipate all the questions. Those wonderful two-parters. People who do comments instead of questions.
Lara: Absolutely.
Poornima: Or you just don't know what the answer's gonna be.
Lara: Totally.
Poornima: So, let's kinda walk through each of these. Let’s start with the first where you just don't have a sense of what the questions are gonna be.
Lara: Yeah.
How To Prepare For A Q&A Session
Poornima: Do you have a technique that you use?
Lara: Absolutely. So I like to just in general have a feedback crew of three to five people. And hopefully they're people who you know well enough to make sure they're gonna
give you good critical feedback.
Poornima: Yeah.
Lara: 'Cause it's not worth it to just get feedback from people who you're not sure are gonna help you actually get better.
So at the end of your practice run, maybe with that feedback crew, maybe they've helped give you some feedback about your body language, about your words that you used, etc. Ask them to help you do a practice Q&A.
Poornima: OK.
Lara: Yeah.
Poornima: That's great.
Lara: I love to make sure I have a mix of people, maybe people who are new to the topic, maybe people who are really familiar with it, or know the audience really well.
Poornima: Mm-hmm.
Lara: 'Cause they can help you level up your game, and get some practice to reduce those nerves.
Poornima: Yeah.
Lara: That when you're finally on stage you're like, "I've done this before."
Poornima: Sure. And do you feel like the questions that they ask are usually indicative of what the audience is gonna ask?
Lara: I try to ask for two different kinds of questions. One's just like a stereotypical, “If you were in the audience for real, what might you ask”?
Poornima: Yeah.
Lara: But if they're your friends, they're gonna be nice, normal questions.
Poornima: Right.
Lara: I also like to add a version two, which is like, “Let's get weird.”
Poornima: Yeah.
Lara: Give me that statement that's not actually a question. Or like totally intentionally
misunderstand the point that I'm trying to make, and ask me that question.
Poornima: Mm-hmm.
Lara: That way I have some practice in knowing how to handle those really sticky moments.
Poornima: So doing this in a practice session and dealing with peers, you're probably gonna feel
pretty good.
Lara: Yeah.
How To Respond To A Question That Is Really Just A Comment
Poornima: But what do you do in that moment where you may get that comment that's a question? How do you respond?
Lara: Totally. I think it depends on the situation. I want to remind everybody, your audience is rooting for you. Whenever you get that, "This is more of a statement than a question." I promise it's not just you feeling the weirdness of that, it's the whole of the audience, too. And you're still in a position of power. You still have control over the room.
Poornima: Mm-hmm.
Lara: And your whole goal is to teach people something new. And make sure that they are leveling them up in whatever the topic is that you're talking about.
You have completely, a complete opportunity to be like, "Thanks for that. Here is how I would either reframe it, turn it into a better question, or answer the question, that you think you really wanted." Provide the information to the audience, too.
Poornima: Mm-hmm.
Lara: Yeah.
What To Do If You Get Asked A Question From Someone Who Is Online
Poornima: That's good. Now I also know a lot of times there are questions that come up where the audience isn't present, they might come up from audio, video, somebody might have written one in, Twitter, whatever. How do you facilitate those kind of questions?
Lara: Yeah, that's a really good question. I think—I hope—it helps to have a good moderator.
Poornima: Uh-huh.
Lara: To make sure that someone can actually help you navigate especially as multiple different sources of information giving you those questions.
Poornima: Yep.
Lara: But by and large, I just try to scan them, and kind of see which ones are the most relevant to my topic.
Poornima: Yeah.
Lara: Or which ones are gonna help me give an answer that will actually level up the entire audience who's listening in.
Poornima: Nice. I like what you said. So you're gonna filtering, but in a way that's gonna benefit the audience.
Lara: Yeah.
Poornima: Not just filtering for the sake of filtering.
Lara: Absolutely. Yeah.
What To Do When You Don’t Know The Answer To A Question
Poornima: So let's talk about the last, the dreaded question, that you don't know the answer to.
Lara: Oh, those are my favorite. Yeah.
Poornima: Yeah.
Lara: I found that just in general in my career, not just in conference settings, but as for standing up in front of my team, or my boss.
Poornima: Sure, meetings.
Lara: Yeah. You have to be able to say, "I don't know."
Poornima: Yeah.
Lara: And you can do it gracefully. Just saying, "I don't know," doesn't mean that you're bad at your job. It doesn't mean that you didn't do all the—no one human can possibly know all there is to know about the topic on which you're speaking. So I like to practice also with that feedback crew saying, "I don't know." And in a really graceful and helpful way.
Poornima: Mm-hmm.
Lara: So maybe like "I don't know. I'll follow up later." And like respond on Twitter when I finally do the research on their answer.
Poornima: Yeah.
Lara: I might just be like, "I don't know. That's a great question. Come find me at the break and we can talk more about it." And my absolute favorite one is to be like, "You know, I don't know the answer to that question, but does anybody else in the audience know the answer to that question could you raise your hand? You should go talk to that person."
Poornima: Yeah. That's great.
Lara: Just totally punt on it.
Poornima: Yeah. No, that's fair. Awesome. Well thank you so much, Lara, for joining us.
Lara: Thank you so much. I appreciate it.
Poornima: Yeah. And thanks all of you for tuning in today. And special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode.
If you've enjoyed this episode, then please subscribe to our YouTube channel. And if you have friends out there who are nervous about Q&A, be sure to share this episode with them. Bye for now.
Lara: Thanks so much.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
All this month we’ve been focused on the theme of pitching. We started out by talking about why many creative problem solvers shy away from pitching, leaving it up to CEOs, founders, and sales people. But, pitching is a really valuable skill that all of us need to hone in order for people hear us out, adopt our ideas, and believe in our solutions.
To help you embrace pitching, we shared the most common mistakes people make when pitching and how to overcome them. Then mentioned that the most effective and authentic pitches boil down to a powerful technique many of already do every day, storytelling. We covered why storytelling is powerful, how to condense a story down, and weave in our credibility.
By now you hopefully understand the importance of pitching, but you might be worried about having to pitch different audiences, and what to do in a setting where you only have 5 minutes or as much as 50 minutes to pitch.
Don’t worry Marie Perruchet and I have you covered! In this final segment on pitching, we’re going to share the various types of pitches you need to prepare.
You’ll learn:
- What to include in a long pitch
- How to condense a long pitch into a pitch that is five minutes or less
- How to modify your pitch to address different audiences
- How to practice your pitch, so you deliver it effectively
Need more help with your pitch? Reach out to Marie on Twitter or on her website.
--
Build is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
--
Episode Transcript
Poornima: Hey guys, we've been talking about pitching. I previously talked about the common mistakes people make when it comes to pitching, as well as some techniques to help you pitch in a way that resonates with your personality. If you missed either of those segments, check out the links to them below. In today's final segment, I'm gonna dive into the various types of pitches you need to prepare.
Welcome back to *Build*, brought to you by Pivotal Tracker, I'm your host Poornima Vijayashanker. Each episode of *Build* consists of a series of conversations I host with innovators, and together we debunk myths and misconceptions related to building products, companies, and your career in tech.
I'm joined again by Marie Perruchet, who is the author of the latest book, *One Perfect Pitch*, and in today's final segment we're gonna dive into the various types of pitches you need to prepare. Now Marie, we are all pretty familiar with the elevator pitch, right? It's 30 to 90 seconds, and everyone obsesses about it. But in your book, you actually talk about having a lot of different types of pitches, or different lengths, right? Having even a longer pitch, and then whittling it down to that elevator pitch. So let's start by talking about why you should have a longer pitch, and what to put in it.
What to include in a long pitch
Marie Perruchet: Yes Poornima, people get fixed on the idea that they should have just one pitch, but actually you need many pitches, because they should be tailored to people you're talking to. If you're pitching a bid to see a company, or a bid to be company, it's gonna be a different pitch you know. If your software is addressing different industries, your story should start with a different character.
And the reason why I say that you should have a longer pitch, is that you should accommodate it, and make it flexible depending on the situation, and that over time, depending on the data points that you get, you rearrange your pitch. Also, why it's important to have a longer pitch, is that you can actually break it down and share the parts that you want to share, depending on the time you have, types of setting, the timing, the location; so many components that you have to include when you're presenting.
Poornima: Got it. So in a longer pitch, let's say we wanted to build our longest pitch, and it was what? Would it be like 15 minutes, or 10 minutes?
Marie Perruchet: It can be an hour, it can be two hours.
Poornima: OK, yeah.
Marie Perruchet: It can be five minutes. But definitely a great pitch would include a hook, a great hook, how you catch attention from people. It should talk about the problem, all the momentum, the achievement, or the breaking news, you know, what's new about your product. Talk about the solution, telling why you're the best at doing what you do. You know, great team, great founder's experience, you've had those awards in design, you learned to build the Siri technology.
Talk about your key differentiators, because so many other companies, all building the same product, or as advanced as you are, or you are belonging to a group and everybody's competing for funding. So you should be able to tell what makes you different and better than the others, and then you end talking, maybe about the market, or talking about the go-to market strategies, and finishing with an ask. You know, how do you want people to help you to build, and share, and keep working at your product.
Poornima: Got it. So your longest pitch has every single element that you talk about in your book, and all those various pieces.
Marie Perruchet: Yes.
How to condense a long pitch into a pitch that is five minutes or less
Poornima: So now, taking things away, that feels scary, 'cause it's like, "Well, yeah, the award was important." Or, having this one key player on the team was really important, so how do you know what to take away for those shorter pitches?
Marie Perruchet: As the minimal available product, you have to test your pitch. And what's important here, and people usually don't pay attention, you should listen. You should listen how people reformulate their pitch, and that was one of my early techniques. You know, when I came to Silicon Valley eight years ago I had no pitch. And what I would do is that, at the time, helping founders, helping them, talking to them, explaining what I was trying to do, and telling them, "Hey, what do you think? What did you hear? Could you articulate what I've just said? What makes sense, is it simple enough? Does it make you think of something else?" So trying to have those open questions.
And then, as you take down notes, if you're quick enough or used to that, or you can actually record with your phone, you know, videotape or just taking your voice recording, and then you replay it to yourself later on. And you see which words people are using. And you know, politicians, they do the same. They test it, and they see what the press picks up. And so, then you have to pick it up again, and then replay it, and practice it again, until, you know, the one day your pitch will be perfectly tailored to the person you're pitching to.
Poornima: Got it. OK, so see how people reformulate your pitch, and what are the highlights that they talk about when they do, and then that will help you kind of condense it down.
Marie Perruchet: Yes.
Poornima: Nice. Do you have an example from any of your readers, or companies that you've coached, where they went from a long pitch to a shorter one?
Marie Perruchet: Yes. So I worked with a company called Autodesk, and we worked with their marketers, and they would send me their pitch and I would review those pitches. And most of the pitches, they're very long, and include information that is not relevant to their audience, or they don't have a very specific call to action. So, I would go over and actually shorten the pieces that were not relevant, and then have them rewrite their pitch so that it would be a little bit more focused.
We start with founders, but also engineers and designers. What we do is that, if they have a 50-slide, or even 25-slide presentation, I'd listen to them, so that's kind of a first run. And then I tell them, "OK, this is what I think is important to highlight, depending on the time we have, and your target audience." And then I have them reformulate it and reframe it, and it gets much easier after we have them practice as well.
Poornima: What are some of the common things that you ask people to take out?
Marie Perruchet: Usually when I work with founders, but also engineers and designers, I like to focus on the story, you know, what makes them passionate about what they're doing, what drew them to work on developing that product or that project, because what I like is that understanding people perspective. They see things that I don't see, and this is from a more technical perspective, and what they do can actually change your situation. So I wanna know what drives them, and what are the problems that they've identified. And then they can share it with others. But you have to be able to communicate it in a very short and concise way, 'cause you know, I've been in the room with investors, entrepreneurs, and after 20 seconds they're being interrupted. So you have to give it right away.
Poornima: Got it. And so what are those pieces that you've seen over and over again, that people might put in that bloat their pitch, that you like to remove?
Marie Perruchet: The pieces that I like to remove is repetition, is rambling, is talking too much about the 50 features and characteristics of their products. I just want to hear about three features, and really defining features. Engineers tend to overwhelm you with too many details, they think that you wanna know more, so you have to understand and tell as much as possible, but this choice, you have to make it for people. You cannot let people make their choice for yourself. You have to work ahead. So don't overwhelm people with too many details, too many features.
Don't talk too much about yourself, but make it relevant how much your past experience is gonna be relevant to lead that team into building the next product. And also I would say, be very concise, and don't beat around the bush from the very first few seconds, or from the very first few lines of your pitch. Go straight away, dive into your pitch right away.
How to modify your pitch to address different audiences
Poornima: In your book you also talk about the importance of having pitches that are tailored to your audience. So question to you, how do you figure out who's in the audience, and then how do you go about doing that tailoring?
Marie Perruchet: You absolutely have no excuses for not knowing who's in your audience.
Poornima: OK, good.
Marie Perruchet: There's so many ways today, on the internet, to get information, and pull information about people, their taste, their location, what they're doing. If you're working in a company, you have to ask your workmates, you know, what a person likes, or is it a great timing for you to pitch to them, getting as much information internally. And also, for example, if you're speaking at a conference, you have to know beforehand, you know, the profession, the level of expectations. When I run a workshop, usually I send a survey before, through Google Docs, and ask people, you know, your expectations, how much they're knowledgeable, so it's great, kind of a quiz to engage people, and making them feel that what you're gonna say is going to be for them.
Poornima: Yeah, I think that's really important, tailoring it to the audience, and doing your homework ahead of time, to knowing what that audience is. Now, I do know a lot of times people get overwhelmed because they think, "OK, my audience is going to be a bunch of engineers, and there's a lot of different levels of engineers. How do I whittle it down to, maybe the beginner, versus the advanced, etc." So walk us through how you would whittle it down, once you have an idea of who's gonna be in the audience.
Marie Perruchet: So you cannot address everyone in the room, but who are the people, the target audience, who's gonna be the most relevant to grow your product or your business. So maybe you would pick a couple, or maybe three examples, you know, three case stories that is going to appeal and help the audience think that you're trying to relate to their own problems.
So let's say, today when you pitched the interview to me, Poornima, you know we are both women, both interested into public speaking, we love video and talking about skills that can be relevant to specific audience. So already you had me there, 'cause I knew you knew me, I can see you did your homework and research, and took the time and effort to make it relevant. Because we are all busy, we have less, and less time, we have very short attention span. So right away you have to be extremely precise, and be relevant, to engage, and actually instigate people to listen and keep listening to what you have to say.
Poornima: I really like what you said about, you can't address everyone in the room, 'cause I know a lot of people try to please everyone, and they're just...it's not gonna happen. So yeah, definitely tailoring it, making sure it's relevant, to even a handful of people, can be really valuable. I know the last thing that you talk about when it comes to preparing, is actually doing the preparation practice. Walk us through what you recommend when it comes to practicing your pitch.
Marie Perruchet: Many founders and entrepreneurs, engineers, designers, they wait for the last minute to practice their pitch. I've worked with this head of a Google Glass competitor, Japanese CEO. We practice, and I say, "OK, you have to practice at least 20 times." He said, "No, I will practice 200 times."
Poornima: Oh, wow.
Marie Perruchet: And I was quite impressed, because the reason why you have to practice, and it's one of my signature exercise that I do during the corporate trainings, is that I have people line up, like speed dating, but they have to pitch for a minute, and then they switch and then they do it again. And I can tell you, the first few minutes, people are bored, and then the pitch ends after 20 seconds. But then, after they do it like four of five times, I have to yell and tell them you have to stop. 'Cause first, you know, they get inspiration, they get idea, and they go straight to the point. They cut to the chase, and they don't give information that's not relevant anymore, because they see that effect that they have on the face of their audience. So practice is very important. Also, practicing in a room, meaning that every time that I go and speak to a conference I arrive an hour before, to do the recognition of the room, knowing where I'm gonna walk, where I'm gonna get closer to my audience so that I don't ostracize part of the room, because otherwise that part will leave the room, and as a speaker, you don't want that.
And I would say the third advice that I would give, is practicing using the technology. So you can use your tablet, you can use your phone; so you record it, and that's OK, to look at yourself. I know we are all the worst judges of ourselves, but then you play it with the sound and no image, without the sound with the image, and you can see and correct all your filler words, your repetitions, the “ehm, uhm,” but also if you're flapping your arms, if you keep touching your nose, or playing with your rings. And then, over time, maybe you're not gonna change overnight, but you learn how to be aware, what are the mistakes, where you can improve, and then manage it over time, and manage that anxiety of public speaking, but also knowing that your story cannot be perfect from the very first day. It takes time and it needs adjustment, you need to tailor it, and also understanding that it's for your audience, it's not for yourself.
How to practice your pitch, so you deliver it effectively
Poornima: That's great Marie. So how do you know when it's ready to go?
Marie Perruchet: How do you know if your pitch is ready to go? Don't wait. You have to do it right now, and start practicing with your friends, with a colleague. Great way to say is, "I have an idea, I have to present it to the management, to a partner, I'd love to get your feedback." Make sure that the person is qualified to give your feedback, not everybody is able to do that. But, "Hey, can I have a few minutes of your time? I'd like to run a few ideas." And then, take notes, or videotape or record with your phone what they've just told you. You have to be able to listen. Integrate that feedback, and then replace it in your next pitch. But don't wait, you know, the previous night before your presentation, to pitch. You have to practice beforehand, because also what's important, is that you will see the journey, and it will give you a lot of confidence.
Poornima: Yeah, I think that's valuable. And as you record yourself, you do see that progression. So, I know for a lot of people that I coach, they then realize they have made a lot of progress, because it's been captured.
Marie Perruchet: Absolutely.
Poornima: Well thank you so much Marie, for joining us, and I know our audience out there is gonna get a lot out of these segments. And be sure, audience, to check out Marie's book, *One Perfect Pitch*. And for people who wanna get in touch with you, what's the best way?
Marie Perruchet: To me what's important, is impact. I'd love to hear from you guys, you know, check the book, dive into the exercises, learn how to work around a method, and get back to me, tell me how it impacted your work. Whether it helped you refresh your ideas, your communication, pushed you to pitch more. I'd love to hear you, so you can connect with me on LinkedIn, Marie Perruchet. You can follow me on Twitter, send me messages through Instagram as well. You know, I love text messages, so please get in touch, I'd love to hear from you.
Poornima: That's it for our episode on pitching. Be sure to subscribe to our YouTube channel to receive the next *Build* episode, and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
One of the reasons people don’t like pitching is because they feel like they have to be someone else. They have to abandon their personality, get into character, and speak in a way they normally wouldn’t in order to impress a colleague, customer, or investor.
However, people on the receiving end of the pitch are going to see through and disengage quickly. A sales-y pitch is one that isn’t rehearsed and the person pitching hasn’t taken the time to figure out how to engage their audience.
What we don’t realize is that we don’t need to change who we are or how we speak to engage audiences. Many of us are already practicing a powerful pitching technique in our everyday lives, storytelling. And when we deliver stories in a conversational approach we come off as clear and authentic.
But we may still be opposed to starting a pitch with a story. We worry about it being too long or short, and the theme and details resonating with the audience.
Well in today’s Build episode, Marie Perruchet author of One Perfect Pitch: How to Sell Your Idea, Your Product, Your Business or Yourself is back.
You’ll learn the following from Marie:
- Why storytelling is a powerful technique for pitching
- How you can tell a great story in a business setting
- How to condense a long story so that it is short and to the point
- How to weave your credibility into a story
- Why most demos fail – hint: it’s because they fail to walk an audience through a story
- How to incorporate an ASK into your pitch
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Episode Transcript
Poornima: Hey, guys. I'm back today talking about pitching. In the last segment, I covered a lot of the mistakes that people make when pitching. If you missed out, I highly recommend you check it out. The link to the video is below this one. Today I'm gonna dive into how to pitch in a way that resonates with your personality.
Welcome back to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Each *Build* episode consists of a series of conversations I host with innovators, and together we debunk myths and misconceptions related to building products, companies, and your career in tech. Today we're gonna continue the conversation around pitching, and I'm joined by Marie Perruchet, who is the author of the latest book, *One Perfect Pitch*. Thanks again for joining us today, Marie.
Marie: Great to be here.
Why storytelling is a powerful technique for pitching
Poornima: Last week we were talking about a number of mistakes people make when it comes to pitching. Now I want to shift gears and talk about how we can pitch in a way that resonates with our personality so that we feel effective as people who are pitching. I know one of the techniques that you talk about in your book is storytelling. But a lot of people have an aversion to starting a pitch with a story, because they're not sure how to craft one. They worry about whether it's too long or too short, and they want to make sure that it really resonates with the audience. So let's just start by talking about why storytelling is an effective technique to start your pitch with.
Marie Perruchet: I love storytelling. You're born and then your parents, your family, reads you stories. I grew up with stories from Charles Perrault, from Brothers Grimm. You know Cinderella...the first story of Cinderella was found in the fifth century in China. And since then you have more than 1,400 versions of Cinderella. Take Japan, the Japanese telling stories using animation. Think about in China there was this guy who would hang around and sell candies and actually would tell stories to sell more candies. And so if you're thinking about the story of immigration in the U.S., the show and tell that kids learn how to do at school, the kids would talk about their fluffy toy. That was a great way to have kids from immigrants who wouldn't speak the same language unite around a story. And when you think of what storytelling is today for technology companies, which is the main industry here in Silicon Valley but also blossoming in other countries, storytelling talks about transformation, and that's what technology companies are doing, transforming a certain industry.
How you can tell a great story in a business setting
So storytelling is a very powerful technique because it's something that people know already, they grew up with that. Every weekend you're telling your friends stories, how you got away from a parking ticket, or how, in my case, I have lost my passports, or how the toast you did for your friend's wedding didn't go so well. So we all know how to tell stories, except in a business perspective, in a business setting, it has to be very short because we can not spend hours telling stories.
So how do you tell a great story? First, think of the pitch meet being a mini story that creates emotion. So stories are a way to start and that's the method I describe in my book. You start with the problem, talk about the solution, and then finish with an ask that is the transformation.
A great image to remember is the image of the rainbow. There's the rainbow, there's the storm, that's the problem. The rainbow, talk about the solution, and then supposedly there's a pot of gold, which is the transformation. So whenever you want to tell a story, there should be a beginning, a middle, and an end. And you know the James Bond movies, they all start with something that grips you to your seat. Think about the Cinderella story, at the end there's a transformation. That's what storytelling is about. There's a problem, there's tension in the beginning, there's a resolution. That's what we want to hear because it creates a tension, it creates an emotion, and we want to follow up.
Poornima: OK, so for our audience out there, start with the problem, and that will present a good tension point to hook the audience right from the beginning.
Marie Perruchet: Absolutely.
Poornima: Now, I know another concern is having the story be too long or too short. How do you recommend it being just the right length for the pitch that you're doing?
Marie Perruchet: People shouldn't worry so much because a story takes time to craft and to refine. Anyone is able to tell a story for an hour, for two hours, but it takes a lot of practice to chop it to maybe a minute. And there's so much you can tell in a minute. The radio pieces I used to tell would be a minute long, and there's so much you can tell in structure. So people shouldn't be worried about that because the story changes over time and you should practice it.
How to condense a long story so that it is short and to the point
Poornima: So how do you condense that hour-long story down to a minute? Do you have an example?
Marie Perruchet: I advise founders, engineers, and designers to take a page, write their story, look at it, and then eliminate two thirds. And those two thirds should be anything that's not relevant or that's not gonna interest their audience. Anything that's not precise, that doesn't have data or numbers, you should get rid of it. Any personal opinions shouldn't be there. That's the first step.
The second step, when you want to know about your story you should focus on different parts like they're LEGO parts, because each part should be breakable. Imagine yourself at a cocktail party, you start pitching and somebody comes and interrupts you. So you should be able to tell those parts very separately and if you put them together they work very well. So think about what's your hook, how do you start your story? How do you differentiate yourself? How do you bring up the solution? Talk about your team.
So each segment should be a minute long. And it's very easy. If you're taking your Word document, there's a word count. It should be between, I believe, 150 words per minute. You can use your calculator in the toolkit for the Word document to calculate it. And then you practice it and you should be very slow, very articulate, especially if, like me, you're non-native English speakers, so that people can get used to your accent.
How to weave your credibility into a story
Poornima: Nice. Now, I know another thing you talk about is credibility and leading with it. How do you recommend people lead with that credibility?
Marie Perruchet: I'm gonna give you an example. When I meet people and they don't know me or they want to question my expertise, I tell them that I'm an award-winning journalist, worked for the BBC in three countries. I've also written a book at McGraw-Hill on the art of writing your pitch called *One Perfect Pitch*. You are establishing credibility giving examples or giving awards or giving achievements to people about what you've been doing in the past so that you can create trust.
Poornima: Right. Now, I meet a lot of people who often will tell me their credibility and they'll mention things that maybe happened 5 or 10 years ago that may not be relevant to the work that they're doing now. So how do you create credibility when you're just getting something off the ground?
Marie Perruchet: I worked with engineers, with founders and designers to create credibility from the ground, and when you think that nothing happened in the past 10 years, yes, something did happen. But you need to really look into it and work and find out, what you're doing today, you didn't get up in the morning and start it. It comes from somewhere and I want to know that. I want to know why you and why not somebody else. One great way to do it is ask your friends, "Why do you think I'm so passionate? Why do you think I'm working every day for 12 hours a day and building and developing my product or my startup?" Ask people you've met with or you've worked with, "This is what I'm doing right now, but I'm unsure, I have doubts. What would be the reason why I should pursue it? Could you help me and shed some light?" Understanding what is your path, your passion, for me, writing a book has been very transformative because I could find out why I was so passionate about storytelling and that storytelling has been with me my entire life.
Why most product demos given during pitches fail
Poornima: Now, I know another technique is the proof is in the product. Especially for those of us who are engineers and designers, we like to have something tangible to show. Can you talk about demoing a product? I'll admit, I've done a lot of terrible demos in my past. How would you recommend people have an effective demo of their product?
Marie Perruchet: Yes, people tend to overlook their demo. They work on their questions, they work at telling what they're good at, sometimes telling about the problem if it's great, but they think, "OK, I'm just gonna do the demo on the fly." But the demo should be extremely prepared because if you need Wi-Fi, you don't know any technical issues. I lived in India, I know about electricity cuts happening all the time. So you never know and you want to be prepared. So don't depend first on your demo to explain your product.
The second thing would be have somebody else handling all the technicalities so that you don't have to worry about that. And the third thing would be, of course, practicing your demo. We worked with a client who was presenting a product to Samsung, and what we did is that we took it from...it's like a journey or taking a trip from A to Z. From the moment you have to click on the button to get into the software to the moment you have to scroll down the menu, you have to show all that. Maybe you have to spend 20 minutes or 30 minutes, keep it maybe under 10 minutes. A couple of minutes is great, but you have to go step by step so that the person understands from their user's perspective what they have to do to get to the product.
Poornima: Yeah, I like what you said about the user's perspective, and I know in your book you talk about even presenting a scenario. Not just like, "Oh, let me show you my product, and here's how you sign up, and here's how you get started," but having a very directed workflow maybe based on a specific use case.
Marie Perruchet: Yes, so you can also do that. If you can show the product, people always like to see something tangible. When you're bargaining in certain countries, you want to show the dollars, the euros, the money that you have. What you can do if you don't have the product with you, you can pick a name. This is Kate, this is Andrew, this is Jane. Jane starts her morning that way. This is what her journey looks like. This is her problem, this is the problem she faced, and this is how our solution helps her transform her day.
Poornima: Nice, so yeah, that's very relatable and that comes back to incorporating storytelling into your demo.
Marie Perruchet: Yes, because behind every product there's a team, there's a leader, and we want to know the struggles your team are going through to give birth to that product.
How to incorporate an ASK into your pitch
Poornima: And finally, there's the ask, which you talk about incorporating into your pitch. But again, depending on backgrounds, you both feel like that can be really sales-y or sleazy. So walk us through why it's important to have an ask at the end of your pitch and how to craft one.
Marie Perruchet: To me, a sales-y pitch is a pitch where people have it rehearsed, and they don't really connect and they only talk about themselves. So an ask at the end of the pitch is another great way to reconnect with the person if by any chance you've lost her or him during your presentation.
So why finishing by an ask? Because every story has an end. And you're telling this story, imagine you've created a tension, you've got people very excited about the problem because they felt, "Oh, they're relating to my own problem, they brought us a solution." But then, nothing happens at the end of your story. You leave them in a state of anxiety. So people, if they've been seduced and excited by your idea, they want to help. So you have to give them clear directions.
For example, "Hey, I'd like to have an intro to that person to support my project. I need more resources. What can you do to help me fund that project?" Be extremely clear, and I know in American English it's much easier. In certain countries, you don't want to be so direct, but find a way to have your team or the person or your subject act on something. Just don't leave it like this because people want to help. They want you to be successful, so what can you give them so that they can help you?
Poornima: That's fantastic. Thank you, Marie. This has been really helpful.
Now Marie and I want to learn from you. What additional techniques have you tried that have worked as you've been pitching your ideas? Let us know in the comments below and the first three people to respond are gonna receive an autographed copy of *One Perfect Pitch* from Marie.
That's it for this segment. Be sure to subscribe to our YouTube channel to receive the next and final segment on this topic of pitching, where we'll talk about the various types of pitches you need to prepare. Ciao for now!
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Have you ever had an idea for something, like a process or product that you wanted to improve? But instead of sharing your idea with others like your friends or co-workers, you just kept it to yourself because the thought of having to “pitch it” felt icky and salesy?
Many of us who are creative problem solvers feel this way.
Since pitching doesn’t come naturally to us, we just leave it up to CEOs, founders, and sales people.
However, pitching is a really valuable skill that all of us need to hone, because only if we pitch our ideas will people hear us out, adopt them, and believe in our solutions.
In today’s episode of Build, we’re going to tackle a number of misconceptions people have about pitching as well as the common mistakes people make while delivering them.
In future episodes, we’ll talk about how you can pitch in a way that resonates with your personality and the various types of pitches you need to prepare because it turns out that an elevator pitch isn’t enough!
To help us out, I've invited Marie Perruchet (http://www.oneperfectpitch.com/about-us), who is the author of the latest book, One Perfect Pitch: How to Sell Your Idea, Your Product, Your Business or Yourself (https://www.amazon.com/One-Perfect-Pitch-Business-Yourself/dp/0071837590).
Even if you don’t plan on pitching anything in the near future, chances are someone is going to pitch something to you: a project or a product, and you need to be able to filter the best from the worst!
So I highly recommend you watch this episode to learn:
- Why no one is a natural when it comes to pitching
- How to get over the discomfort of pitching
- Why you can’t stop at the first NO
You’ll also learn the 3 most common mistakes people make while pitching and how to avoid them such as:
- Not taking the time to make people care enough about your idea.
- Not realizing that most pitches are shared.
- Overwhelming people with data.
--
Build is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
Episode Transcript
Poornima: Pitching an idea feels icky and salesy and for those of us who are creative problem solvers; it doesn't come naturally to us. So, we just end up not doing it all together, leaving it up instead to founders, CEOs, and sales people. However, pitching is a really valuable skill that all of us need to hone, because only if we pitch our ideas will people hear us out, adopt them, and believe in our solutions. Today, we're going to tackle a number of misconceptions and mistakes that people make when it comes to pitching and in future segments, we're going to talk about how you can pitch in a way that resonates with your personality and the various types of pitches you need to have prepared.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Each *Build* episode consists of a series of conversations I host with innovators and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Today we're going to be diving into the misconceptions around pitching and to help us out, I've invited Marie Perruchet, who is the author of the latest book, *One Perfect Pitch: How to Sell Your Idea, Your Product, Your Business or Yourself*. Thanks for joining us, Marie.
Marie Perruchet: Thanks for having me, Poornima.
Poornima: We met at a conference earlier this year, and as I recall it, your background is not in tech. So, walk us through your background and what lured you into tech.
Marie Perruchet: My name's Marie. I grew up in Normandy, originally from South Korea, born there and was adopted to French parents. Because I always loved traveling, my first career was actually being a journalist.
Poornima: OK.
Marie Perruchet: I was a radio journalist and I started out from Brussels, then I decided to move further and I worked for the French National Radio from New Delhi in India covering politics, earthquake, and two years later I thought it would be great to also work from one of larger clients in Asia, so I moved to Shanghai where I worked for the BBC. And then after, that was my big turning point, because I moved to Silicon Valley. In the beginning, I was covering some tech, but mainly it was for the Presidential elections for former President Obama, end of 2008. You know, when you arrive here, you realize that first you don't have to use VPN to get access to information coming from China. But also that everybody is embracing entrepreneurship and that means that you have a laptop, you have a Wifi connection, and you have an idea, and you want to see if you can put it through and then push it to the market.
I thought it was very exciting, so I thought, "OK, what's going on here? What can I do?" I always loved helping people tell their own story through the media, but at the time, it was a big explosion about the platforms. How do you communicate your company's story, how you can communicate about yourself, how do you go for funding? And I started helping entrepreneurs and startup founders communicate that story to the world and also to investors here, but also users and partners. I mentored at different incubators, including 500 startups, mentored at Japanese, Korean, Chinese incubators here and then starting having my own clients helping them communicate their idea for funding, but also on their website, on social media. And I'm going to corporate training where I brought these large companies here, because you know internally you also need to be able to present your ideas effectively in very short formats, because people they have very short attention spans.
Poornima: Yeah. That's a lot of great work that you've done around pitching. What then inspired you to go from doing that work to writing the book, *One Perfect Pitch*?
Marie Perruchet: So, you know when you're a journalist, you think that down the road you're going to write a book at some point.
Poornima: OK.
Marie Perruchet: But I was not a journalist anymore. And what happened is that I was featured in the *Wall Street Journal* for my work and McGraw-Hill they actually pitched the book idea to me.
Poornima: Oh, that's great.
Marie Perruchet: Yes. And I said yes, even without knowing what it means to write a book.
Why People Find Pitching Uncomfortable
Poornima: So, I know a lot of people don't enjoy pitching, they don't feel like they're good at it, they're not a natural, they might be shy or introverted. How do you help people get over those situations?
Marie Perruchet: First of all, people should think about why they're so uncomfortable pitching. And it has to do with...you know, think about your business ahead. So, it takes a lot of time to think about it and it takes a lot of preparation knowing your user, what your business does, your brand identity, your identity. So, that's why it's very important to think ahead about what you're trying to convey. And then when you're confident about your idea, it makes it much easier to be able to pitch your idea. The second thing is also practice. Don't wait for the last minute for people to feed you questions to pitch, because here it's very competitive. People are coming from all over the world to go for funding, look for funding, but also trying to get and acquire users and customers. And I would say the sort of thing that I tell people who feel shy, “OK, maybe you're doing this presentation, maybe you're pitching, maybe it doesn't go so well as you think, but you have to keep going back to the stage in the room and keep pitching until your idea goes through.” So, you can't stop at the first “no.” You have to keep doing it.
Poornima: Yeah. Yeah, that's a really good point.
Marie Perruchet: Of course, if you're looking on the internet, if you're looking at great speakers, think about in 1988 at the Democratic Convention, there was the Arkansas governor called Bill Clinton. He was a very, very bad presenter at the time, but you know how much money he makes today while speaking. So, nobody's ever a natural. There are techniques and you need to acquire those techniques to feel more comfortable and manage your anxiety.
Pitching Mistake #1: Not taking the time to make people care about your idea.
Poornima: There's also a number of mistakes that people make when they are pitching and you cover some of them in your book. The first one is not taking the time to make people care about what it is you're talking about. So, what exactly does that mean, and how do you make people care?
Marie Perruchet: How do you make people care when you're trying to convey an idea? You have to put yourself in the shoes of your audience. So it means that you have to have empathy because maybe you got that idea from the closet of your room or from your garage or from your basement if you're living on the East Coast or in any other countries, but you know you have to understand how your product, your service is solving a problem for the person who may buy that product from you. And that's why when you're a founder because you're so entrenched in the work, you need to take some perspective and really put yourself in the shoes of your audience.
Pitching Mistake #2: Not realizing that pitches are shared.
Poornima: We also have people in our audience who are very technical, and a lot of times when they are presenting an idea, the get really bogged down in that jargon, which may not be comprehendible by somebody who is not technical or on the business side or has some other expertise. So, how would you explain to them how to manage that?
Marie Perruchet: So, they should think about how to make their pitch simple, because whoever they're going to pitch it to, that person is going to pitch the idea to somebody else. So that's why they have to make it simple. For many founders, their biggest problem is knowing where to start their pitch. And in my book, I describe three ways to start your pitch. The first one is telling how you're solving your tech problem. No, the first one is telling about the problem that you're trying to solve. So putting yourself in the shoes of the person. Another way to start your technical pitch is talking about the breaking news. What's the latest about your product or your idea? Maybe you've just debugged something in your software or you've just released a new product. Something that makes it exciting for people. And the third way to start your pitch, when it's a technical pitch as well, is talking about all the achievements that your team has achieved in the past week or in the past month, so that's a great way to grab the attention of your audience.
Poornima: Yeah. Now, I know another thing you mention in the book is having a universal story, right? And this is something you can start your pitch with. So, walk us through, what exactly is a universal story?
Marie Perruchet: I recommend founders to start with a universal story, because that's how they find something that they can have related to what they're doing, meaning that founders think that what they are doing is very unique and very special, but if you're looking around, you realize that maybe 10 companies are doing the same thing as you're doing.
Poornima: Sure. Yep.
Marie Perruchet: And when you're thinking about the people who are going to buy your product or your service, they cannot just be your family or your close friends. You have to understand that hey, this product could be used in that country in that segment, in that market and make it relevant for everyone.
Poornima: Do you have an example of a reader or somebody that you coached to come up with a universal story that you could share with us?
Marie Perruchet: Yes. I've coached a company that were developing sensors and those sensors were actually bees and those bees were able to detect some substance, illegal substances for example, and what we found out is that the founder, his grandpa was actually the largest exporter of honey from Turkey. And so everybody understand honey, everybody understand bees, so that's where universal, because it's a common in plain English in English language that people can use to convey their ideas.
Poornima: Got it. So you started with that, and then talked about the sensors rather than starting with sensors, which people may or may not understand anyway.
Marie Perruchet: Exactly. Because you always have to think that people are going to pitch for you, as I'm pitching about himself today. I need to be able to understand and the more simple you make it, the easier it travels.
Pitching Mistake #3: Overwhelming people with data.
Poornima: Yep. So simplicity's important, but I know a lot of us in tech love information and data. One of the things that you talk about in your book is sometimes we don't present enough information or the data that we share isn't the most relevant or can be confusing. How do you recommend people decide on how much information is enough and how to present data that's valuable?
Marie Perruchet: Well, I love data. Most of the time, people they tend to overwhelm people with data, so you have to maybe—for example, if you're thinking about a slide presentation—just maybe one data per slide, that's enough. Not 50 data per slide.
Poornima: Yeah.
Marie Perruchet: And also, when they're saying, "Oh, not enough data," what they mean is that they're not precise enough. Sounds like high level or it's too much jargon, but we don't really picture in our mind what it means, so the more precise you are with your data, the better it is. For example, in a span of three weeks, our traffic increased by 50%. So that's very precise, instead of saying that, "We've got great traction in developing our product." That doesn't mean anything.
Poornima: Got it. And so showing kind of the growth trend could be one way of representing it. Are there other techniques that you talk about?
Marie Perruchet: To talk about traction?
Poornima: Mm-hmm.
Marie Perruchet: You can say traction in a short amount of time, saying like in a month, required X number of users. That could be another way to show it, so growth, but also, “Our application has been number one for six consecutive weeks or six consecutive months at the Apple Store in three countries.” And you're not bragging but you're just stating the facts and it gives context to people because imagine what you're pitching, other companies are also pitching. So how do we get the right context to make a decision about should we have the next meeting?
Poornima: Got it. Well, thank you so much Marie. This has been fantastic. Now Marie and I want to know, are there mistakes that we haven't covered in this segment, that you're worried about making? Let us know what they are in the comments below and we'll be sure to address them.
OK, that's it for this segment. Be sure to subscribe to our YouTube channel to receive the next segment where we'll continue the conversation and dive into how to create a pitch that resonates with your personality. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Every product release our goals are the same: we want to show customers we care about meeting their needs and we want to stay ahead of our competition! So how do we get it all done? We cram as many features and bugs as we can think of. Cutting back is for complainers!
Is it really?
Or… is it hard to estimate how long a feature is going to take to build and a bug to fix? And by not cutting back are we jeopardizing the quality of the product we release and sacrificing the sanity of the team?
We get that this is an age old struggle. It’s hard to challenge business goals, and start a conversation within your team about why you aren’t going to do something without being seen as a slacker.
If you or your team has struggled to figure out what will produce quick wins, what to ignore because there is no value, and what may be too complex to pursue in a single release then you’ll want to watch today’s episode! In today’s Build Tip you’ll learn:
Be sure to share the episode with your teammates to help them understand the importance of cutting back!
Transcript
Poornima: What's the matter? What are you doing?
Ronan: I'm getting ready for the next release.
Poornima: And this is how you get ready?
Ronan: Do you know how many features and bugs we have to get into it? I'm to sure we're going to be able to make the release in time.
Poornima: Have you thought about cutting back?
Ronan: No way. Have you spoken to the customer recently?
Poornima: I think we're going to need to cover how to cut back in today's *Build* tip.
Why People Choose To Cram Versus Cut Back
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host Poornima Vijayshanker, and today I've got a new *Build* tip for you. I'm joined by Jay Hum, who is a project manager at Pivotal. Now Jay, we run into this issue over and over again where we commit to a lot of features, a lot of bugs, because we want to meet business goals and we want to make our customers happy. But we can't cram it all in. And I know time and time again we tell people to pare back, but they don't, right?
So let's start by talking about why people don't pare back.
Why It’s Hard To Estimate How Long It Will Take To Build A Feature Or Resolve A Bug
Jay Hum: So before I answer that question, I think it's important to bring out that software development's always notoriously difficult. And estimating the amount of effort that goes into any type of release feature or functionality, is even more difficult, right?
So, for example, if a developer comes to me and says, "This is going to take two days," then I multiply that two and then add two days to it, so it's actually going to take six days instead of two days.
Why It’s Important To Cut Back On Features And Bugs For Each Release
Poornima: So why is it even important to pare down a release?
Jay Hum: So customers always ask for a lot of features and functionality, and then even the development teams, the product manager, the designers and developers, they always have their own ideas of what should go into a release or feature. But at the end of the day, until that product is out in the market, you're actually never going to know what features or functionality the customers are actually going to use.
There's lots of evidence out there that when you're dealing with customers, they'll say one thing but you go look at the analytics and they're actually doing something else, right? So the danger in creating this big release that has tons of features and functionality, is that you can sort of create something that's sort of an analysis paralysis in terms of what the user's experiencing, right?
So if they get a new release and there's so many new features and functionality they don't know what to do, so what they end up doing is not doing anything and just going back to what they were doing originally. The second part is that you always want to sort of relate it back to web business goals or metrics that you are trying to achieve, right?
Again, you want to focus on some of the top priority task features that will drive the most business value or move a KPI, whether that is to increase engagement or move people further down the funnel.
What Happens When You And Your Team Commit To Building And Fixing Everything
Poornima: What happens if we commit to everything?
Jay Hum: Well, in Ronan's case where he's all stressed out and it's a big release, I mean I've heard this story before, and essentially the short answer is disaster, right? But let me unpack that a little bit.
So, first of all, you've already seen that Ronan's very stressed, right? So if you don't pare down the release you are effectively going to burn out the team. Not just the developers but the product manager, the stakeholders even, the quality engineers, and the designers.
Poornima: Is there anyone besides the team they're going to upset?
Jay Hum: Yeah, obviously you're going to upset the customer. So generally when the team is overstressed or burned out and really pushing hard and cranking through the night, effectively, they're not going to write good-quality code and they're going to accrue technical debt and it's going to be messy and they're going to cut corners, right? So that means that the product that eventually is going to be shipped is going to be subpar, it's not going to be up to the expectations of the client or customer, and again, they're just going to get turned off and very disappointed.
How To Evaluate What To Work On And Commit To Using A Simple 2x2 Matrix
Poornima: I know there's been a lot of conversation and debate on how to pare down features, what bugs to include or not include. Do you have a simpler solution you can share with the audience?
Jay Hum: Yeah, my go-to solution is a two-by-two matrix. That works very well in helping us prioritize which features should go into a release and which features should fall out. So it's a two-by-two that allows us to rank any features in terms of value to the customer as well as complexity to implement.
And it's great because it actually gives you information on four different things. So it'll give you information on which of the features you should actually be doing or working on, as well as which would we call sort of the quick wins that you can do very quickly and looks like you're making good progress. It'll show you which features that you should ignore because they don't have any value or they're too complex, and other ones that you should debate around in terms of product strategy and roadmap.
Poornima: Now Jay and I want to know do you guys have a go-to method for paring down features at your company. Let us know in the comments below.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
All this month, Joy Dixon and I have been digging into the theme of working on side projects that you’re passionate about. We started out by talking about how to keep your day job and pursue your passion project on the side, and last week we talked about how to keep your passion project moving along when you physically can’t.
In today’s final episode, on side projects for this month, we’re going to talk about how to keep your passion project growing despite challenges.
When we’re just getting started all the passion we have for our side project makes us feel like we can tackle small challenges that come up every day. But over time we start to uncover bigger challenges like funding, dealing with regulations, lacking experience, and missing self-imposed deadlines and milestones.
When we hit one of these challenges we feel stuck. Our side project stops growing, and again we’re tempted to quit.
Instead of giving up, it might be time to re-evaluate the direction and purpose of our side project.
In today’s episode Joy is going to share how she responded to all the challenges she ran into while setting up and growing her side project Mosaic Presence. You’ll learn:
Know someone who is starting a side project? Please share this episode with them!
Transcript
Poornima: Previously, Joy and I dug into why it's totally OK to keep your day job and pursue a side project. We also talked about how to manage your time and your energy. If you missed either of those segments, I highly recommend you check them out. I've included the links to both of them below this video.
In today's segment, we're gonna tackle the final topic: how to continue growing your side project, despite the bumps.
Welcome back to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Each *Build* episode consists of conversations I have with innovators. Together we debunk myths and misconceptions related to building products, companies, and your career in tech. Thank you, Joy, for joining us again.
Joy Dixon: Hey, great to be here.
Poornima: It's been two, two and a half years since you started Mosaic Presence. Surely you've hit some bumps along the way.
Joy Dixon: Yes.
Poornima: In those bumps, as you were experiencing them, how did you respond to them?
Joy Dixon: I took them all as learning opportunities. There was a lot I didn't know. I was very clear about being in the classroom. Very clear about teaching code. But a lot of the other parts of it—like creating my business, incorporating all those different I's and T's—I did not know about those. I really just took it in stride. I was like, "OK, cool. Now let me jot it down and I can share this with the next person."
Poornima: That's awesome. That kind of answers my next question, which is, what did you learn from that? It sounds like you learned a lot.
Joy Dixon: Totally. I learned a lot, how to actually set your business up, how to establish it, how many, where the offices are in the city of Oakland who are like, "Go and file this paperwork." So I really just took it all as a big learning opportunity and it's just really great. It was really great.
How To Embrace Not Being Ready
Poornima: One of the things we talked early on about was being ready. Since you didn't know all this stuff, it didn't make you feel like you weren't ready to do it?
Joy Dixon: No. That thing called Google has really instilled a lot of confidence in me. I would really just go Google. So many people put out so much great material, like yourself.
Poornima: Thank you.
Joy Dixon: Right?
Poornima: Yeah.
Joy Dixon: So you can just follow along, learn some things. It's really easy to just keep moving forward.
Why You Need To Build A Support System For Your Side Project
Poornima: Nice. When you did hit those bumps, in hindsight we're like, "Oh yeah, it was a learning opportunity." But they sting in that moment, right? It's like, this is really difficult. Yeah, I'm sure I'm gonna look back and learn on this. How did you manage that moment when the bump hits you?
Joy Dixon: When the bump hit me, I leaned on my loved ones. Honestly. My best friend, my inner circle. Because the bump hit, and it was a really big bump. Yes, without a doubt, on this side of it, it's a learning opportunity. But in the midst of, and I remember the exact moment when there was so many things coming at me, but the exact moment is when my MacBook Pro just went blank. And I was like, "Oh my goodness, this is it right?" That was the moment that I pretty much lost it. 'Cause I was like, everything was rolling and even I hit bumps I could still manage. But I was like, "Everything is on this machine." Thank goodness for the people in my life, really.
Poornima: Building a support.
Joy Dixon: I would tell people, have that support system. They don't have to be in the same field you are, they just have to support you. That's really so important.
Poornima: Nice. Again, because we're in that moment, we think, "OK, we can get through this." But there comes a time where we keep hitting those tough bumps. And it can kind of phase us, right?
Joy Dixon: Yes.
Why Keep Your Side Project Alive Even If It’s Not Growing
Poornima: Why did you decide to keep going in spite of?
Joy Dixon: Really what I did, was I stopped and I looked at what was really causing a lot of the pain for me. It was really my timeline. It was my timeline. 'Cause I had said, I wanted this completed by this. When I initially opened up Mosaic Presence and started doing it, I was like, "Oh. Four months. I'll be done. It'll be up and running. I'll have 30 students two weeks after that." Right?
Poornima: Yeah.
Joy Dixon: None of that came to fruition. It was really, "Wow." Sad to learn how to let go and just keep moving forward. Have a direction, but not be attached to the outcome. That was really what made it easier to go through the process, 'cause it was really my struggle and my holding on tight and wanting things to go my way that was really causing all of my extra pain.
Poornima: I like what you said about the timeline, 'cause this is something I talk to a lot of founders about. Those who are both technical and nontechnical. It's just, “We anticipate it taking three months, six months,” it ends up taking—heaven forbid—a year.
Joy Dixon: Yes.
Why Our Self-Imposed Deadlines Slip And Having A Day Job Helps When They Do
Poornima: Sometimes 18 months. I think going back to the overall theme, that's kind of why it's nice to have that day job, to have a little bit of a footing and continue that side, because you don't know how tumultuous it's going to be. I think that's hard for people to wrap their head around, "Why would it take double the time? Why wouldn't it be done tomorrow? Why can't I just fix this thing with one pixel? Why is this not a five-minute fix? Why is this a five-day or a five-month sort of thing?"
Joy Dixon: It really is so true. And that's so good to put that out there for everybody to really understand that. Having a day job made it easier for me to get through those times. Because one of the things I really was concerned about with Mosaic Presence and actually starting it was the energy that I brought to it. I wanted everything to have a certain level of peace and calm. Just to create a great learning environment.
I wanted my students to be my number one. I wanted to serve my students. I didn't want to all of a sudden see them walk through the door, "OK, you're the rent." You know, I didn't want to look at them like that. I really wanted to look at them as, "Well, I'm really trying to expand your opportunities. I really want to be in community with you. That's how I want to see you, and that's how I want you to feel in this classroom." I wanted to talk all that extra pressure off of them and off of myself. That's why I maintain the full-time job.
How To Re-evaluate The Direction And Purpose Of Your Side Project Instead Of Giving Up On It
Poornima: Let's talk about the learnings, 'cause there is that moment where you can look back and you can say, "I learned something." How has that caused you to change course?
Joy Dixon: Really, the timeline is the main thing. The timeline and allowing it to just unfold. Instead as opposed to being super directed about, "I want this to happen, this way, at this time.” Now it's more of an unfolding as I go through Mosaic presence. The amazing parts about this is all these opportunities are coming to me.
Poornima: Yeah.
Joy Dixon: I'm not out there actively seeking. I'm allowing things to just happen and transpire.
Poornima: Sure.
Joy Dixon: It definitely is challenging. It is really challenging. Like I said, I'm Type A.
Poornima: Yeah. I was just gonna say, as a, I shouldn't say recovering, as a present Type A, I think part of the challenge is, and also having been a software engineer, when you see something done and it's shipped, that's when you get this great sense of like, "I accomplished something." But when stuff isn't, then it causes you to, "Oh my God. I gotta do all these other things now to make this thing happen because this deadline has been pushed." There's this level of unease. When you said, learning to sit with it, I think that's the challenge. Learning to let go, that's the challenge. When it doesn't happen, we don't have that nice to-do list checked off. We don't have that thing to show, so we don't have that sense of accomplishment.
Joy Dixon: Yes. That was really it. It's about redefining success. Really. 'Cause is it the journey? Or is it the destination?
Poornima: Yeah.
Joy Dixon: I know people say it all the time, but it really is like, "Oh, with each step. Each step I have a success." Celebrate each and every single step towards your goal. 'Cause otherwise it's gonna be a painful journey. It really is. That has really been the thing that has helped me a lot. It is a big walk of faith.
Poornima: There are obviously times where you felt like you were banging your head against the wall. It wasn't working. You needed to change the timeline. You've kind of kept at it because you've been doing this now for two and a half years. Somewhere in that period of time, there must have come a moment where you felt like, "OK, what I'm doing, it's making an impact. It's actually bringing me joy." Right?
Joy Dixon: Yes.
Poornima: How did that feel for you? When was that?
Joy Dixon: That felt great. That felt really great. Really it was just encountering...It was actually when I started reaching out to former students for testimonials and to see that, "Oh, they're a director of this part. They're a senior software engineer over here." The words that they sent back about the impact that I had on their lives was like, "Oh my goodness." That was an amazing thing. That reminded me that this is why I do what I do. There is no better feeling in the world than being able to support somebody and assist them on their journey in moving forward.
Poornima: How do you continue to keep growing your presence?
Joy Dixon: Yeah. Ba-dump-bump. Actually even meeting young people. Young people are really great and they're super inspiring. People who are like me, who are like, let me transition and acquire some new skills and really kind of show them that, "Hey, I do this. You can do this." And when they see that and they get that light in their eye, then that makes all the difference in the world to me.
Poornima: Any final recommendations you have for our audience when it comes to growing their side project?
Joy Dixon: Yeah. Keep at it. I really do mean that. Keep at it. Every single step counts. Do what you need to do to take care of yourself. That is of the utmost importance. Your self care is number one. Always do something on your project every single day, even if it's some small thing. But just something every single day, that way you'll feel like, "Oh, you're nurturing yourself. You're being and you're nurturing yourself like your project and your baby.” That would be my recommendation.
Poornima: Those are wonderful words to end on. Thank you so much.
Joy Dixon: Awesome. Hey, thank you, this has been so great.
Poornima: For people that want more, how should they get in touch with you?
Joy Dixon: They can reach me at mosaicpresence.com and feel free to send me an email at joy@mosaicpresence.com. I'd love to hear from you.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
In last week’s episode of Build, we began exploring the theme of pursuing a side project while keeping your day job. Jox Dixon and I did some myth busting around the need to go all-in. If you missed the episode you can check it out here.
This week we’ve got a pretty meaty episode for you. We’re going to dive deeper into this theme, and talk about what to do when the inevitable happens: you can’t physically work on your side project.
We thought it was particularly important to tackle this topic because it’s happened to both Joy and myself more than once, and it’s probably already happened to you or you’re thinking about how to handle it when it does.
The common culprits that hold you back from physically working on your side project are burnout and stress. Each is often prompted by teammates at your day job needing you more, you feeling the need to do everything yourself, and not having enough help on your side project or feeling like you can’t ask for help!
People often think it’s the quality of the idea that determines the success or failure of a side project. But really it depends on how you respond each of these issues as they arise. Of course, it can be tempting to just give up and move on, because hey it’s a side project! But if you’re really passionate about your side project, it can be hard to let go, and you’ll want to continue to make progress.
So in today’s episode, you’ll learn the following:
Transcript
Poornima: In today's segment, we're going to talk about how to manage your time and energy around a side project. I know there's been a lot of talk around time management and energy management, so I'm going to dive right into some of the tougher topics.
Welcome back to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Each episode of *Build* consists of conversations I have with innovators in tech. Together we debunk myths and misconceptions related to building products, companies, and advancing your career in tech.
Why It’s OK To Take Periodic Breaks From Your Side Project
We're continuing our conversation with Joy Dixon, who is a visionary and entrepreneur with 20 years’ of industry experience. In addition to having a day job as a software engineer, she runs a technical training school called Mosaic Presence. I know for myself, Joy, I have recently gone through a tough month, where I had a lot of health issues, and I just couldn't physically be there to nurture all of my side projects. Let's start by talking about how do you keep these projects humming along when you maybe physically can't?
Joy Dixon: Yes, that is a great question. That is a really great question, because that actually happened to me a couple of times last year, major health issues. It was really an opportunity to take a break.
Poornima: Good.
Joy Dixon: I took it as an opportunity to take a break, so I slowed down a little bit. It gave me enough space to refocus and to prioritize. That was something. Instead of trying to do everything, let's actually set up that list where this is number one, this is number two, and if we get those two things done, that's good. We don't need the full 30 done today.
Poornima: Nice.
Joy Dixon: That was really it.
Why It’s Important To Say NO To Things To Avoid Burning Out
Poornima: I remember in last segment, you mentioned that lovely word, which we started this year talking about, that N word. Let's hear it. Saying “no” to things. Right?
Joy Dixon: Yes, yes.
Poornima: What's your magic way of saying “no” to things?
Joy Dixon: I do it graciously. Really. I have said “no” to more things in the past two years, and not just like, "Hey, let's go hang out," but no to weddings. No to graduations. No to major birthday milestone parties. Really just having to make a decision and having to...most people have been receptive, because it's you're like, "Oh, I'm doing X, Y, Z. I'm working on Mosaic Presence. It's really important to me. Can we get together at a different date?"
Poornima: Right.
Joy Dixon: Most people have been more than receptive for that and really super supportive. I think just the practice. It's about practicing and getting comfortable with putting yourself and your dreams and your desires first.
How To Ask Others For Help
Poornima: In addition to saying “no,” I also have to get comfortable asking for stuff. How have you gone about getting help from other people?
Joy Dixon: My network has been really super great. I have really just reached out to them, because I'm very clear about what I know, which means I'm super clear about what I don't know.
Poornima: Yeah, yeah.
Joy Dixon: With that, I just reach out to people. Most people I have found...people have been so super helpful and want to help. Maybe not on the timeline that I have, but they are—
Poornima: That's important.
Joy Dixon: That is very important.
Poornima: I think you should say it one more time. Yeah.
Joy Dixon: Yes, people are very receptive. Maybe not on working on my timeline, but they do come around, and they do help. So just really learning to accept the help when it's available has been really, really good for me.
Poornima: I'm sorry. I had you repeat that, because I think a lot of times, when we get so passionate about our idea, and we want to put in the effort, we think everyone else is like, "Yeah. I can do this, too. I can quit whatever I was doing," but they need a little bit more lead time, because they also have commitments that they want to keep up. We just have to be respectful about that.
Joy Dixon: Really, having my own passion and my own project, really, I have more understanding for people when they have theirs. I'm like, "Oh, OK. We'll do it in two weeks, then."
Poornima: There you go. Now, here's the thing. I think a lot of people...because you mentioned before being type A. We get really averse to asking for help, though...
Joy Dixon: Yes.
Poornima: ...because it's our baby. We just have to figure out a way to get over the hump. How have you gotten over the hump of asking for help?
Joy Dixon: Yeah. That one's a really great question. I love that question, because I still do that. I'm still in process and learning how to do that. Back to knowing what I know and knowing what I don't know and really everything is an opportunity for me to learn. The teaching, writing code, I know all of that. The accounting? Oh, no. I don't know that. It's really just allowing myself to learn. Another thing along with that is being super clear about what I'm doing. When I'm super clear, then it's easier for me to find people and for people to find me who also want to support my project.
Poornima: Yeah.
Joy Dixon: Yes.
Why It’s OK If You Don’t Have Knowledge Or Experience In Some Areas And Can Delegate That Work To Those Who Do
Poornima: You said a couple of things here that were interesting. The first is knowing what you know and knowing what you don't know. That's good. That's the first level. Then the second level you said is getting the help for the things that you don't know. One question I get asked a lot is, "Oh, should I just dive in and learn that accounting?" Especially people in our audience. They might think, "Well, I don't know coding. Should I do that as an entrepreneur instead of hiring somebody?" What's been your response, or how do you handle that? "This is a way for me to learn. Maybe I just want to hire somebody and get it over with?"
Joy Dixon: Yeah. That's really good. Disclaimer. Type A. I actually spend time in each of the areas that I don't know, at least so I can have a conversation, a more intelligent conversation with the people. I can also vet people.
Poornima: Bingo.
Joy Dixon: I don't have to know it all. I'm not looking for a master’s degree in accounting.
Poornima: Sure.
Joy Dixon: At the same time, what I am looking for is a certain sense of, "Oh." When I have a conversation with somebody, I know the questions to pose, and then when they give me a response, I'm like, ‘Oh, that sounds good.’”
Poornima: Yeah.
Joy Dixon: Yes.
Poornima: I like to call that the BS detector.
Joy Dixon: There we go.
Poornima: Yes.
Joy Dixon: There we go.
Poornima: You know just enough to be a little dangerous, but at the end of the day, you don't want to do the work.
Joy Dixon: No.
Poornima: Yeah. You want to get somebody else who has deeper subject matter expertise in it.
Joy Dixon: Exactly.
Poornima: Wonderful.
Joy Dixon: That's great. I like that.
How Find People Who Are Interested And Motivated To Work On Your Side Project
Poornima: Yeah. Of course, there are times where we hire people, and they, for whatever reason, let us down, either because they didn't meet our standards or just things happen. That can cause us to become dispassionate, because you think, "Oh, maybe my idea isn't that great. That's why other people don't want to work on it." How do you stay motivated through those moments where some people just let you down or drop the ball or don't execute quite to the same level?
Joy Dixon: You're the great questioner. OK? Really, that one is back to self. Everything comes back to self for me and self-awareness. Am I super excited and I'm super jazzed? It's really my thing. I really can't hold anybody or put them on a hook to have the same passion about my thing as I do.
Poornima: OK. That's important. Yeah. I think that's a good takeaway.
Joy Dixon: That's really important first and foremost. It's really about just getting super clear about what I'm doing. I call it the lighthouse effect, like shine my message even brighter. For those people who are really attracted to it, it will make them easier to find me. Those people who are kind of like on the fence, then they'll stay away. Then we really won't have too many of these interactions.
How To Set Boundaries With Your Teammates At Your Day Job When They Want More Of Your Time
Poornima: No, that's good. Yeah. I think another issue I've seen that arises a lot is people want more of your time. Let's say at your day job or your side project, and you've got to figure out how to set those boundaries. How have you done that?
Joy Dixon: Yeah, that one is a really challenging one. Really. Like I said before, if you have social events, you have family events, those are really challenging.
Poornima: But even within your existing day job or your existing side where they want more of your time.
Joy Dixon: Yeah. Really, for what I've done with the boundaries is, “this is the boundary,” because I know any overflow will affect everything else. It will have a ripple effect. You might think, "Oh, I'm just going to spend these extra few hours doing this," but it will really have a ripple effect and take away from the other part. It's super important to get very clear and to just maintain those boundaries.
Poornima: What does that look like for you? Let's say somebody at your day job is like, "Hey, Joy. Really could use your help. Could you stay another hour or two to help me out with this thing?"
Joy Dixon: Balance of an hour or two?
Poornima: Yeah.
Joy Dixon: Sometimes it would be “yes,” and then sometimes it would be “no.” Honestly, it's truly contextual. If I have to teach a class, then the answer is “no.” If I'm available, then I can do it. It really is situation.
Poornima: In that moment.
Joy Dixon: In that moment, exactly.
Poornima: OK, got it. Then same thing for your side project. If someone says, "Hey, Joy. I really need you to help us do X, Y, and Z."
Joy Dixon: Yes.
Poornima: The same thing.
Joy Dixon: Yes, because I'm beholden to both, so I have to keep both at the forefront of my mind.
Why You Don’t Have To Respond To Every Improvement Request Immediately
Poornima: Now, there's also times where we want to do more. Maybe that project at work, we want to go that extra mile, or in the side project, it's like, "Ooh, wouldn't it be really cool if I could add this and that? That's going to take another couple of days. It's going to take maybe another hour of staying awake or setting up another meeting. Do I have the room? Does it make sense to do that or not?" How do you manage those...I like to call them requests?
Joy Dixon: Those requests. Are they from...
Poornima: From yourself.
Joy Dixon: Did I initiate them?
Poornima: Yes, yes.
Joy Dixon: OK.
Poornima: Yeah, you just feel so compelled. Maybe it's external, like a customer saying or a student saying, "Hey, it would be really great if you guys also provided Y."
Joy Dixon: Yes. That would definitely have to go on the lovely big corkboard that I keep in my bedroom full of great ideas. It would be in the parking lot, and then I will revisit it in time. There are so many things I want to do. There's so many things. Every time I teach a class, I'm like, "Oh. Take notes on the curriculum. I want to teach it this way next time. I'll say it this way next time." Then I just have to wait for next time. There are just certain times you can't make those changes each and every time. Having that break. Once again, I know I speak about space a lot, because space has really allowed me to decide. Is it something I really need to do, or it's just something in the moment that just felt like a good idea?
Poornima: Ah, that's good. What's your barometer for that?
Joy Dixon: Time.
Poornima: OK. Letting it sit.
Joy Dixon: Time and emotion. Really. There is a part that's like jazzed and this is great, and making it that part, I would move forward with that. If it's like fear or like, "Oh, I need to hurry up and get this to market," then anything that comes from that place is something that I really just sit with for an extended period of time, because if it's supposed to be done, then it will be done.
Poornima: Thanks so much, Joy. This has been really helpful.
Joy Dixon: My pleasure.
Poornima: Yeah. For all of you out there, if you've had a side project that you've been working on for a while, I'm sure you have your go-to for managing your time and energy. Joy and I would love to hear what it is. Please share it with us in the comments below this video.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
It’s a brand new month, and we’ve got a new theme we’ll be tackling on our show Build! We’re going to be talking about building, managing, and growing a side project you are passionate about while keeping your day job.
I’m sure you’re aware of all the benefits that come with a side project: you get the chance to explore and learn new skills. And if it’s 100% yours, you get full creative freedom.
However, you’ve probably heard that once your side project starts to grow you need to make a decision… You need to decide to go ALL-IN! You need to quit your day job and pursue that side project. Otherwise, you’re not really passionate about your idea, you’re not committed, and chances are you’ll appear less than focused!
But going all-in on a side project can be a real challenge for many of us that don’t have the means, really like our day jobs, and truly want to have something on the side.
Well, it turns out you don’t actually have to go all-in, and in today’s episode we’re going to tackle this myth. In future episodes we’ll talk about how to manage your time + energy when you physically can’t and what to do when your side project is facing a number of challenges.
To help us out I’ve invited Joy Dixon, who is a visionary and an entrepreneur with 20 years’ of industry experience. In addition to having a day job as a software engineer, Joy also runs a technical training school in Oakland, California called Mosaic Presence. So Joy is definitely someone who walks the talk!
In today’s episode you’ll learn:
Transcript
Poornima: I'm sure you've heard that it's a wonderful idea to have a side project. After all, a side project will help you learn a new skill or explore something. But once that side project starts to grow, then you've got to quit your day job and go all in. If you don't, you're just not that passionate about your idea, you're not committed, and you could appear less than focused.
Today we're going to tackle this myth, and in future segments we'll dive into how to manage your time and energy and grow your side project.
Welcome to *Build*, brought to you by Pivotal Tracker, I'm your host, Poornima Vijayashanker. Each episode of *Build* consists of conversations I have with innovators. Together we debunk myths and misconceptions that are relating to building products, companies, and your career in tact.
I've invited Joy Dixon, who is a visionary and an entrepreneur with 20 years’ of industry experience. In addition to having a day job as a software engineer, Joy also runs a technical training school called Mosaic Presence.
Thanks so much for joining us today, Joy.
Joy Dixon: Thank you for having me here, this is great.
Poornima: You and I met at a conference recently and I'd love to just get to know you a little bit more. Tell us how did you get introduced into tech?
Joy Dixon: Actually in the sixth grade. I actually had a teacher, who said, "Hey, let's do tech." She was doing computers, it was back in the day with dummy terminals. Learned Basic, line number 100, duh, duh, duh, line number 200 duh, duh, duh. That's actually how I started in tech.
Poornima: Wow, that's great that you got exposed to it so early and now it's brought you full circle where you're doing, you're teaching. Let's take it a step back, you have a day job right now. What's your day job?
Joy Dixon: I have a day job right now. My day job is writing code. I'm a senior software engineer and I write code by day and then I teach people to write code by night.
Poornima: That's awesome. Your side project is Mosaic Presence. Tell us a little bit about it.
Joy Dixon: Mosaic Presence is my thing. That is the one thing that I do. So there is, it is truly my bliss, it is a software development training school, we have a mobile focus and really it's about expanding opportunities and creating community. That is the main purpose of it all. We take brand new people, if you're a complete beginner, we'd love you there. Then we move on and we do mobile stuff, we teach people how to make SMS apps. As well as your standard apps, either iOS or Android, whatever one's your preferred flavor.
Poornima: Nice. What inspired you to start Mosaic Presence?
Joy Dixon: Actually I've been teaching for 10 years and I've taught at various companies professionally, as well as various universities, and I just really wanted to do my thing. I wanted to teach things in my way. And then also with, just when I went back to school to get my Master’s, I had to do that at night and on the weekends because I too had to keep my day job. I wanted to create a program that would allow people to also keep their day job as well acquire new skills.
Poornima: Nice. You've been doing this for how long now? Mosaic Presence.
Joy Dixon: Mosaic Presence? Two and half years. The first half year was a pilot program that I ran and that was really great, there were so many companies who allowed me to use their space. Then actually putting pen to paper and creating a business was in 2015.
When To Start A Side Project
Poornima: OK, great. How did you know you were ready to start this? I know a lot of people are like, "Oh I want to teach." Or, "I want to do this thing." Or, "I want, want, want." But it's hard to get over that hurdle and then start doing it. You mentioned you'd been teaching before, but when did you decide, “Now I want to make this into my side project and then a business?”
Joy Dixon: Into a business. This is actually really great. This is actually my second time at bat. 'Cause before I was just doing software consulting and I was building websites and doing consulting for people, and then that business went down because it did. I was working too much and not working on my business.
Actually that was really good because it gave me a foothold this time to make sure, if you're doing Mosaic Presence, you're going to make sure you spend the time doing Mosaic Presence as well as maintaining your day job.
Poornima: So you had a little bit of a, let's call it failure.
Joy Dixon: Totally.
Poornima: It taught you how to do things the second time around.
Joy Dixon: I call them learning opportunities.
What It’s Like To Hold Down A Full Time Job And Pursue A Side Project
Poornima: I like that. Then let's talk about managing the business while you're doing your day job. What's that like?
Joy Dixon: A lot. It is really a lot. It is about time slicing, honestly. I pretty much sleep between 12 and 5, those are my hours. Before I go to work, I work on Mosaic Presence and then I teach at night. It's really time management, time management is key, there are a lot of nos to invitations to go places and to socialize because the weekends are really meant for me to spend on my business.
Poornima: I want you to hold that thought 'cause we're going to talk about that in the next segment. I want to skip ahead, why even do this on the side and keep your day job? Why not just save up a bunch of money and then say, "Peace." And go and just focus on your side?
Joy Dixon: That is a definitely a way to go if that works for some people. For me, this couldn't wait. Mosaic Presence couldn't wait and I wanted to fund it and then just make it happen. I was like, let's just do this. And the way I can do this and keep it in my control is to keep my day job.
Why You Should Tell Your Employer About Your Side Project
Poornima: The other issue that I know that a lot of our audience is probably thinking about is, what about your employer? How do they feel about it?
Joy Dixon: I told them. That was really, really, really important and key. Because when you start to kind of do stuff in the dark then you really don't do it. I was very open and honest with them that this is the thing that I'm doing. I just felt better about that, just being transparent. This is my love. I'm working here and I'm going to do my best and I'm gonna work in excellence as always do but this right here is my love.
Poornima: What was their reaction to it? Was there any, "Well, we need you here?"
Joy Dixon: They basically were like, "Hey, if you can do your job."
Poornima: OK, good.
Joy Dixon: So that worked out really well. I really appreciated that.
Poornima: So finding that fit.
Joy Dixon: Yeah.
Poornima: Yeah, I talk to a lot of people who when they know that they need to financially or intellectually have that day job, they negotiate up front with that future employer or the current employer. But they don't leave them in the dark because it gets them into deep water.
Joy Dixon: It really does.
Poornima: Later on.
Joy Dixon: It really does. I would definitely agree with that and recommend that to anybody's who's doing both. It could be a little scary especially if you're already in your current job. And they're like, "Oh, why are you doing this all of a sudden? Are you planning to leave?" At the same time I think it's just better just to have it out there. And it just makes you feel better in general and you put forth your effort.
How To Share Your Side Project With Your Employer
Poornima: Do you have some techniques you can share with the audience for even how to start that conversation with a current employer?
Joy Dixon: I would really find somebody who you feel safe with. If it's not your manger. Even if it's not, just like, "Hey." Have the dialogue and then at that point in time you do need to move it up the chain. But I would check all the lovely documents that they have for you to check. To see if this is even OK.
Poornima: That's true.
Joy Dixon: Before you even have a conversation. 'Cause that's really the challenge is the conflict piece.
Poornima: I do know some places there are very, very strict where you're not even allowed to do things like, "Oh, I took $100 for tutoring this kid on a one-off basis."
Joy Dixon: No really?
Poornima: Yeah. You're just not allowed to take money. To your point, check the documents first.
Joy Dixon: Check the documents first because there's a lot of times when people will think it's something but what's actually written on paper, 'cause that's really going to be what happens.
How To Respond To People Who Think You Aren’t “Focused”
Poornima: Aside from your employer, you probably told other people that you're working on this and on the side in addition to your day job. They were probably less than supportive. How do you manage those reactions where they're like, "Oh Joy, that's not very focused." Or, "How are you going to manage all of this? Seems like a lot."
Joy Dixon: It's really interesting 'cause part of me and the people in my life know I'm type A so they're just like, of course you are. But there are those people definitely who aren't as familiar with me or don't know me as well who do have that response. Really I just take it in and I'm like, “OK.” When you find that thing and Mosaic Presence is my thing, it actually energizes me. It energizes me and sets my energy in a space that makes me more creative, more full of life, more joyful, no pun intended. That's what I respond with that. And when people see that passion and they feel that energy then they're usually are like, "OK, keep going."
Poornima: They get it. That's good, wonderful.
Well, thank you so much Joy for sharing.
Joy Dixon: It's my pleasure. Thank you.
Poornima: Now Joy and I want to know, are you worried about going all-in on an idea and would prefer to start something on the side? You've got some concerns? Share those concerns with us in the comments below this video and we'll be sure to take a look at them and respond shortly.
That's it for this segment, be sure to subscribe to our YouTube channel to receive the next segment where we'll talk about how to manage your time and your energy as it relates to your side project. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
What Is Tech Debt And How Do You Manage It
It’s crunch time! You’ve got eager customers who are waiting for you to ship product, your teammates are eager to complete the release and move on, and you don’t want to be the bottleneck. So what to do you? You rush through writing your code and put in a quick fix.
It’s good enough to pass tests and a quick code review.
Unfortunately, crunch time doesn’t come around once in a blue moon. It happens more often than we’d like. And sadly it gets heralded by sayings like: “Move fast!” “Break things!” And, “Ship code!”
As designers, product managers, and developers we are eager to share what we’ve built with customers. However, constantly operating by the seat of our pants comes at a price and that price is tech debt.
Whether you have or haven’t heard of tech debt, I’m pretty sure you’ve experienced its effects. If you’ve been on product teams that seems to constantly be putting out fires, you’ve probably noticed that over time all those quick fixes add up. And when it comes time to build something brand new, what would normally take a few hours or days, suddenly takes weeks or months.
The reason it takes so long is because there’s a lot of cruft built up in the code base. Continuing to layer on quick fixes will only destabilize the code and impact its quality.
If you’ve struggled to deal with tech debt on your product team, or want to educate new teammates on how to manage it, then today’s Build Tip is for you!
I’m joined by Jay Hum who is a Product Manager and Pivotal, and together we’re going to be sharing:
Be sure to share the episode with your teammates to help them understand the importance of tech debt!
Want more resources on tech debt? Here's a link to the post Jay mentioned in the episode: Introduction to the Technical Debt Concept https://www.agilealliance.org/introduction-to-the-technical-debt-concept/
Transcript
Poornima: When your product has a nasty bug that's impacting a lot of users, your first priority is to put a fix in that's going to help resolve it. You might hear your developers say something like...
Developer: Yeah, I'll just put in a quick fix.
Poornima: A week may go by, maybe possibly a month, and you've got another nasty bug on your hand. Your developer might tell you...
Developer: No problem, I'll have that bug resolved by the end of the day.
Poornima: Later on, you might ask them to put in a new feature, and they may respond with...
Developer: Yeah, it's going to take a while.
Poornima: How long?
Developer: Weeks, possibly months.
Poornima: “Weeks, possibly months!?” Why so long?
Developer: Tech debt.
What is tech debt
Poornima: Wondering what's tech debt, how to avoid it, and prevent it before it gets too unwieldy? I'm going to answer these questions and many more, in today's quick *Build* tip.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Today, I've got a *Build* tip for you. I'm joined by Jay Hum, who is a product manager at Pivotal. Jay, tell me what's tech debt?
Jay Hum: Tech debt is the effort that builds up when a team makes a conscience decision to implement code that's easy, instead of building out a best solution.
Poornima: OK, so what does that actually...
Jay Hum: The easy-to-implement, quick, messy code, is the debt. Like any type of debt, it accrues interest over time, and so the additional effort that is built up that could either be time, money, or resources, is the technical debt that builds up that makes it much more difficult in the long run to implement a better solution.
How to avoid tech debt
Jay Hum: Here is the interesting thing. Tech debt is usually thought of as a bad thing, something that needs to be paid down very quickly, or avoided as much as possible, or all together. However, tech debt is actually unavoidable. Much like financial debt, there is not necessarily good technical debt, but there is technical debt that you can deal with.
An example is, in the mortgage or student loan, where the principle plus the interest that you accrue could be lower than what you actually yield in terms of the investment. Any experienced or seasoned developer are always wanting to create the best possible solution that there is out there. However, sometimes you need to incur technical debt in order to get a product out to market quicker. Generally, the time to market, or the time pressure, is what makes technical debt unavoidable.
How to manage tech debt
Poornima: OK, it's unavoidable. How can we manage it, while continuing to meet customer needs and pushing features out?
Jay Hum: Here's the thing about technical debt that makes this sort of the analogy to financial debt a little dissimilar. You don't actually have to pay down technical debt. For instance, when you're building out a product or service, there could be parts of the code that aren't used very often, or are not touched, that don't need to be changed. The RY on actually paying down that debt, or refactoring doesn't get you much, or doesn't get you anything there.
One of the other ways to really look at it and approach it is build in technical debt into the product role map, or how you plan out your releases. When you think about it, you should be thinking about it in terms of what's the upside potential versus the downside risk of either paying down technical debt, or not paying down technical debt, and relate that, to again, getting a product or service out to the market quicker, or spending more time and writing more cleaner quality code.
Poornima: All right, that's great that we don't have to always have to pay down tech debt, and that it's OK to accumulate it, but how do we know when to make the trade off of paying it down, versus just letting it exist?
Jay Hum: Right, so one of the things that you want to look at, is what is the probability of the occurrence of something bad happening, or the probability of the occurrence of you having to do a major refactor because the technical debt has just gotten so big. Coupled with that, you also want to look at what is the impact.
Again, there is smaller technical debt, where the impact of paying it down is not very big. Again, there's other parts where the technical debt can be very big, could lead to a big regression, and what is the impact on the delay to the market, or the impact to the customers that are actually using your product that's in the market right now.
When you don’t need to pay down tech debt
Poornima: Do you have a example of a situation where you don't need to pay down the tech debt, versus one where you do?
Jay Hum: Sure, yeah. I think a really good example would be if you take a look at an app through your analytics, and you're looking at one of the features that you've implemented is not being used very often. This is a good example of, you probably don't want to pay down technical debt on that feature, because again, it's not a lot of people that are using it.
Versus the flip side, so if you see that there is a feature that's being used very heavily by your users, and that they're clamoring for a feature that is sort of an add on to that feature, this is an instance where you would want to pay down technical debt quickly, so that you can build out that new feature that is an add on to the existing feature.
Is it ever too late to pay down tech debt?
Poornima: What happens if you leave tech debt around for too long? Is there ever a point where it's too late to pay it down?
Jay Hum: There are instances where it is too late. Usually what that manifests itself is that you have to do a big rewrite, which not a lot of people enjoy doing, both from a customer perspective, as well as the development team. If you go back to what I said earlier, if you realize that tech debt is unavoidable, and you build it into your product strategy, and your product roadmap, then there's ways of being able to manage that tech debt at a good pace, so that you never have to end up with having to do a big rewrite.
Poornima: Thanks, Jay. This has been really helpful. Do you have any other resources for our audiences to check out?
Jay Hum: Yes, they should check out this article written by the Agile Alliance. It is called “Introduction to Technical Debt Concept,” and it goes much more deeper into some of the concepts that I discussed here around technical debt.
Poornima: Now, Jay and I want to know, how do you guys handle tech debt at your company. 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 great episodes of *Build*, and *Build* tips like today's. Special thanks to our sponsor Pivotal Tracker, for their help in producing today's episode. Ciao for now.
--
Build is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
All this month, Karen Catlin and I have been digging into the theme of mentoring. We started out by sharing the debut Build episode on why some people are reluctant to seek mentoring, and last week we talked about how to approach mentors, set expectations, and thank them.
In today’s final episode, on mentoring for this month, we’re going to talk about what you can do to become an effective mentor yourself.
We understand that you might be reluctant to be a mentor for a number of reasons: you don’t have the time, you don’t feel qualified, or you feel like your experiences may not relate.
Don’t worry Karen and me have you covered! You’ll learn:
Transcript
Poornima: In the previous two segments, I've been talking to Karen Catlin, who is an advocate for Women in Tech, a leadership coach, and my co-author of our book, *Present! A Techie's Guide to Public Speaking*. Karen and I have been digging into the importance of mentorship. We started out by talking about why you might be reluctant to seeking a mentor. Then, we talked about how you can effectively establish the relationship. If you've missed either of those segments, I highly recommend you check out the links below this video. In this final segment, we're gonna talk about how you can become an effective mentor yourself.
Welcome back to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Each *Build* episode consists of a series of conversations I have with innovators. Together, we debunk myths and misconceptions related to building products, companies, and your career. Now, I know at the beginning, Karen, you mentioned how you loved mentoring, because you get to learn a lot. I feel the same way. I think I actually learn more than maybe my mentees do and that's why I love doing it. Let's talk about some of the benefits that you're gonna experience should you choose to mentor.
Mentoring is a two-way street that benefits both the mentor and mentee
Karen Catlin: Sure, yes. It's definitely a two-way street. You may not know what you're gonna be learning from a mentee, but getting together, hearing about what's going on, the questions they ask, you are going to get insight into how you can benefit your career. You might just get a good, broad perspective of what's going on around your company or your industry. As I mentioned, maybe some great ideas for podcasts that I could listen to, or books I could read, or productivity apps I could use. I don't even know what's it gonna be, but I always pick up something when I talk to a mentee.
Poornima: Yeah. I feel like it's a great way to stay relevant. Especially if some of us are a little bit older and maybe we're not as in the know.
Karen Catlin: OK. OK. So one time I was talking to someone and they said, "TLDR." This was a few years ago to my credit, but I'm like, "TLDR, what's that mean?" So, I asked and they said, "Oh, just too long, didn't read." I'm like, "Oh, OK." Just now, I am able to just like, weave that into conversations and all of a sudden I seem really relevant.
Poornima: Totally. So you can speak the lingo.
Karen Catlin: Exactly.
Why a mentor doesn’t need to have the exact same experience or perspective as their mentee
Poornima: Now, when you were at Adobe, did you just mentor women or do you also mentor men as well?
Karen Catlin: Sure. As a senior woman at the company, I definitely was approached by a lot of woman for mentoring. Men approached me, too. I did definitely mentor both genders. I think it's important for a mentee to get advice from people who don't look like them, whether that is because of your gender, or your life experience, your...of other things that you're bringing to the company, bringing to the table. It's important for a mentee to get advice from people who aren't like them, because it's gonna broaden the set of advice that they're going to get, right?
Poornima: Sure.
Karen Catlin: Likewise, because mentoring is a two-way street, it's good for mentors to mentor people who don't look like them too, because, that is going to allow them to learn, get different perspectives, and all of that. I think everything is ups for grabs.
Poornima: Yeah.
Karen Catlin: Yeah.
Poornima: What about people who may worry that they don't have the same experience, or perspective, and so, they might not feel credible sharing their life experience with a mentee?
Karen Catlin: Oh my gosh. Don't overthink it. That's my advice for mentors here. The mentee has approached you because they respect you and they want to learn from you. You don't have to worry about, am I going to be able to provide just the right piece of experience or advice. Don't worry about it, just have a conversation, share stories, share your experience, it's gonna make a difference to the mentee.
What to do when you don’t have time to mentor someone
Poornima: I wanna talk about a couple of other issues that I see come up a lot when I recommend people mentor and they're resistant to. The first is time. “I'm just so busy, I have kids, I have a family, I have other obligations, I just don't have the time to be somebody's mentor.”
Karen Catlin: Yeah. Yeah. I get that. Because, we are all very busy. That said, if someone
approaches you because they wanna get your advice, and they haven't time-boxed it following my advice from an earlier segment here. Ask them, what are you really asking for here? Can we get together and maybe, you know, if you're busy, you might say, "Can we get together for a 30-minute phone call?" for example. Ask yourself, "Do I have time maybe for a 30-minute phone call?"
Chances are, you have some small segment of time that you could offer to a mentee and so, you can be responsible for saying, "Well, this is what I can give you and this is all I've got right now." If you're really too busy, you might just say, "The next two months I am just super busy on this project, can you ping me in three months’ time, and I'll bet I'll have some time for you then."
Poornima: Yeah. I think that's good. I think it's good to give people that kinda realistic picture. One thing I like to do—actually, two things I like to do—if somebody comes to me and I know they have that good directive question, like, I got this one recently, "How do you self-publish?" Well, I've already written two posts, like, pretty meaty ones. I tell them, "Read these posts and then, if you have any other questions, shoot me an email, I'm traveling a lot, I'll be sure to respond to you via email."
Trying to find a 30-minute time spot across time zones, is just not gonna work for both of us. I think that's great. The other thing I say is, and you do this because you speak at a lot of events, I say, "I'm gonna be at this event, why don't we just meet there and when I'm in between sessions, would be great to come out and have a chat with you." I think finding those opportunities, you can get more flexible.
Karen Catlin: Yeah and,doing what you can to just help the person, whether that is with your actual mentoring or making a recommendation for another mentor.
Poornima: Yeah. That's a good one.
Karen Catlin: I had times, yeah, over my career, where really my mentoring dance card was just full. I really, really couldn't take on anymore mentees. When those things happen and someone approached me for mentoring, I would explain, my mentoring dance card is full. What are you really looking for from a mentor? And then I might recommend that they reach out to someone else at my company. Right?
Poornima: Yep.
Karen Catlin: Help them, move them forward in some way.
Poornima: Definitely. I know another hurdle is relevancy. Again, kind of, oh, you know, the mentee might say, "I'm looking for somebody in data science." I might say, "I don't know anything about data science, I'm just a front-end engineer or I'm a designer, why are you approaching me?" Right? It doesn't seem like my work is exactly relevant. I don't know if this is a good thing.
Karen Catlin: Yeah. It's so funny. Just a couple days ago, a mentor, excuse me, a mentee was reaching out to me and asking, "Hey Karen, I am thinking about putting on a women's only hackathon and I'd like to get your advice about how to do this." I had to tell her, "Well actually, I have very little experience with hackathons, even though I'm an advocate for Women in Tech. I think this is a great idea, but I don't have direct relevant experience to share with you. However, I do know about this one tech company who has run a women's only hackathon." I mention the name of the company, she said, "Oh, I know people who work there, I'll reach out to my network there to find out little bit more.” Again, this notion that I pushed her forward, I helped her out without really being able to answer her direct question, whether that was on data science or a hackathon.
Poornima: Yeah.
Karen Catlin: This notion, I’ve done with so many mentees, this notion of encouraging them to think about their network. Who else could they tap to get that specific experience or advice they're looking for?
Poornima: Yeah. Part of your mentorship is also helping them see what they already got, see the resources that they have at their disposal.
Karen Catlin: Exactly.
Poornima: It's not all about you having to do the work.
Karen Catlin: Exactly.
Who need to hold a mentee accountable
Poornima: Yeah. That's great. What about accountability? A lot of times people say, "How can I hold my mentee accountable? Make sure they're hitting milestones. Make sure that they are successful?"
Karen Catlin: Yeah. Gosh. Maybe I should be doing a better job at this. I really feel that as a mentor, my job is not to take any action items from the meeting, you know, it's to provide my experience, my advice, my thoughts. But, really, I'm expecting the mentee to be taking notes, to be figuring out what they're gonna do next, and to be making progress. I don't take any of that on me, but maybe I should be, I don't know how to help them. We all benefit from having accountability partners. It's just that, as a mentor, I'm already giving a lot of my time, I don't feel I need to be doing that as well.
Poornima: OK. Maybe that's something more a sponsor would do or even a coach, if you hire them?
Karen Catlin: Yeah. A coach would definitely do that for you. Otherwise, maybe it is a buddy, or a friend, or a colleague that you might reach out to, in addition to having the mentor, you have an accountability partner, who helps make sure you're making the progress you want to make.
What to do as a mentor when someone brings you a deeply personal problem
Poornima: I've had this happen a number of times, where somebody that I mentored, I see very quickly that it is not just about getting that promotion, or improving a particular thing about their career, there's some other stuff going on. It might be a personal issue, and so, how would you recommend answering that as the mentor?
Karen Catlin: Yeah. Mentors and coaches, frankly, we're not therapists. We're not trained in helping people through some deep personal issues. I remember a situation where someone had some things going on with, I think it was a teenage child, and, even though I'm a mom of teenagers, I still felt that this was something that I did not feel qualified or really feel right about providing guidance. Happy to share what I've done as a parent in different situations, but that's not getting to the point of providing therapy, so I've really had to sort of redirect the conversation and stay away from it, frankly.
Poornima: Yeah. Set some clear boundaries and make sure that they understand that.
Karen Catlin: I'm not a therapist.
What are male allies and how to become one
Poornima: Yeah. That's fair. I wanna go back to one of the earlier things that we had talked
about around coaching people that may not look like you and I know as an advocate for Women Tech, one of things that you do is coach men to become better allies for women. Start by telling me, what exactly is a male ally?
Karen Catlin: Yeah. So, an ally is anyone who is in the majority and really has a point of privilege as a result. Maybe a little bit of power that other people don't have, because they're not in the majority. In tech, it's typically white men who have the position of power, they're the majority. So, it's an important thing for them to realize that they have this role to fill as an ally for women or anyone who's underrepresented in tech.
They have a role to play to help those people be successful, to feel that they can be...that they're welcome somewhere, that they can be included, that they can grow their career and have an impact there. A male ally, that's what I look to them to do, is to make their environments, their teams, their company culture, more welcoming and inclusive to people who don't look like them.
Poornima: How do you help men to become male allies?
Karen Catlin: Yes. I believe there are everyday, simple actions that men can take to make their environments more welcoming and inclusive. For example, and this is something that I think that pretty much every woman who's professional, or maybe working—every woman working in tech, I'll go as far as to say that, has had this experience, where they have been talking in a meeting and some man with deeper vocal chords and a louder voice, just interrupts them and sort of steers the conversation in a different direction.
There's a phrase for it, “manterrupting.” We've heard that before. What can a male ally do when they witness that behavior when they're sitting across the table and seeing it going on? They can say something with their deep, strong vocal chords, "Hey, I was actually interested to hear what Anna had to say, let's bring the conversation back to her." That's an example of an everyday action a man can take to be an ally for women in that meeting.
Poornima: Yes.
Karen Catlin: Another example, might be this whole idea-hijacking, I like to call it. Again, I think so many of us have had the experience where we have said something brilliant, awesome, in a meeting, and it kinda fell on deaf ears at the time, and then maybe a couple minutes later in the meeting, someone else says the same brilliant thing—often it's a man, only because there's gonna be so many men in these meetings.
What's a male ally to do in that situation when they notice an idea has been hijacked by someone else? They can say something simple, like, "Yeah, I really like that idea, and when Jen said it a few minutes ago, she phrased it this way. I like the way you've built on it," or something like that. Another every day action a man can take to help the women and underrepresented minorities be successful.
Poornima: It's great that you are coaching men to have these everyday actions that are important and impactful. You have any others that you would like to share?
Karen Catlin: Oh, sure. Here's another space, I'll call it—forget about meetings, let's move on from meetings. We all need to have networks to be successful, to hear about opportunities, to hire from, right? When we're trying to fill roles at our company or to find jobs if we're looking for jobs. If we let our networks grow naturally and organically, chances are, we're gonna have networks of people who are just like us. “Just like me” networks. We enjoy the same hobbies, we went to the same school, we enjoy doing and talking about the same things, right? That's just human nature to reach out to people we enjoy spending time with, that's our network.
I think we have a role to play, especially if we're a male ally, but we should really be looking to diversify our network, so that our networks aren't just like us and that they're filled with people who are of different backgrounds, different experiences, just went to different schools, worked at different companies and so forth. For men, specifically, I challenge them, if they go to some networking event, or a Friday afternoon beer bash or something, go introduce yourself to someone who doesn't look like you. You can define that however you want, but someone who doesn't look like you.
Poornima: Maybe shorter than you.
Karen Catlin: Maybe shorter, yes. Darker skin, gender, whatever it is. Say hello, get to know them a little bit and see if there isn't something that you can either learn from them or that you can do for them as a result. Just getting to know them a little bit. That challenge, I think, is important and I try to embrace it, too. When I go to a networking event, I tend to like to look for the women that I wanna meet and reach out to them. It's easier for me to have those conversations. It's a little bit more intimidating for me to go up to a young man in a hoodie and introduce myself and start a conversation. I try to do that myself, because I think it's important for me to diversify my network. It's good advice for not just male allies, but probably for all of us.
Poornima: Yep. Well, thank you so much Karen. This has been a lot of fun and I'm sure the audience is gonna get a lot out of this. Why don't you let us know how we can get in touch with you.
Karen Catlin: Sure. You can get in touch with me on my website, there's a contact page and that is karencatlin.com. If you want more everyday actions you can take to support diversity, inclusion, create a welcoming environment at your company, check out the Twitter handle @betterallies.
Poornima: Wonderful. Thank you. We'll be sure to share the links below the video. That's it for our episode on mentorship. Be sure to subscribe to our YouTube channel to receive the next episode. If you've enjoyed this segment, then please be sure to share it with your friends and your colleagues. And finally, a special thanks to our sponsor, Pivotal Tracker. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
Have you already tried mentoring and found that it’s not working for you?
Is it because you’re just not getting what you want out of it, or other people have convinced you it’s just not worth your time?
We get that something may go wrong, which is why in today’s episode we’re going to cover ALL the things that can go wrong with mentoring. But we won’t leave you hanging… Karen Catlin (https://karencatlin.com/) and I will provide concrete tips (including some exact script to use) for:
- Why you might consider finding a mentor inside versus outside your current company
- How you can go about setting clear expectations with your mentor
- How mentoring and coaching are different
- How to decide if it makes sense to pay for coaching
- Why it’s important to thank your mentor and how to do it effectively
In the next video, we’ll conclude our theme of mentoring by sharing how you can get started as a mentor!
Transcript
Poornima: In the last segment, we talked about the importance of mentorship and why some people may be reluctant to seeking out a mentor. If you've missed the segment, I've included a link to it below this video, so don't miss it and be sure to check it out. In today's segment, we're going to focus the conversation around how you can get the most out of mentoring. Welcome back to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. Each *Build* episode consists of a series of conversations I have with innovators in tech, and together we debunk a number of myths around building products, companies, and your career in technology, because I know there's a lot of people out there who may not be aware that they are doing things that are actively acting against them from having a good mentoring relationship.
Karen Catlin: Sure.
What not to talk about during mentoring
Poornima: Let's start by talking about what you should not expect to get out of that relationship.
Karen Catlin: In a word, gossip. I used to have a mentee who would come to my office for our monthly meetings, and would sit down and just say, "So, tell me what you're hearing about. What's going around the company?" Oh my gosh, like I wasn't just going to share all of the, you know, news I had heard to this person, you know?
Poornima: Right.
Karen Catlin: He was just looking for gossip and it basically turned into this mentoring relationship that I hated. I really did not look forward to those meetings because like he was probing me for intelligence. It wasn't cool.
Poornima: Yeah, yeah. It wasn't the purpose of the meeting.
When mentoring goes wrong
Karen Catlin: No. Can I tell you something else I've hated about mentoring? I had another mentee who we were working together, I think, for over a six-month period, once a month we had a meeting, and when we got together each time I would say to her, "So last time, you know, we talked about this. Did my advice help you?" Her response was various forms of, "Oh, you know, I've been too busy" or, "I didn't really think it was going to work so I didn't even try it out," but she was there to get more advice from me. Like, what was that all about, right? I was not fulfilled. I did not think my advice was helping her, and again, I hated those relationships.
Poornima: Yeah, so it didn't sound like it was something that would keep you engaged as the person who was doing the mentoring.
Karen Catlin: No, exactly.
Poornima: Anything else that people want to be doing?
Karen Catlin: I'm so glad you asked.
Poornima: Yeah.
Karen Catlin: The other pet peeve I have around this—and I bet most people in our audience here would be incredibly respectful of anyone's time that they were asking for mentorship—but I definitely have had people that have overstepped the bounds of that. You know, a meeting has been scheduled maybe for an hour and I can't get them to leave the office. It's like the hour is up and they keep talking, and they want me to keep providing advice. I'm just trying to get them out the door because I've got other things to do, so we really need to be respectful of the time and our time commitments there.
How to set expectations for your mentoring relationship
Poornima: OK, so now that we've talked about a number of things not to do, let's switch gears and talk about how to set expectations.
Karen Catlin: Sure. A mentee should really be looking to the mentor for advice, but really in the context of, "Have you ever experienced this situation before?" Or, "Tell me about a time you might have had to do something like this." For example, let's say that you wanted to approach a mentor because you had to learn about a certain market vertical, right? The worst question is to go to that mentor and say, "Tell me everything I need to know about this market vertical." It puts so much burden on the mentor to be like this educator in everything.
Poornima: We don't know where to start.
Karen Catlin: Any way, and we don't even know where to start. It's too big a question. Much better would be to approach the mentor and say, "Hey, I need to come up to speed on this market vertical. Can you tell me how you came up to speed and learned everything you know?"
Poornima: Nice.
Karen Catlin: Something like that. They then can share their experiences and start talking about how they have come up to speed on the market.
Poornima: Yeah. It's a lot more relatable and they have those experiences. They're not kind of fishing for things that may or may not be applicable. It's kind of your job as the mentee to figure out which piece of their experience relates back to you. Any other examples that you have?
Karen Catlin: Sure. I remember mentoring someone who came to me because she wanted to explore a lateral job move and she actually asked a really good question. She didn't come saying, "Hey, I have this opportunity to do this lateral job move. Do you think I should do it?" No. She didn't say that. Instead she said, "Hey, I'm thinking about this lateral job move. Have you ever taken a lateral job move and how did you make the decision to do it?" Then we were able to have a great conversation about it.
When does it make sense to pay for coaching?
Poornima: It's natural to start and have maybe a coffee conversation. There are a lot of mentors, though, who are also coaches that expect to be paid, so how do you know when it's time to hire somebody?
Karen Catlin: Mentors and coaches are similar and yet different as well. A mentor's job is to provide their experience, share their advice, those types of things. A coach probably has more of a discipline around helping a client in a certain way, whether that is a job transition that they're exploring and trying to put frameworks around that, or strengthening leadership skills, which is what I focus on, and every coach is different. I think a very simple way to think about this is, a coach will be—it's a business, and so there is a charge for that, and a mentor is a free thing.
One thing I'll say though is every coach has a different style depending on their experiences and their approaches to things, and I am a blend. Chances are I've walked a mile in my client's shoes because I've had such a long history in tech already and all my clients are in tech, so I do provide some mentoring in terms of my coachees might ask me something, my clients will ask me something, and if I have relevant experience, I'll share that story because I think it might help them, but then I'll also be putting more of a framework around helping them achieve their goals overtime and that's why it will end up...you know, there's a payment involved, there's a cost involved.
Poornima: Yeah. You're trying to get somebody to a milestone.
Karen Catlin: Exactly.
Poornima: You're trying to help them improve, and because there's a lot of structure around it, you then want to get paid for that versus like just general kind of coffee conversations.
Karen Catlin: Right. Exactly, exactly.
Poornima: For people who are evaluating when it makes sense to hire somebody, how would you recommend that they think about it?
Karen Catlin: Yes. I would recommend it in terms of, first of all, if you don't have a good mentoring situation or mentoring program at your company or in a community of some sort, then that's a time to explore coaching. I would also say that if you have a situation where you're trying to grow some skills and you're very much, "Here are my goals and here's what I want to get to," and you feel that it would be something you want to do not out in public, like you don't want anyone at your company to know you're working on these skills, again, you want to do it on your own and sort of on the side, you might want to hire a coach. It also might be that you want some professional help in terms of, yeah, you respect a lot of people that you work with, but are they the right people to help you get to this point that you're trying to get to in your career? It might be time to get an external perspective and some professional help.
Poornima: Yeah. I've also found that just having the accountability of meeting with somebody weekly, thinking of it as an investment, is really helpful.
Karen Catlin: Yes.
Poornima: Versus like, "Oh, can we grab coffee 30 minutes here, 30 minutes there?" A lot of times it's valuable, but you miss some of the context, and like you said, some of the framework that people you're paying for have done this over and over again.
How mentoring differs from coaching
Karen Catlin: Yeah. Here's an analogy. Let's say you think about your workouts, just to keep yourself healthy and so forth. You may have a workout buddy or a friend. You're going to go work out, go climbing, go for a walk, whatever. That's great, but if you really are serious about changing things up, you might hire a trainer at your gym to really get things moving in the right direction and get some professional help. That's similar to how you might approach coaching and mentoring. A mentor would be someone like, "Let's go for that walk together. Let's go climbing together." We're going to talk as we go, but it's going to be a little more casual. Then if you really want to get serious, you're going to hire the equivalent of the trainer at the gym. You're going to hire a coach for your career.
How to thank your mentor
Poornima: Last question for you in this segment. How about thanking your mentors, expressing your gratitude so that they know that their time was well spent, and they keep kind of looking out for you and want to work with you?
Karen Catlin: Yeah. Mentors, even if it looks like we are professional and successful, we still enjoy being treated to a cup of coffee or a lunch. You know, it's a nice touch, and of course flowers, wine, gadgets, Teslas. I don't know. Just have some fun there.
Poornima: Yeah. It'd be a toy Tesla.
Karen Catlin: A toy Tesla. There you go, but seriously, gifts are always nice, but I'll tell you the most meaningful thank yous I've gotten from my mentees have been when they have come and thanked me and told me, "This is how your advice has helped me." I remember I mentored someone when I was back at Adobe just over lunch one day. It was just a one-time, casual mentoring kind of thing. A year later, she reached out to me and said, "Hey, Karen. I want to thank you for that lunch we had a year ago. You told me these things and this is what I did, and I just got the promotion I was trying to go for." I remember I went to lunch, but I didn't remember everything I told her. I shared some advice, shared some stories, whatever.
For her to come back and say, "This helped me" was so important to me because that meant that I spent my time well, she really was paying attention and in sort of a circle kind of thing, it also helps me become a better mentor because now I know, "Oh, that story or that advice really resonated for her. I'll remember to use that again if someone is in a similar situation." So thank somebody by really telling them, "This is what you've shared with me. This is what you told me. This is what I did. Here's how it helped." That's the best thank you any mentor could ask for.
Poornima: No, that sounds great. Well, thank you for sharing that with all of us.
Karen Catlin: Sure. My pleasure.
Poornima: Karen and I want to know, are there expectations that you're looking to set with your potential mentor and you're wondering how to frame them? Let us know what they are in the comments below and we'll be sure to respond to them shortly. That's it for this segment. Subscribe to our YouTube channel to receive the next and final segment on mentoring where Karen and I will be talking about how you can become an effective mentor. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
Welcome to Build brought to you by Pivotal Tracker! I’m your host, Poornima Vijayashanker.
Each Build episode consists of a series of conversations I have with innovators. Together we debunk myths and misconceptions related to building products, companies, and your career in tech.
One misconception I fell prey to early on in my career was staying heads down and waiting for someone to acknowledge my accomplishments.
The thought of tooting my own horn seemed too self-promotional. I was worried about what my teammates and boss would think.
It wasn’t until I came across people who helped me find my voice and style that I realized the disservice I had been doing to my career.
Through their guidance and support, I realized how beneficial mentors can be to your career.
While there’s been a lot of talk already about the need for mentors, in today’s segment we’re going to take a slightly different angle and explore:
In future segments, we’ll tackle how to effectively get a mentor, and how you can get started as a mentor!
To help us out I’ve invited Karen Catlin who is an Advocate for Women in Tech, a leadership coach, and my co-author on our book: Present! A Techie’s Guide to Public Speaking.
Transcript
Poornima: One misconception I fell prey to early on in my career was staying heads down and not talking about my accomplishments. I felt like it was too self-promotional to toot my own horn, and I worried about what my colleagues and my boss will think. It wasn't until I came across people who helped me find my voice, and told me that it was OK to share the work that I was doing, that I became more comfortable. And it was through their guidance that I realized how valuable that mentorship can be to catapulting your career.
While there's been a lot of talk already around mentorship, we're gonna dive a little bit deeper. In this segment, we'll dive into why you might be resistant to getting a mentor, and in future segments we'll talk about how to effectively approach a mentor, and if you wanna be a mentor, how to go about getting started.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, I'm going to be talking to innovators in tech, and together we're gonna be debunking myths and misconceptions related to building products, companies, and your career in tech. And to help us out, I've invited Karen Catlin, who is an advocate for women in tech, a leadership coach, and my co-author on our book, *Present! A Techie's Guide to Public Speaking*. Thanks so much for joining me, Karen.
Karen Catlin: Oh my gosh, it's my pleasure, Poornima, thanks for having me.
Poornima: Yeah. This is such an exciting episode for me, 'cause you and I have been working closely for a number of years. Now, for our audience out there, I wanna go back a little bit to your days as a VP at Adobe, and walk us through what you were working on there.
Karen Catlin: Sure, sure. So I joined Adobe through the acquisition of Macromedia, so I actually worked at those two companies for 17 years, so a big bulk of my career. And while I was the Vice President there, I ran the shared engineering services, which included things like product security, product globalization, our open source, our engineering productivity tools, accessibility work. All sorts of things that we hire deep experts in those areas, and then worked across the product teams to help them with their product releases.
Poornima: In addition to your role as VP at Adobe, you were also mentoring a lot of people. Walk us through why you decided to do this.
Karen Catlin: Sure. And I actually started mentoring people much earlier in my career. I remember at one point, at Macromedia, I was a program manager, and in fact I was the only program manager for the company at the time, and I worked on a very early version of Dreamweaver, which you may remember. And as other product teams started hiring program managers, I offered to help hire them and train them, and bring them up to speed. And because of that interaction, a lot of those program managers, by default, kind of started looking to me for ongoing mentorship about how to be successful in their role. So it started out really there. And then, certainly I just kept continuing to do that as I moved up with my career and into the VP level.
Poornima: That's great that you were doing a lot of corporate mentorship, but as I know it, you also had been mentoring outside of Adobe and other companies that you worked at. Talk to us about the kind of mentorship you did outside of the company.
Karen Catlin: Sure. So there are quite a few ways to get involved in, formal mentoring programs, I'll call it, and I do that through...for example, my alma mater, where I mentor a senior, an undergraduate, who's about to start her career, and I provide mentoring during her senior year, which is great. And I get matched with someone, and it's a nice way for me to give back to the university, as well as to learn about what a senior is going through right now in her life, and trying to figure out and navigate the career options and so forth.
I also do more informal mentoring, which I like to call micro mentoring, and I do that through The Women's Club of Silicon Valley, where I've been a member of that for a number of years. I've been on their board, and I certainly love helping our members with anything that they might need some advice on, some help on. And I call it more informal because we're not matched, people just reach out to me if they have advice that they want to seek, they wanna get my experience that I've had on something. And they'll just reach out and say, "Can we get a cup of coffee, get together for lunch," something like that. So it's much more informal and kind of organic that way.
Why is it good to have a mentor
Poornima: So let's dive into kind of the bigger theme here, right? 'Cause I know a lot of people say that mentoring is important, but why is it even important? Like, why do we need to do this, why can't we just read books, or ask our boss, or ask our colleagues for help when we need it?
Karen Catlin: Yeah. So first of all, I think that I enjoy mentoring because I wanna pay it forward. I want to share my experience, and help other people who might be going through similar challenges, or similar choices that they need to make, to learn from my experience. And I hate reinventing the wheel, so if I can help other people not have to reinvent the wheel themselves, if they're going through the same type of situation that I'm going through, I'd love to—or, have gone through, excuse me—I would love to share my experience with them.
And this whole notion of paying it forward is one reason I mentor, but it's really a two-way street. Every time I mentor someone, I learn something from them, too—it's just not me providing my advice, I learn from them. I might learn about, you know, good new books or podcasts I should be listening to. I might learn about new productivity tools that are just, you know, a new app to do something that I had never heard off. When I was a VP I also might hear about certain challenges that people are facing, that actually helped me be a better leader, because I got intel and insight into what was going on around the organization that I might not otherwise hear about.
When is mentoring appropriate
Poornima: Yup. And for the mentee side, what are the benefits for them?
Karen Catlin: Oh, sure. So the mentees, they get to have a sounding board. For example, if they are trying to decide something, get some advice, they get to hear someone else's perspective on that. They get to hear stories about a time that that mentor maybe went through something similar, and then they can learn from that. And they just might be able to take a step back from that day to day, I'm working, I'm getting stuff done, let me step back and think about what I should be doing with my career, these choices ahead of me, how I should think about a problem differently, or a situation differently. So, so many benefits to a mentee.
What is a mentor versus a sponsor
Poornima: I've also heard of this word, sponsor, and I'm sure some of our audience has as well, so walk us through what's the difference between a mentor versus a sponsor.
Karen Catlin: Sure. So they're very different, although they may sometimes be the same person. But let me break it down. A mentor is someone that you might meet with to get their advice, and they should share their stories, their life experiences, their perspective on things, so that you get that insight into what they, you know, how they think about things. By contrast, a sponsor is someone who is influential at your company, or in your industry segment, and they are going to be in situations, meetings, different situations where they will find out about opportunities that they might think of you as a good person to fill. So they will open doors for you that you might not even know exist, right? So that's what a sponsor does, they know you well enough to recommend you for opportunities, and to support you that way.
Poornima: Yeah, a little bit more directed, then.
Karen Catlin: Yes, exactly. But you might not even know you have a sponsor. They might just be doing this behind the scenes, and opportunities are coming your way and you're not even sure why they happen. So sometimes you don't even know you have a sponsor.
Why people are resistant to mentoring
Poornima: Nice. Now, not everyone wants a mentor, why do you think people are resistant to seeking one?
Karen Catlin: Yeah, so in my current role as an advocate for women who are working the tech industry, I have talked to hundreds of women about mentoring and the importance of mentors, and the two things I hear from many women—there's a theme. The first is, "Ooh, it's so awkward to go up to someone, or send a note, and say 'Hey, would you be my mentor?'" You know, that's awkward and a little intimidating, so they don't wanna do it for that reason. And then the second reason is that they think they're imposing on someone. Everyone's so busy in tech, right? Super busy, and so why would some important person wanna take any time out to help me, right? It's an imposition, and I don't wanna go there.
Poornima: Yeah. And what would you recommend to kind of getting over those hurdles, if that's what's holding you back?
Mentoring what to expect
Karen Catlin: Right, right. So I like to break it down with my coaching clients, as I encourage them to find mentors in their companies, I like to break it down in terms of, be very specific about your ask. For example, let's say your goal is to file your first patent. That's a really clear goal, and there are...then you can look at, who do I respect around the organization who's filed a patent, and send a simple note saying, "Hey, I'd love to file a patent and I would like to have lunch with you to find out about your experience with patent filing." You know, just really simple, concise, direct, this is what I would like to do.
Sometimes it might be a longer term mentorship, so another example of an ask might be, "I'm very interested in growing my career to the director level. Would you mind meeting with me for three months, once a month, for half an hour or something. I'll bring the questions, you bring the advice." Right? Just be very specific about what you need. You don't even have to say mentoring, like, that feels awkward. Just say, this is my ask, can you help me?
And you'll notice with both of those, whether it's a one-off or a longer term thing, I time boxed it, right? And I think this notion of time boxing is really critical when you reach out to a mentor. If I were to say to you, "Hey Poornima, would you mentor me?" You'd be like, "What's that mean?" Like, what does that even entail? What are they asking me to do? But if I can say, "Would you meet with me for half an hour, once a month for three months," you know exactly what you're getting into, and it's a whole lot easier for you to say "Yes," or maybe, "Not right now, I'm too busy," if that's the case, right?
How mentoring relationships evolve
Poornima: Yeah. Or, let's do a couple meetings first, and then if it works out, there's chemistry, you like what I'm saying, then maybe we'll do a full three months, but let's not get—
Karen Catlin: Exactly. And by the way, at the end of that time box period, let's say that is a three-month, or a six-month engagement, if things are gelling and you still wanna be learning from that mentor, and the mentor wants to continue meeting with the mentee, you can continue it. You can renew it for another period of time, another six months, three months, whatever that is. Yeah.
Poornima: Thank you so much Karen, I think that's a great place to get started with mentoring. And for all of you out there, if there was a hurdle that Karen and I didn't cover in today's segment, let us know what that is in the comments below, and we'll be sure to answer it shortly.
That's it for this segment. Subscribe to our YouTube channel to get the next segment, where we'll continue the conversation, and talk about how to get the most out of your mentorship. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
--
Build is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
There’s been a lot of debate and controversy around the lack of women and minorities being represented in tech companies from entry-level to the C-suite and board room.
However, what isn’t showcased is how there is sisterhood within tech, where women are helping each other out, and enacting change at every level from schools to the board room.
To talk about how women are investing and encouraging each other, I’ve invited Samantha Walravens who is the co-author of the new book Geek Girl Rising: Inside the Sisterhood Shaking Up Tech.
If you’re a woman, minority, or male ally you’ll learn from Samantha how:
This is the last episode of FemgineerTV but don’t worry it’s not the end...
After hosting FemgineerTV and listening to audience members like you for the past 2 ½ years, myself and my sponsor Pivotal Tracker decided it was time for a fun format!
Starting next month, I’m going to be launching a new show called Build. I think you’ll enjoy the new format for Build. Each week you’ll receive a short video on a topic to help you build a product, company, and career in tech. So stay tuned for the launch of Build :)
Want to help us get the word out about Build?
Please take a moment to leave a review on iTunes here.
If you’ve never left a review, here is a quick tutorial on how to do.
--
Poornima: Welcome to another episode of *Femgineer TV*, brought to you by Pivotal Tracker, I'm your host, Poornima Vijayashanker, the founder of Femgineer.
In this show, I invite innovators in tech, and together we debunk myths and misconceptions related to building tech products and companies.
One of the most heated topics today is the lack of women and minorities represented in tech; from entry level, to the C suite, to the board room. While we all know this is already a problem, in today's episode, we're going to be talking about some of the solutions, and showing how there are companies and organizations enacting these solutions.
And to help us out, I've invited Samantha Walravens, who is the coauthor of the latest book, *Geek Girl Rising: Inside The Sisterhood Shaking Up Tech*. Thanks so much for joining us today, Samantha.
Samantha: Thanks for having me!
Poornima: Yeah, it's wonderful.
Let's start by talking about why you and your coauthor, Heather Cabot, decided to write this book.
Sharing The Unspoken Narrative of Women In Technology
Samantha: The inspiration for this book was a conversation I had about three years ago with a friend of mine, who's been in Silicon Valley for 20 years. She's a woman, she's the VP of sales in business development, and she's worked in a number of tech startups, and we were having coffee, and she said, "Sam, I cannot tell you what just happened in my performance group review, it was last week, and my manager commented on what I was wearing, the color of my dresses, the jewelry I wore, and he told me that I was too aggressive, and too bossy, and I needed to tone it down a bit." Meanwhile, she is the head of sales, and she was rocking her number out of the park. So she said, "Sam, you've got to write something." She knew I was a journalist. She said, "You've got to write something and you have to talk about this kind of discrimination and this kind of sexism in Silicon Valley."
Mind you this is before the *Newsweek* article came out, "What does Silicon Valley really think of women," people were discussing women in technology, but it really was not a top of mind—and so I started to do a little digging, and researching and interviewing women. And what I found was, yes, there's sexism, there is harassment, there's discrimination, there's unconscious bias, it's there, it's a problem we need to talk about it and deal with it.
But there was another narrative, another discussion that wasn't being told, which was: these women want to talk about the companies they were building, the technologies they were creating, the women who are supporting them and helping them along the way in their careers. There was this whole other narrative that was missing from the conversation that was happening in the national news media about sexism in Silicon Valley.
And I thought, "we have to discuss this." So, Heather Cabot, who's my coauthor, was in New York, I'm in San Francisco, we talked, and she said, "Sam, I've been researching this topic," it was kind of a coincidence, it was like one of those weird moments of weird fate. And she said, "I've been researching this topic, let's work together." So we put our heads together and we just started digging into the topic, and it's been three years now, and finally the book is coming out!
The Sisterhood That Is Supporting Women In Tech in Silicon Valley And Beyond
Poornima: So one thing I experienced early on in my career, and it keeps me motivated, is the women who inspired me. So, early on, when I was a college student in engineering school, I had a professor, and she had twins, and she was doing her research, and she was teaching, and she was leading the department, and I thought, "If she could do it, I could do it." And as I was reading the book, I noticed the theme of the sisterhood kind of coming up again and again.
Tell us how you discovered this theme as you started writing or as you were doing your research.
Samantha: Of course. Well, I too had a mentor back in my Silicon Valley days when I worked for a software startup during the dotcom boom in 1998 to about 2003, so I saw the dotcom boom and the bust happen, I was living through it, our company went public, stock went to 130, then went down to two, so I lived and breathed the dotcom boom and bust.
My manager/boss at that point was Carol Carpenter, who has since gone on to become—she was the CEO, actually CMO of ClearSlide and then CEO of ElasticBox, so she's a prominent woman in Silicon Valley, and she really pulled me up. She really, when I was lacking confidence, and I thought, "I can't do this," I'd just had my baby, my first baby, we were going public, and I thought, "I can't do this, this is crazy." We're working 24/7 and I have a newborn at home. She was the one who said, "Sam, you can do it, you can do it." And having that kind of mentorship and that kind of woman who was going through it herself pulling me up, really encouraged me.
So as we were researching the book, we started noticing these pockets around the startup universe, women who were supporting each other, investing in each other, encouraging each other in their careers and inspiring the next generation of girls and young women to pursue technology and continue their careers in technology.
Encouraging The Next Generation of Women To Consider Careers In Tech
Poornima: Yeah, that's great. I think you're absolutely right, that is a narrative that's missing from the media and more women need to know that that's out there as well, so that they don't feel like all there is is just what the media portrays.
Now, the first place that you write about change happening is at the primary school up to the high school level, so walk us through what that looks like.
Samantha: Well, fortunately, before Obama left office, he did create an initiative, a $4 billion initiative called "Computer Science for All" that is encouraging and putting funds towards creating computer science curriculum in schools throughout the country. I was so excited to read about Rahm Emanuel in Chicago, in the Chicago public schools now, computer science is a requirement for all high schools in Chicago. So I think we're going to see more of that.
When you look at the numbers, though, we still have a long way to go, cause 25% of high schools in the U.S. offer computer science, I think it's like 22% of girls, of students taking the computer science AP exam are girls, so we still have a long way to go.
What we noticed, though, it's sort of this grassroots movement of women who are encouraging the younger generations to start building, to start creating, to start coding. For example, we start our book talking about Debbie Sterling, who's the founder and the CEO of Goldie Blocks, and she's got this great—I have two little girls, we have it at home, it's a great toy that encourages girls to build, and there's a really fun, positive role model, Goldie, who builds a spinning machine and she has all these sorts of engineering—you wouldn't even know it's engineering, it's really just building Ferris wheels and building merry-go-rounds and all these fun things, along with the story, talking about Goldie and her friends, and how she's building these different fun games and amusement park rides. We have that in our household.
These are the kinds of things that women are doing to try to inspire the next generation. There is a woman in our book who started a company called Bitcode, she's actually working with the public schools to get them to use video to teach girls how to code. So if you have kids you know that they're on video, they're on YouTube, and they're really tech savvy. I have four kids, they can get around YouTube, and iMovie, and they're all over it. So, this tool is used in the public schools, to teach coding, using videos, to make it fun.
How Colleges Are Changing The Ratio Of Women Graduating With Computer Science Degrees
Poornima: It's great, yeah, it's good to see these grassroots efforts, so that even if there is kind of a gap in terms of change for public schools or the school system in general, there's ways in which parents and teachers can supplement that.
So, the next place in which a lot of women and minorities drop off is at the college level, tell us who's working on changing that.
Samantha: Well, we had the most amazing experience at Grace Hopper in 2015. I believe you were there, and Heather and I, my coauthor and I went, and just to see, I think it was 12,000 women there in computing, and it is a true celebration. And to see the enthusiasm and the excitement and the bonding between these young women, it was so encouraging.
When you look at specific colleges, there's a lot being done to encourage more women in to pursue technology and computer science. I met with Maria Klawe, who's the president of Harvey Mudd, and wow! What a firecracker she is, she skateboards around campus, she's just a really fun, wonderful woman, and she implemented a program along with her colleagues a few years ago, where there are two tracks for computer science, so as a freshman you can take the gold track or the black track.
The gold track is for students who have not had any computer science experience in high school; the black track is for students who've had some experience. So, by doing this, the students who have not had experience don't feel so impostered, they don't have the confidence cause no one's had this experience, so they get through this year and I spoke to a couple of students who have taken these classes, and they say that by the end of the year, everyone's pretty much at the same level.
So, she, Maria Klawe, and her team has tripled the number of women graduating with computer science degrees at Harvey Mudd in the past ten years, and the number is, I hate to throw in all these numbers, cause they get little mind boggling at times, but 55% of the computer science graduates at Harvey Mudd are now women.
Poornima: That's great, it's a nice change to—the numbers go up.
Samantha: There's also Stanford. Another example of what's going on to encourage women to pursue computer science is Stanford University, of course a top institution, but they have a Women in Tech group called She++, which was started by Ayna Agarwal, and who was not even a computer science major by the way, but she started this group to encourage women and they had a Gala, every year, which gathers all the women in technology, not just Stanford. What they do is they go out into the communities and they take on high school students in different communities around the country and they support these young high school girls to start programs in their communities. For example, I live out in Marin County, and there is a girl who started a robotics happy schooler box program in Marin City, which is an underserved community in Marin County, and she runs this afterschool program in Marin City.
So all of these girls around the country who are starting these programs through She++ gather together for this gala, and I am telling you, if you could be there to see these college women, these high school girls who came, they were dressed to the nines, they were glamorous, I mean, talk about debunking the myths and breaking stereotypes about what a woman in tech looks like, I mean, we could have been in an LA nightclub, not to sound like—but they were so beautiful and wonderful and smart and excited to talk about their programs, and they were so excited to be in technology. And again, this is why Heather and I said, "This is a story that no one sees," you don't see this kind of enthusiasm around technology, you see, "Oh, it's so hard, numbers are dropping, it's all doom and gloom." And so we really wanted to tell that other story.
The Angel Investors And Others Who Are Supporting Female Founders
Poornima: OK. That brings us back to industry, and I know there's a lot going on at the corporate level, as well as startups. I'm of course partial to startups, so let's start there and talk about how the ecosystem is changing for women and minorities.
Samantha: There's a lot of momentum behind supporting female founders. For example, there are accelerator programs like the Women Startup Lab, which is down here at Menlo Park; there's MergeLane, which is in Colorado; there's The Refinery in Connecticut. These programs focus on female founders, and really giving them the tools, the skills they need to grow their company into a venture, fundable company. And they give the tools to learn how to pitch venture capitalists, and we all know the venture capital world is very male dominated.
Poornima: Yeah, it is a challenge. I know I've had my fair share of doing the fundraising.
So, there's a very common problem around women and minorities getting up and pitching their business to VCs, either male VCs not getting their idea, or they don't think it's a big enough market, or there's a lot of unconscious bias around it, so how are women getting their training to get over all of that?
Samantha: Well, you've started a company, so you know what it's like. The founders that we've met, that I've met in my journey with this book, are so passionate about their idea. But you can have an idea, and it's not going to go anywhere—you have to have the product market fit, you have to test the idea, you have to build your team out—and so these programs are really teaching women what they need to do to get to that level, to actually pitch to investors. But when you look at the numbers, I think it's 10% of the venture funding, globally, goes to female founders—it's still a really small percentage.
We've also noticed that there's women who are angels. So angel investors who fund companies at the early stages—for example, Joanne Wilson, aka Gotham Gal, who has a tremendous momentum in New York City, who has invested in a number of really great companies; Caren Maio, Nestio, Shanna Tellerman, Modsy—she finds these women, who have ideas that are big, that are scalable, and she nurtures them, and she's like the fairy godmother to these women. And there are other women that we talk about, we'd had to read the book to learn about all of them, but there are women who really take these female founders under their wing and support them on their journey.
Poornima: I think it's great that there are women like Joanne Wilson out there. Do you have a sense of how many companies she's invested in?
Samantha: Joanne Wilson has invested in around a hundred companies, and they're doing fantastic. One of them, Shanna Tellerman, started the company Modsy, which is an immersive, 3D environment for home décor, home design, and she told us that she created this project called “The Pinnacle Project,” at Park City, Utah, and it was Wednesday through Sunday, I think. And she invited Joanne, and Susan Lyne, and a bunch of angel investors, as well as a number of female founders, to come gather, network, ski, and have fun, and she said it was funny, because all the women were thinking, "We should be home, we should be working, we should be with the kids, we have so much to do," and she said she had to tell and remind people that, "This is what the guys do. They have a boys call and they pick off and it's all about business, whereas women don't have that sense of, “Let's go out to ski, or golf,” and that kind of networking, so it was an example of this pinnacle project, which is going to happen recurring every year, of, "OK, women, we can get together, have fun together, network, introduce each other to investors and influencers, and have fun while we're doing it. It's OK."
Poornima: Yeah. That's fantastic. And I think another thing you had mentioned pipeline ventures, or pipeline angels?
Samantha: Pipeline angels, yes, yes. Natalia Oberti Noguera is a force of nature and she started this angel investing group for women and I went through it and Heather went through it. I did it in San Francisco, Heather did it in New York, and basically it's a training, it's a bootcamp or a training program for women who are credited investors, to learn how to invest in female and minority-led companies. So it walked us through the process of how do you set evaluation on a company, what do you look for in a startup that you're investing in, what kind of traits you want to look for in the team, what's going to make this a good investment. So it trains women to invest as angels, and then you actually make an investment at the end.
We made an investment in a great startup—which I believe is still hush hush, underground at this point—but I believe we made a great investment and we're following the course of these early stage female founders, and it's really her goal to change the face of angel investing, to increase the amount of money going towards these early stage female founders.
Poornima: As we were doing research for your book and when I was reading it, I noticed that there was some astonishing findings, like only 11 companies that were founded by African-American women have received funding over a million dollars. So walk us through who is working to change this.
Samantha: Well, that number has actually increased, it's now 13 companies that have received more than a million dollars, but the numbers are still really low. One woman who is really on top of this problem is Kathryn Finney, who is the founder of DigitalUndivided, which is an organization whose main purpose is to increase the number of women, minorities in the tech world, latino women, and black women founders, and she just recently launched an accelerator, in Atlanta, Georgia, called the Big Innovation Center, and I think their first cohort is gathering this year to help skill up and prepare these minority founders to raise money.
How Tech Companies Are Growing Up And Changing How The Nature of Work
Poornima: So let's switch gears, and talk about corporations. We previously had Lisen Stromberg on the show, talking about the changes that were happening for parents—what have you seen?
Samantha: Well, what we've noticed is that Silicon Valley is growing up. They are trading in their ping-pong tables and foosball tables for nursing rooms, which is inspiring to see. When I started out, I had my Medela Pump in Style in a cold bathroom out of the courtyard of our startup, so it wasn't pretty, but we spent a day at Eventbrite not too long ago, and Julia Hartz, who's now the CEO of Eventbrite, it's very focused on woman, developing women in leadership positions and allowing for work-life balance. And I say that word, “work-life balance,” a term that is loaded, what she's trying to do with that company is focus on the whole person, not just the employee self.
For example, they have a program called “Take the time you need.” So if you need time to care for a child or to care for an adult, you can work from home, you can take time off, so she's really interested in her employees, and telling her employees, "You can do what you need to do, so you can live a life and you can be an employee."
And she also tells the women who are having babies at her company, she says, "You know what? You can get through the first six to nine months," it gets a lot easier, because a lot of women when they have their babies early on, they think, “I can't leave this poor creature alone with a daycare with a babysitter,” and she says, “If you can just get through that”—she's got two little girls herself—”If you can just get through that time, stick with it, come back, and we will support you while you're doing it,” which is fantastic.
Poornima: You also showcase companies like Power to Fly. Walk us through what Power to Fly is.
Samantha: Yeah, Power to Fly was started by Milena Berry and Katharine Zaleski. Katharine actually wrote an article apologizing to all the mothers out there. Before she had children, she was a little bit judgemental of mothers taking time off and having to leave work early, and then she had her first baby and she thought, "Oh, my gosh, this is really hard," so she and Milena got together and started this company, Power to Fly, which connects women with remote and flexible job positions, so they can actually care for their family and pursue careers in technology. The great thing about technology is that it can be done remotely. Especially if you're in coding, you don't have to be in an office 24/7, so Power to Fly works on that.
Another great program is Tina Lee started a program called MotherCoders, and she's based in San Francisco, a fabulous woman, her program retrains mothers in tech skills, so they can go off and they can—either they've taken time off or they have background in some other field, they can skill up in technology, and go out and get the tremendous amount of jobs that are available in technology as they get back to work.
Disrupting The Boardroom
Poornima: Well, that brings us to the boardroom, so walk us through what changes are happening there.
Samantha: The number of women holding board seats in our country is still very, very low, I think the number is 18% of board seats at Fortune 500 companies are held by women. So we still have a long way to go.
One real pioneer in this area is a woman, her name is Sukhinder Singh Cassidy, she's fabulous, she is the CEO and founder of a company called Joyus, a tech company, and she, a few years ago penned an article called "Tech Women Choose Possibility." And she really wanted to profile the women in Silicon Valley, in the startup world, who are doing great things, just founding great companies. There was a lot of positive response to that article, and so she created an organization called #choosepossibility.
Part of that organization is a group called, or an initiative called "The Boardlist." And basically it's a matchmaking tool that matches qualified, board-ready women with startup, tech companies, looking to fill board seats with women, so she made that happen, and they placed three women on the board, which it seems like it's very low, but what they're doing is they're connecting the VCs and the startup companies with these women, and a lot more placements have been made not directly through the platform, but just through the connections that have been made on this platform.
Poornima: OK, great, so it's good to know that there is some change happening at the board level as well.
Well, thank you so much for joining us today, Samantha, I know our viewers out there are going to enjoy reading your book, *Geek Girl Rising*. And for our viewers who are women, minority, and allies, is there anything else you would like to share with them in terms of resources?
Samantha: Yeah. I would love to see everybody come to our website. We have a gazillion resources
on how you can join the digital revolution, just take a peek.
Poornima: Thanks for tuning in today and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode of *Femgineer TV*. If you've enjoyed this episode, then please be sure to share it with your friends, your teammates, your boss, and everyone so that they get to benefit from all the great resources, and subscribe to our channel to receive the next episode.
Ciao for now!
--
FemgineerTV is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
There are a lot of people who want to change their career later in life. They want to do more challenging work, earn more money, and have a better lifestyle. Given the growing need of technical talent in the US, it would see like a technical career would be a great choice, right?
Unfortunately despite the dearth of technical talent, many people are wary because of the misconception that transitioning into a technical career later in life is just too hard. Another is, as you start to fall behind on your technical skills, it’s hard to play catch up!
Hence, a lot of people struggle to stay relevant.
Piling on career pauses like parenthood make it even harder!
However, the growing number of retraining programs, bootcamps, and online education options are looking to cater to busy people who are eager to transition into a technical position.
In today’s episode we’ll talk to Tina Lee, who is actively is working to change these misconceptions with her nonprofit MotherCoders, which helps moms on-ramp to technical careers in the new economy.
You’ll learn from Tina:
Show Notes
Check out MotherCoders at http://www.mothercoders.org/
FemgineerTV is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).
Full Transcript
Poornima: Welcome to another episode of *Femgineer TV*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker, the founder of Femgineer. In this show, I host innovators in tech and together we debunk myths and misconceptions related to building tech products and companies. One common misconception I come across a lot is how challenging it can be to pursue a technical career midway through your career.
Another is that it's really hard once you've lost track of your technical skills, or they've gotten rusty, to get back on track. One woman, Tina Lee, is working to change this misconception. She is the founder of MotherCoders, a nonprofit, that helps moms on ramp to technical careers in the new economy. Thanks for joining us, Tina.
Tina Lee: Thanks for having me.
Poornima: Yeah. So, I know you and I met about a year ago at a conference, but I'm not too familiar with your background. Why don't you just tell us a little bit about how you got started.
Tina Lee: So, I started this journey towards having a technical career when I became a management consultant coming out of college. I helped implement large, enterprise-level IT systems and from there I kind of had this epiphany that tech was going to play a major role in business, and it was just a matter of time before the rest of the world was going to be transformed by it as well, and then after that I did technical recruiting. I spent some time in grad school studying education technology, and then ended up working on behalf of nonprofits and government and helping them use technology better to meet their goals.
Poornima: So that's great that you've had all this exposure to technology in your career. What ultimately inspired you to start MotherCoders?
Tina Lee: Well, like a lot of people who are inspired to make change, it came from a deep place of pain.
Poornima: Yeah, what was your pain?
Tina Lee: So, I had been trained to do simple things, build simple things: HTML, CSS, a little bit of JavaScript. I even tried learning Ruby for a while. And it was fine until I had my second child, right? The programs that are available to beginners usually happen on the evenings or on the weekend or online. And I felt like because I had just had a baby, my second one, I felt very isolated. So, doing it online felt very lonely and I couldn't make these in-person classes anymore, so out of that I had this vision of like, you know what? I cannot be the only mother, a new mother, who’s experiencing this. I should just organize kind of an informal meet up because my grandmother had met me.
I had envisioned maybe some grandmas here on the corner and then we'd be doing our thing here. And ultimately what happened was I had so many women that filled out this informal Google Poll that I had about their interest level that I said, "OK. There's enough there to do something more organized." So I ran a pilot out of a co-working space that was empty on Saturdays and just happened to be next to an onsite child care facility center.
Poornima: Wow.
Tina Lee: Yeah. So that we were able to run the classes in the conference rooms and then have the kids be cared for by professional caregivers in a setting that was set up for them.
Poornima: That's awesome. So you really saw the opportunity. One as like a personal pain point that you experienced but then after you do this experiment there were a number of women who were interested. And then from that point, how did you transition into making it the nonprofit that it is today?
Tina Lee: So, I'm all about failing fast and rocket prototyping. So that was kind of my way of experimenting with this model. And because so many women had reached out, ones who could not participate in the pilot for one reason or another, I knew that there were moms out there that were hungry. And once you dig deeper into the numbers it collaborates that, right? I know you had Lisen Stromberg on the show recently and you look at the numbers about how many millennia women are about to become mothers, right? A million a year for the next 10 years or so. And then you look at how millennia women are going to be the largest and the most educated demographic ever, right? And then you look at who’s already a mom now.
There's just tremendous opportunity to help moms who are either stuck on the sidelines and they want to get into tech but can't. Or they're in a job where they're not touching it and they want to move up. This is a great way to activate them and give them a skill set that will help them stay competitive. And we even have entrepreneurs who feel like they need a bigger tool set. They want like a wider understanding of how the ecosystem’s working so they can really launch their ventures. They come to us for that understanding and then also the community, too. That's a big part of what we do is the community because like I said being a mom is very isolating.
Poornima: Yeah that's fantastic. I'm sure some of our viewers out there who are entrepreneurs will be interested to learn a little bit more. So it’s great that there are going to be all these millennial women who are becoming mothers but I know there's still a problem when it comes to leadership, and as you and I have noticed, within tech itself only 26% of women hold computing jobs. So, how do you think MotherCoders is helping with that?
Tina Lee: Well, couple of things. One, we've kind of discussed this a lot which is a pipeline issue. Yes. We could be graduating more women with degrees in computer science or engineering but we also do a terrible job as a society of helping women thrive once they become mothers, right? No one ever says the term “working dad.” We just assume that—
Poornima: That's true.
Tina Lee: —you're going to be working.
Poornima: Yeah.
Tina Lee: But for mothers, I think as a society, culturally, we're still very ambivalent about how we feel about women working outside the home once they become mothers, but if you think about it, mothers are the people that you work with, right? They're the people sitting around you and they're your cohort next to you that's going to be taking over this role. It’s just the workplace is not set up to help women succeed, right? The IT worker is all in, all the time.
Poornima: Right.
Tina Lee: And if you have caregiving responsibilities, that's impossible, right? And women are kind of pressured to make a choice because there are not...there just aren't the social support systems, right? School lets out at 3.
Poornima: Yeah.
Tina Lee: There's no paid parental leave, right? And a lot of companies are just starting to experiment with flexible work hours, right? So all these things make it very difficult for women who feel like they want to prioritize their families and of course at the same time they're made to choose.
Poornima: Yep. I do remember in Lisen Stromberg's interview we talked about this caregiving bias. So it’s great that you touched upon it. I think you also mentioned in a talk earlier the mommy tax versus the fatherhood bonus. Walk us through why this disparity exists.
Tina Lee: Oh man, we're going to get sad. OK. So, because of this ideal worker model, right? You're expected to go in all the time. Once you become a mother, everyone knows what that means and what that looks like, right? Based on our certain circumstances. Our current set of circumstances. So, automatically men and women will think, "OK. So this person is either going to be downshifting their careers or they're going to drop out altogether." Right? "And if they do stay they're probably not going to go all in. So let’s put them on the mommy track." So, women aren't left with that many choices right? So the way I frame the mommy tax is that automatically you're considered less valuable.
Right? And that will represent...that will manifest itself in salary negotiations, in having projects that will help you reach the next level, in helping you maybe make connections or professional development that will bring you to the next level. So there's a tax not only in real terms in salary but also a tax in terms of the opportunity cost.
Poornima: Right.
Tina Lee: Of what you could have done if you didn't become a mother in the eyes of the employer. Now it’s such a powerful bias that women who aren't even mothers get hit by it right? I mean how many stories have we heard of women walking in to pitch their companies or trying to get a job and they say, “Are you going to be pregnant?” Or, “You're married, do you plan to have kids anytime soon?” Not only is that illegal.
Poornima: Yeah.
Tina Lee: That automatically kind of primes everyone in the room to think like, "Oh, right. You're a woman. There's a high chance that you'll become a mother and you're just going to peace out at some point and why should we invest in you." Right? So that's the motherhood penalty. On the flip side, the opposite is happening to men. "Oh! You're going to become a dad? This means you're going to be...you're going to be going in even harder because now you're responsible for caring for a family, right? You should be given the best projects because you really need to get to the next level. And you really should get a salary bump because now you're responsible for all these people."
Poornima: Yeah.
Tina Lee: So it’s just a very unfair situation where women are getting hit by this mommy tax and dads are not. And women are already a lot of times behind because of the gender pay gap that they came into before all this even happened.
Poornima: Right.
Tina Lee: Oh and for every child that you have, additional child, you get hit a little bit more.
Poornima: What can we do to sort of alleviate this? Or what...what can people do to sort of empower themselves?
Tina Lee: Well, I think we need to talk about it in several levels, right? One is the individual level. One may be at the company level. And then one at a society level. So I'm going to start personal. Personally, I think one of the strategies that I've employed is you really have to take stock of your own capacity.
Poornima: Mm-hmm.
Tina Lee: What are my goals? What are my passions? What do I want to do? What capacity do I have in terms of caregiving? Do I have family to help me out? Do I have friends? Do I live in a community where there's support systems? So all of these things have to be taken into consideration. And I specifically stayed in a neighborhood in San Francisco that has a high density of in-home child care providers, and preschools, and great elementary schools to kind of situate myself where I would have these resources available to me. Other people move in, their parents.
Poornima: Yeah.
Tina Lee: Other people move closer to their parents. Everyone has a different situation, right? And I'm lucky in that I have a great partner. So all of these things help me succeed. But on a company level, what would make it even better, as I mentioned earlier, some flexible schedules. If I have a role where I pretty much can do work without being physically in the office, I should be allowed to do that, right?
Poornima: Yep.
Tina Lee: And if I happen to work with other people who are caregiving, not just kids but for their parents, or they happen to do other things in the community, they should be given that right, too. So having this flexibility actually benefits everyone in the company.
Poornima: Yeah.
Tina Lee: Paid parental leave is huge, right? And also really thinking about how to combat that implicit bias against women and mothers, right? And that kind of speaks to the larger problem of the societal expectation that women are expected to provide caregiving and men are not, that women should stay home after they have kids, right?
Poornima: Yeah.
Tina Lee: And the reality is that our society's changing, women are more educated, they're working. Forty-five percent of families with kids under 18 now have two working parents working full time to stay afloat, right? And so the reality is that we need to change some policies around how we support parents in general, caregivers in general. And I'm really glad that people like Sheryl Sandberg through *Lean In*, Emily Slaughter through her books, and then Lisa, too, are really tackling this societal piece because we can't change. We're not going to see change until we have culture change and I think that's a long-term thing that needs to happen.
Poornima: So let’s bring it back to the struggle to stay relevant, right? You take a pause for parenthood, or you downshift, or maybe you don't even downshift, but there's this perception that you are downshifting. So I think it’s great that there are retraining programs like yours. How do you see these programs evolving overtime?
Tina Lee: I don't know.
Poornima: Yeah.
Tina Lee: That's the honest answer.
Poornima: OK.
Tina Lee: I don't know, because—
Poornima: But you see people embracing them?
Tina Lee: Yes, people are embracing them, but I think we're at the beginning stages of just having this consciousness that tech is moving really fast.
Poornima: Yeah.
Tina Lee: We live in this world where you have to continuously learn in order to stay relevant whether you're a caregiver or not, right?
Poornima: Right.
Tina Lee: That's why companies invest in professional development budgets and provide access to online training courses or learning plans. So I think we as a society know that people need to stay fresh on top of the skills and understand how fast things are changing in the industries, right? And that's why they invest in the professional development piece, but they also will have to come up with new ways of providing those to people who may not have the capacity to go to the one-week conference.
Poornima: Yeah.
Tina Lee: Or the “take three months off to learn how to become a full-stack web developer” type of programs, right? Those all-in programs are going to be very challenging for people with caregiving responsibilities and that's why you don't see an influx of caregivers in those types of boot camps or in online learning, right?
Poornima: Yeah.
Tina Lee: Because as I spent time in ED School, I know that learning is very social and I'm a big believer that context is important. It’s great if you learn how to speak French by yourself, at home, in front of a computer but if—
Poornima: No, I tried that. I have a terrible accent.
Tina Lee: But yeah it would be better if you had actually visited France.
Poornima: Right.
Tina Lee: If you understood French culture and maybe even had some French friends and had a French meal. So it brings it all together and that's kind of the experience that we aim for because it’s not just the skills. It has to happen in context.
Poornima: Yeah. So why teach these technical skills? Why not just get people to get better at management skills or some of the other softer skills? Why do you want to focus on tech skills?
Tina Lee: I think tech is transforming our economy. It’s just going to be one of those things that we take for granted, right? And having that literacy is going to empower you to think about your own industry differently. And it’s going to impact the way you approach a problem differently. And I think once moms gain that level of tech literacy, it just gives them a level of confidence to approach this new phase in their life differently because a world of opportunity will open up, right? I think before in the beginning, when things were still very technical to the point where you had to have a bachelor’s or a master’s degree to understand it, then it was less accessible.
But now we're at the point where we've automated a lot of these things and made it a little bit more friendly. And I think if you're really going to innovate, it's just as important to understand the problems in the industry and then figure out the technical piece that goes along with that. And I think there's enough room for everyone to participate in that exercise.
Poornima: So why don't we talk a little bit about the type of people you see coming to your program, other coders—are these people that are outside of tech? Or are they people within tech who maybe were on the business side and then wanted to transition into the technical side?
Tina Lee: So, after running five cohorts now, some patterns are emerging, right? We mainly see women who are working moms and they want to get technical but can't find a solution that works with them because of scheduling or child care issues. They know that their path to career advancement requires them to gain this new skill set, right? So they want access to it and we provide that for them. Another group of moms who come to us, like you mentioned earlier, they may have stepped out for a little bit. A year, six months, some even 10 years, right? And they're just looking for a refresh. To figure out a way to connect their passions to a path forward.
And then the last group, these are entrepreneurs who have an idea for an app or they are already on their way to building a company and they just realize, like, "Hey, I'm kind of stuck now and I can't proceed without a grander understanding of what it is I'm trying to do and how to go about it." And so they come to us. So those are kind of the three groups that we see. In terms of industry background, they just run across the gamut. We have moms who worked in a startup only on the operations side. So they wanted to get closer to moms who were scientists, who are working in a lab. And they're like you know what? I actually want to do something else because it enables me to be more creative. So just really all over the map in terms of industry background.
Poornima: And how do you go about doing the teaching?
Tina Lee: So, we have a three-pronged approach. As I mentioned before, it’s not just the technical skills.
Poornima: Sure.
Tina Lee: So, we teach a little bit of code. All the moms are taught HTML, CSS, and JavaScript to build a basic website and how to launch it, but the goal of that really is to give them a taste of it, to see how it feels to build something and put it out into the world, and to really check themselves. “Do I like this enough to keep going?”
Poornima: Yeah.
Tina Lee: Right? Or, “Is this enough? Or do I pivot?” The second piece that goes along with that is the community piece. So we bring in women from the field, like yourself, and we create this community not only of people who could mentor them, but people who provide access to job opportunities. And then of course they have each other.
Poornima: Yeah.
Tina Lee: Right? They can go to conferences together. They can just go to a café and help each other. And having that nerd mom comradery is really essential to success because, sometimes in the middle of the night and there's no one else there, you can feel like you can ping someone.
Poornima: Right.
Tina Lee: And then the last piece that we do, right, technical, community, and the last piece is the childcare piece, right? And that childcare piece really helps moms figure out in a safe space if this is something they want to go further. Right? And I would also argue that another piece of it is context. Although it’s hard to explain to people what I mean by that. What I mean by that is all of this is happening within context of what we see in everyday life and that piece of context is provided by the community, right? You come in and explain we use agile and that's what it means in our shop.
Poornima: Yeah.
Tina Lee: Or we believe in rapid prototyping and design thinking and that's how it works in our shop. Right? So all of these things are relevant. Not just the building part or not just the hanging-out-with-your-people part.
Poornima: So that's great. So how do you pick a cohort?
Tina Lee: We pick a cohort the way I would build a team.
Poornima: OK.
Tina Lee: So because...before I used to be a technical rep, I spent some time being a recruiter, and having that safe space for learning is really important. And I realize how hard it is to do this when you are a mother as well. So I work with my board and we have several steps to our application process, the last one of which is an in-person interview.
Poornima: OK.
Tina Lee: Where we really talk to the moms. “Are we right for you? Are you ready for this?” Because a lot of learning will have to happen outside of the classroom too, right? So they have to have capacity and they have to be really clear about why they're doing it because otherwise you're not going to stick to it and it's not going to feel like you achieved something at the end, right? So we walk them through that. And it’s worked out pretty well. All the moms come together and I think because being a mother is such a democratizing experience they all show up as people who are there to support each other, and want to learn together, and move forward together.
Poornima: So walk us through what a day in the life of MotherCoders looks like.
Tina Lee: Sure.
Poornima: For your students.
Tina Lee: So, Saturday only classes right? You would go...you would drop off your baby. So we have a half an hour transition time. It takes a while to explain have they eaten, have they slept, all that stuff.
Poornima: Right.
Tina Lee: So you hand off to the caregiver and you're in your seat by 10:00 right?
And then you learn until noon. And then we have lunch together. We always have lunch catered because it's such a special time and they have to bond. And a lot of times we'll have speakers there too, right, who will stay and hang out with them. So it’s a great time to just kind of network and talk. And then after lunch they learn some more. And then around 3, we leave half an hour for reflection. So I'm big on you learn, but at the end of the day, you have to pause and really connect what happened to how you're feeling about it and how it connects to your own understanding of the work, OK? And then after that they pick up their kid and then they go.
Poornima: OK.
Tina Lee: In terms of content, it will vary by day. We have specific build days where people just get together and they build and we help you work through your wireframes and your issues. There are days when we have lectures. We don't really have a lot of lectures. We have “discussions,” I should call them. And then there are other days when we have guest speakers who come in and they talk about a topic that they want to talk about, or they do a workshop, or something I've been doing is I've been pairing a cyber security info sec expert with data scientists.
Poornima: Yeah.
Tina Lee: So on one side you have data scientists who want like all the data, and then the other side you have people who are in charge of the data or making sure they're following the rules about data and saying, "Whoa." So that's been a very illuminating conversation, too. So we've been doing stuff like that.
Poornima: That sounds great. So how many people have you graduated? You mentioned you have
five cohorts coming who have gone through the program?
Tina Lee: Thirty-four so far.
Poornima: Great. OK.
Tina Lee: Yeah we're really delighted because 34 moms represents families, right?
Tina Lee: And there is over 50 kids. And another way to think about this is we've placed 34 stem role models.
Poornima: Oh, great.
Tina Lee: Right? Into homes. They are inspiring our next generation of kids. Right? So not only are these women changing the trajectory of their own family like right now, their kids are going to be impacted, too. So we're really looking at this from a multi-generational perspective.
Poornima: Yeah. That's fantastic. So what are some immediate outcomes that you see from them graduating in the program?
Tina Lee: Jobs!
Poornima: Yeah.
Tina Lee: They're getting jobs.
Poornima: Good. OK.
Tina Lee: They're getting jobs in tech, right?
Poornima: Yeah.
Tina Lee: So we have moms who have become front end engineers. We have moms who have become mobile app developers. We have moms who have become user experience designers. Some have been promoted, of course, because now they have this new tool kit. And then we have other moms who are proceeding with their startup dreams. So potentially, right, we have entrepreneurs out there. So, this has been really exciting to see them grow.
Poornima: That's great. So it’s a lot of variety of outcomes but all pretty positive.
Tina Lee: Mm-hmm.
Poornima: So how do you measure success for MotherCoders?
Tina Lee: Right now the way we're measuring success is completion.
We're also looking at how diverse we are in terms of the people that we have in our classes. Right? I'm an intersectional feminist.
Poornima: Yeah.
Tina Lee: Eighty-one percent of women become moms and if companies are really worried about diversity? I'm like, “Come to me, because we have queer moms, we have moms that emigrated from other countries, like just everybody.” We just think about it racially, religiously, geographically, right? So the way we measure success—there's a piece of the diversity piece, and then there's a completion piece, and then we're starting to track not only who got jobs or who got promoted, but how much did they increase their income?
Poornima: Oh, great.
Tina Lee: Or earning potential? Right?
And that's been tricky because we've been running cohorts and it takes time. And different moms have different capacities, as I mentioned. And some of them have kids, again.
Poornima: Sure.
Tina Lee: Because moms do. So, we're trying to figure out a way to tell that story better but just anecdotally because there are only 34 moms, I keep pretty close tabs on them.
Poornima: Yeah.
Tina Lee: I know that they are making more money because some are buying new homes.
Poornima: OK.
Tina Lee: Some are buying new other things.
Poornima: Yeah.
Tina Lee: And they're updating their LinkedIn profiles and LinkedIn tells me that, right?
Poornima: Sure.
Tina Lee: So we know that they're getting skills, getting new jobs, buying homes, and on top of that, starting businesses.
Poornima: So I love that you care about this diversity piece, and I do, too. So I'm going to ask you this question: What about Father Coders? You know there's a lot of stay-at-home dads that's becoming less and less of a stigma, but would you ever be open to allowing men to come in and participate in your program?
Tina Lee: Not in the foreseeable future.
Poornima: OK.
Tina Lee: And here’s why, right? The reason why we don't do Father Coders is exactly the same reasons why we do MotherCoders, right?
Poornima: OK.
Tina Lee: Think about it from a kind of a cultural perspective.
I have actually gone to meetups and programs. They're very friendly. Not that they're not friendly to women, but in terms of belonging, I think women have a harder time feeling a sense of belonging in those spaces, right? And you walk into a room and you don't see anyone who looks like you...it's very intimidating and there's a lot of trepidation around going back again.
So we create this safe space where we know that women will find inviting, right? And I think mothers specifically have a very unique set of challenges, right? That go beyond just being a woman, right? The scheduling, the feeling of pressure to be the perfect mom, and the perfect spouse, and the perfect worker, all the perfect things, right? And then on top of that picking up skills and working in an industry that's predominantly men is very intimidating, right?
Poornima: OK.
Tina Lee: So all of that comes together in MotherCoders. And I understand that fathers have the same challenges with scheduling, but I bet you they would feel less trepidation walking into a space that was designed more for someone without the challenges that moms have.
And we actually have had conversations with women who come up to me and say, "I'm not a mother but I care for a family member. Can I come?"
Poornima: Yeah.
Tina Lee: So I can see at some point that we rethink our structure.
Poornima: Oh I see. Right.
Tina Lee: But we exist for the same reason that Hackbright exists and Women's Colleges exist.
I graduated out of a Women's College. So all of those things still stand and until we kind of break apart some of those barriers to women I think I need to keep doing what I'm doing now.
Poornima: Thank you so much for coming on the show. Is there anything else you'd like to share with our audience before we end?
Tina Lee: Yes, I would love to share with you kind of my pie-in-the-sky kind of vision that I'm working towards, right? Women from all all over the U.S. and the world reach out to me and ask when we're coming to their communities.
Poornima: OK. Yeah.
Tina Lee: So I know there's a desire for this type of training program all over and we're trying to figure out a way to get there. And we envision ourselves being in any community that wants to have a MotherCoders but, because, you'd know, technology varies by geography, and industry, and all these different things. We want to design a program that's thoughtful enough and flexible enough where they can design it to fit their local conditions, right? To fit the needs of their local employers so that moms will have a place to move to. So we are moving towards that. We are actively fundraising towards that.
And the reason that we're a nonprofit is because we're committed to helping women who cannot afford to pay $10,000 for Bootcamp or they're not sure if they want to invest in that even before having tried out something more preliminary. So we are working towards a vision where we're all across America, if not the world, so that we could help women everywhere as they transition into being moms and thrive in the workplace.
Poornima: Great. So how can we help you with that?
Tina Lee: Well, help us get our word out. This is great, right?
Help us send moms who are interested in taking our program to us. I would also love it if employers who are worried about retaining moms that they have to provide professional development for them through us. And then also figure out a way to maybe work with us to develop programs or return ships where women who may have stepped off want to get a refresh and then go back.
Poornima: Yeah.
Tina Lee: So those are great ways. And then of course, we're always looking for donations, always looking for sponsorships. So many ways to partner with us and everything can be found on our website.
Poornima: Wonderful. Well we'll be sure to include the link to it.
Tina Lee: Thank you.
Poornima: Thank you again for joining us, Tina. Thank you for tuning in today and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode of *Femgineer TV*. If you've enjoyed this episode, then please be sure to share it with your friends, your team, your employer, and of course, all the mothers that you know to get the word out. And be sure to subscribe to our YouTube channel to receive the next episode of *Femgineer TV*. Ciao for now.
If your company doesn’t produce a hockey stick graph for growth by the end of the first year, you’ve done something wrong. Don’t expect it to become one of the fastest-growing companies, just shut it down!
Seems drastic, no?
Sadly, that’s what many founders are led to believe.
The truth is, it can take several years to really figure things out. Some of the fastest-growing companies today began really slowly.
To debunk the myths around how long it takes to really see significant growth, I’ve invited Ooshma Garg, the CEO and Founder of Gobble.
Gobble is a weekly dinner-kit delivery service that helps busy people cook dinner in just 10 minutes with one pan. It is growing quickly, doing $100M in sales. But it didn’t happen overnight. It took 3+ years of twists and turns through the trough of sorrow.
This is one of my favorite episodes because Ooshma does a great job of talking openly about issues that many founders struggle with like:
- why you should pursue your idea, even when you don’t have a funding or a technical co-founder
- what to do when your lead engineer leaves right before you launch;
- why finding product/market fit is really about becoming an expert in the field
- transitioning from a bespoke service to a product that scales;
- how to deal with competitors that creep up on you
- how to deal with the criticism of going at your own pace
- why it’s OK to go back to investors that had initially rejected your idea
- how to put aside your ego and do what is best for your company.
--
FemgineerTV is produced as a partnership between Femgineer ((http://femgineer.com/) and Pivotal Tracker (http://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).