Info

Build

A web show where Poornima Vijayashanker, the founder of Femgineer, interviews guests on topics related to startups, entrepreneurship, software engineering, design, product management, and marketing. Sponsored by Pivotal Tracker.
RSS Feed Subscribe in Apple Podcasts
Build
2018
December
November
October
September
August
July
June
May
April
March
February
January


2017
December
November
October
September
August
July
June
May
April
March
February
January


2016
December
November
October
September
July
June
May
April
March
February


2015
August


Categories

All Episodes
Archives
Categories
Now displaying: Page 1
Dec 10, 2018

Last week on Build, we shared what allyship is and why it can help build inclusive workplaces. Anytime new approaches like these come out our defenses go up because it can be challenging to change mindsets and best practices. Plus there’s some fear around what the unintended consequences will be.

 

I hear ya!

 

Here’s the thing about allyship, you don’t need to get the green light from someone at the top or put in a ton of effort to make an impact. Turns out there are everyday actions that can benefit your team and workplace and make you a better ally.

 

In today’s episode, we’ll be sharing them with you to help you get started as an ally!

 

To help us out, I’ve invited Karen Catlin, co-author of Present! A Techie’s Guide To Public Speaking, a leadership coach, and an advocate for inclusive tech workplaces. You may recall seeing Karen in a few episodes from last year on mentorship.

 

I invited Karen back on to the show to talk about the work she has been doing coaching allies.

 

Given Karen’s rich career in tech spanning 25 years, she has a lot of experience to draw from, and it has inspired her to help other become better allies and create inclusive workplaces.

 

Here’s what you’ll learn as you watch today’s episode:

 

  • How You Can Get Started Being An Ally
  • How Karen went about testing a number of simple everyday actions people can take to being an ally
  • 3 simple everyday actions you can start to take immediately
  • How Companies Have Benefited From Allies Taking Simple Everyday Actions
  • A Best Practice For Being A Better Ally In Your Community

 

Want to get in touch and learn more from Karen?

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

 

--

 

## 3 Simple Everyday Actions You Can Do To Be A Better Ally And Create An Inclusive Workplace Transcript

 

Poornima Vijayashanker:                     In the last episode, we talked about what allyship is, and why it's important for helping with diversity in the workplace today. If you missed that episode, I've included a link to it below this video. In today's episode, we're going to dive into some best practices on how you can become a better ally through simple, everyday actions. So stay tuned.

                                                 

Welcome to *Build* brought to you by PivotalTracker, I'm your host Poornima Vijayashanker, in each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now two big misconceptions that a lot of folks have when it comes to being an ally for diversity is thinking that they need to have a green light from some high level executive in order to have their initiative come out, and thinking that the initiative has to make a big impact in order to even pursue it.

                                                 

Well it turns out that there are some everyday actions that you can do that will cause a ripple effect and improve diversity in your workplace, and we're going to share what those are in today's episode. And to help us out, Karen Catlin is back. Karen is my co author for our book Present, she's also a leadership coach and an advocate for diverse and inclusive workplaces. Thanks for coming back on the show.

 

Karen Catlin:                     Thanks so much for having me again.

 

What Allyship Is And Why It’s Important

 

Poornima Vijayashanker:                     Yeah, so let's do a quick recap for people who might be joining us. Tell us what allyship is, and again why it's important today.

 

Karen Catlin:                     Mm-hmm (affirmative), so allyship is simply using your position of privilege to make more inclusive workplace, and help other people be successful if they don't have quite as much privilege as you. And this is so important today, because we have a war on talent, it's hard to hire people so you want to cast a wide net and keep those people once you've hired them, keep them productive and working hard at your company, and stayed, staying there.

                                                 

And, there are all these studies showing the economic benefits, benefits of improved innovation, problem solving, and decision making. So that's why it's important.

 

How You Can Get Started Being An Ally

 

Poornima Vijayashanker:                     Yeah. So let's talk about how people can get started, because I'm sure there's people in our audience who would love to get started as an ally.

 

Karen Catlin:                     Yeah, so it's really not that hard. And I love the way you started out saying you don't have to have a huge initiative, you don't have to be the VP of people at your company, or head of diversity and inclusion to start being an ally. You simply I think need to just start paying attention to what's going on around your workplace, and raising awareness yourself, and if you're not really aware of like what are some of the things I could be doing, it's fine to ask someone who is an underrepresented gender, or minority, just ask them for some feedback of what are some of the challenges you're facing, and what's one thing I could be doing to help you out?

 

How Karen Catlin Went About Testing Simple Everyday Actions People Can Take To Being An Ally

 

Poornima Vijayashanker:                     So in your upcoming book, you provide a myriad of best practices, but before we dive into some of those, let's talk about how you went about testing these practices.

 

Karen Catlin:                     So I start testing these ideas actually on Twitter.

 

Poornima Vijayashanker:                     OK.

 

Karen Catlin:                     About four years ago, I started a Twitter handle called @betterallies. And it was anonymous, it still is anonymous until this show actually.

 

Poornima Vijayashanker:                     Yeah.

 

Karen Catlin:                     And I started tweeting simple, everyday actions that someone could take to create a more inclusive workplace. And my whole goal was that I didn't want it to be, you didn't have to feel like you were the head of people at your company, or head of diversity and inclusion to make a difference. It really was something that the normal person could do. So I started tweeting these ideas based on my experience working in tech, based on coaching clients I had, as well as the research that was being published at the time of the challenges that are happening in tech workplaces as well as other workplaces by people who are underrepresented.

                                                 

Based on the reaction, I kind of started realizing, OK that works, that's helpful, that's not so helpful, and where it was helpful it was really helpful, and I started getting again, positive reinforcement that these messages were making a difference to the people who were consuming them. And checking out my Twitter handle too it's like, there's some, you can use Twitter Analytics to find out a little bit about your demographics.

 

Poornima Vijayashanker:                     Mm-hmm.

 

Karen Catlin:                     And I have about 50% followers who are men, 50% women, so I know that there are a lot of men who are paying attention to this and appreciating the content.

 

How Companies Have Benefited From Allies Taking Simple Everyday Actions

 

Poornima Vijayashanker:                     Nice. I know you've coached some men, so do you mind sharing maybe one or two examples of how these best practices have helped their team, or their company?

 

Karen Catlin:                     Sure. One that's just so memorable to me is I was coaching a man about, he wanted to hire more diverse talent for his team, and we started talking about just different aspects. I asked him just so how does the team socialize today, like you know, to go out to lunch or after hours? What's social life like for the team? And he looked at me, and he said, oh, you mean I probably should've told those guys going to the strip club for lunch last week that that's not cool? I'm like yeah maybe that wasn't exactly the most inclusive social event.

                                                 

He honestly like, bless him, he just hadn't realized how other people might feel that they couldn't go out to lunch that day with some of the team members, right. Another example is some of the language we use, and I know Pivotal Tracker I was reading a blog post that they now have something in their daily stand up, and in their bill process for the week called the Inclusion Thing of the Week.

 

Poornima Vijayashanker:                     Oh, cool.

 

Karen Catlin:                     And they just come up with the idea of something they can be doing to be more inclusive, and they talk about in their daily stand ups and everything, and one of them was simply don't use the word “guys.” Some people may be thinking, “Wait a second Karen, what do you mean? Guys is gender neutral, we use it all the time.” To them, I always like to say well if you were a woman, you need to use a public restroom, and there was a door marked guys, do you go in? Probably not.

                                                 

Or if someone were to ask you, a man, how many guys did you date in high school? They're not thinking women, right there, right? So “guys” is not gender neutral, so that's another thing that as Pivotal Tracker learned is a simple thing they could do. As I've started coaching other people too, examples come up such as, “Well what's your spirit animal?”

                                                 

Well maybe that's not very inclusive because spirit animal is actually an important part of some Native American cultures, and spiritual component of it. So it's really kind of appropriating their culture. So I can't believe this is such a beautiful example of an alternative. Why not use patronas instead from Harry Potter right? So just swap that out, and have everyone feel that they can be included in the conversation.

 

Best Practice #1 For Being A Better Ally And Creating An Inclusive Workplace: Reviewing How We Give Feedback To Women Versus Men

 

Poornima Vijayashanker:                     Got it. OK so let's dive in now and have you share three best practices from your book.

 

Karen Catlin:                     Yeah. So the first one I'll share is all about performance feedback. People who do research into performance feedback have done things like study performance reviews, written performance reviews, thousands of them, and found that there is gendered difference in how we give feedback to women versus men. Some of that gender difference shows up in the form of the feedback that we give to women is more vague.

 

Poornima Vijayashanker:                     OK.

 

Karen Catlin:                     And with men, it's more specific. We're telling men more often that this is how your work has impacted the business, here's how you can keep impacting the business, here's a skill you need to learn to have a bigger impact on the business. And with women less so, it's more vague. And at the same time there have been studies showing that we actually tend to hold back from giving constructive feedback, the hard feedback, to people who are different than us.

                                                 

So whether that's a different gender, different race, or so forth, we hold back from giving the constructive feedback probably because we don't want someone to think that oh he's only giving me that feedback because I'm a woman. So as a man we might think I don't want to give a woman feedback because she's going to think I'm sexist if I criticize her. I don't want to give a person of color feedback if I'm white, because they're going to think I'm racist, right.

                                                 

So we hold back, and we soften the feedback. But that doesn't do anyone any good, right.

 

Poornima Vijayashanker:                     Yeah.

 

Karen Catlin:                     We really need that feedback, constructive as well as the positive feedback to keep growing our careers. So in the book there's a whole chapter on giving feedback with best practices of doing things like looking at the language you're using, and are you actually tying the feedback that you've giving someone to their performance? And to the impact they're having on a business?

                                                 

Are you providing skill based suggestions about how they can grow their career that way? And, at the end of the day, are you writing reviews of roughly the same length for men and women, for all of your staff? Because that's one indicator that you might be skimping on the feedback, real easy thing to check.

 

Best Practice # For Being A Better Ally And Creating An Inclusive Workplace: Give Credit To An Idea’s Owner Publicly

 

Poornima Vijayashanker:                     Nice. Well that's a very comprehensive best practice, thank you for sharing. Do you have another one?

 

Karen Catlin:                     Sure, pay attention to what happens in meetings. So much of tech and frankly any workplace is driven through meetings. And, in meetings there are a number of dynamics at play that really prevent people who are in the minority from speaking up and fully participating. Perhaps it's that they are interrupted, we've talked about that already.

 

Poornima Vijayashanker:                     Yep.

 

Karen Catlin:                     And number of reasons why that might happen, but if that is part of your culture, or perhaps there are some repeat offenders who interrupt frequently, that could be something you could be paying attention and stopping. It could be that the ideas are not being credited appropriately when women or people in minority positions are bringing them up.

                                                 

It may be that someone's asking a question, like in a client meeting of what they, they asked the question to the person who they think is in the power position of the meeting. Probably a man, when really it should go to a woman. So redirect that question to well, you say something like, that question would be best answered by Poornima, the founder of Femgineer, like throw that question to the right person. So look for ways that you can create more inclusive meetings by just paying attention to these social cues that are happening.

 

Poornima Vijayashanker:                     Got it. So this is great in meetings, but I think sometimes we're not sure if we're doing it the right way. So is there a way we can solicit feedback from our peers, from our boss?

 

Karen Catlin:                     Yeah, why not use the back channel?

 

Poornima Vijayashanker:                     OK, yeah.

 

Karen Catlin:                     The back channel that's in any meeting, I mean we all use them right. The DM's or the text messages, private chats to just like touch base with people, like what did you think of that point they just made? Or did I clarify everything I should've clarified? We're constantly using the back channels, why not just ask people in the meeting that you trust, have someone DM you when you could've been a better ally, when you could've stood up for someone who was interrupted or had trouble making a point in the meeting, or whatever it is right. Use the back channel.

 

Best Practice #3 For Being A Better Ally And Creating An Inclusive Workplace: Saying No To Office Housework That Isn’t Your Job

 

Poornima Vijayashanker:                     OK. Your third best practice that you'd like to share with us.

 

Karen Catlin:                     Yeah, so the third one is I think I'll choose office housework. So office housework is the stuff that needs to happen in any office and it's no ones job really to get it done, and it's important work, but not really leading to business growth, career growth, and so forth. The classic example is taking the minutes at a meeting. When that's not your job.

 

Poornima Vijayashanker:                     OK.

 

Karen Catlin:                     That's your job, that's not office housework, that's your job. But if it's no ones job and you just have called a meeting and someone needs to take the minutes, it often falls on the shoulder of a woman sitting around the table. The problem with that is the person taking the minutes is usually a step behind, so they're not participating in the meeting at full force so to speak, so they're being left out, their voice is counted as much. They're also put in a subservient position to maybe their peers who are sitting around the table, and that's not fair, and that might have longer impact right, well beyond the meeting.

                                                 

So it's much better to set up a rotation.

 

Poornima Vijayashanker:                     Yeah. Actually did that at my second startup, yeah.

 

Karen Catlin:                     Excellent, so you were a great ally there. But office housework isn't just meeting minutes, it's also things like maybe it is someone's got to clean up all the comments in the code before we ship it off to our partner, or to make it open source, right. That important work needs to happen, but it doesn't really lead to career growth, right. It could be oh we need someone to mentor the intern again this summer, Susie did it the last five summers and she's awesome at it, right.

 

Poornima Vijayashanker:                     Right. Maybe Susie doesn't want to do it again, she wants to do something else, yeah.

 

Karen Catlin:                     Exactly, because the first time yeah maybe there's some career growth area, you learn to mentor, you learn to have that leadership skill, but the fifth time you've probably mastered it and maybe it's time to spread the wealth.

 

A Best Practice For Being A Better Ally In Your Community

 

Poornima Vijayashanker:                     Yeah, that makes sense. So these three are great for inside your company, do you have maybe a couple best practices you would share for the community at large?

 

Karen Catlin:                     Sure, so I think we should think about our networks, the networks we build professionally. Our networks, and there's research on this too, that they become very homogenous, or just like me, because we meet people and hang out with people, and connect with people, and stay in touch with people who we share some common interest with, right. So it's not that that can't cross gender bounds, or racial bounds or anything like that, but we tend to have networks that are primarily just look like us.

                                                 

So the impact of that is that then we only have people who are like us that we connect with opportunities, whether that is to get a new job, or to speak at an event, or some other career growing opportunity, right. We recommend people in our network. So the call to action here is diversify your network. The next time you're out at any kind of professional event, go say hello and introduce yourself to someone who does not look like you.

 

Poornima Vijayashanker:                     Yeah.

 

Karen Catlin:                     Whatever that means right. Start a conversation, see if you can't connect them with an opportunity, and reverse might happen to. So diversify our network I'd say is the first one. The second thing is, and this is such an important part of being an ally is, don't just be a bystander, or like I don't do these bad things, right. Be an upstander. When you see something bad happening, don't just like say that's not my problem, like say something, and see something, say something.

                                                 

There is a story that was shared on Twitter just I think a week or two ago of a woman saying that one of the worst things that ever happened to her as a public speaker was that there's a man who asked a question during the Q&A and kind of demanded to know was she single, because he wanted to pursue things with her. And at the time, I mean I wish there had been an upstander in the audience who would just stand up and say basically, hey dude, we don't do that here.

 

Poornima Vijayashanker:                     Right.

 

Karen Catlin:                     That's all it takes, defuse it and put the guy in his place, and show some support for the woman.

 

Poornima Vijayashanker:                     Yeah. Well you remember when I was in Canada, I fortunately had a team that helped when I had a heckler in the audience, and just kindly took this gentleman outside, and I could kind of move on with my Q&A, so it helps to have those folks in your kind of corner.

 

Karen Catlin:                     Yes, absolutely.

 

Poornima Vijayashanker:                     So be one of those people.

 

Karen Catlin:                     Be one of those people, yes.

 

Better Allies: Everyday Actions For Creating More Inclusive Engaging Workplaces

 

Poornima Vijayashanker:                     So I know we just scratched the surface. So tell us more about the upcoming book as well as how people in our audience can work with you.

 

Karen Catlin:                     Yeah, so the book is *Better Allies: Everyday Actions for Creating More Inclusive Engaging Workplaces*. And you can get in touch with me at KarenCatlin.com, but I really encourage you to follow @betterallies on Twitter, or other social channels, we're on Instagram, Pinterest, and Medium as well. And there's a newsletter also so if you go to betterallies.com you can get the subscription link to the newsletter.

 

Poornima Vijayashanker:                     Wonderful, thank you.

 

Karen Catlin:                     Yeah, thank you.

 

Poornima Vijayashanker:                     Well I can't wait to read Karen's book, and that's it for this episode of *Build*. Be sure to share this episode with your teammates, your friends, your boss, anyone who you think may be wanting to be an ally, and be sure to subscribe to our YouTube channel to receive the next episode. Ciao for now.

                                                 

Dec 3, 2018

As the year comes to a close, you’re probably getting ready to attend a holiday party, maybe your company’s. And maybe you’re concerned about what to talk about with your teammates and boss. Diversity and inclusion may be hot buttons to stay clear of, especially with people scrutinizing practices and scoffing at the benefits.

 

But you know it’s important…so what can you talk about? How can you set your team and company up to see a change next year?

 

Allyship.

 

Wondering what it is and how to be a better ally? Well in today’s episode, we’ll cover what allyship is and how it can help you build a more inclusive company.

 

To help us out, I’ve invited Karen Catlin, co-author of Present! A Techie’s Guide To Public Speaking, a leadership coach, and an advocate for inclusive tech workplaces. You may recall seeing Karen in a few episodes from last year on mentorship.

 

I invited Karen back on to the show to talk about the work she has been doing coaching allies.

 

Given Karen’s rich career in tech spanning 25 years, she has a lot of experience to draw from, and it has inspired her to help others become better allies and create inclusive workplaces.

 

As you watch today’s episode, you’ll learn the following:

 

  • What an ally is and what allyship is
  • How people can develop an awareness for allyship
  • Why you don’t need to be a leader to be an ally in your company
  • Why men care about being an ally
  • How to spot or approach an ally to work for

Want to get in touch and learn more from Karen?

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## How Being An Ally Can Help You Create An Inclusive Workplace Transcript

 

Poornima Vijayashanker:         You've probably read a number of headlines around discrimination in tech. Despite all of the diversity initiatives, it seems like change is pretty slow. So, what can we do to make change faster, both in our teams and our companies? Allyship. If you're not familiar with what allyship is, well, in today's *Build* episode we're gonna talk about it. So stay tuned.

                               

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. As you're well aware of, diversity is a hot topic today. There are a number of practices, but people are scoffing at their benefits and they're wondering if there can really be anything done in the near term.

 

Well, there is a new approach called allyship. In today's episode, we're gonna share how allyship can help you and your company. To help us out, I invited Karen Catlin. Karen is my co-author on our book, Present. Karen is also a leadership coach and an advocate for inclusive tech workplaces. In the episode today, we're gonna be talking about what allyship is, why it's important, and in the next episode, we'll be sharing some of the best practices that you can put in place every day.

 

Karen Catlin:                  Thanks so much for having me on the show again, Poornima.

 

Poornima Vijayashanker:         Yeah.

 

Karen Catlin:                  It's great to be here.

 

Why Diversity And Inclusion Have Been On A Decline In Tech For Two More Than Two Decades

 

Poornima Vijayashanker:         Thanks for coming on. You've had a rich career in tech. Why don't you share with us what you've done, as well as problems you've experienced over that time?

 

Karen Catlin:                  Yeah, so I spent about 25 years working in tech. I started out as a software engineer writing code for a living, and over time moved into management roles, and eventually into executive leadership. Most recently, I was a VP of Engineering at Adobe Systems. During that time, I definitely saw this interesting thing happening where there was a decline happening in the number of women coming into the field. There's a lot of research that backs this up, but there are just fewer women studying computer science. Not that that's the only way you get into tech, but it is definitely a key way, here in Silicon Valley, to get into tech.

                               

So, there's a decline happening with the number of women who are into the field, and at the same time, women leave tech at twice the rate of men at that mid-career point. As a result, over the 25 years that I spent working in tech, I really saw the impact. I saw that there were a lot fewer women around and less diversity in general.

 

Beliefs That Have Held Leaders Back From Creating An Inclusive Workplace

 

Poornima Vijayashanker:         Were there specific problems that maybe you incurred or you saw happening within the companies?

 

Karen Catlin:                  Yes. And I worked for some really good companies, so I don't wanna throw my companies under the bus that I used to work for at all. But I will say that most of the men I worked with really, firmly believed that their company was a meritocracy, that you got ahead based on your merits, that if you worked hard and did good work you'd be recognized and promoted. But the numbers just really didn't back that up. In any company there are more women in the entry level, and as you get up to the C level, it just declines like a pyramid. So, definitely there was something going on.

                               

Personally, some of the things I witnessed...and I think this will resonate with a lot of women who are watching this, is something called bro-propriation where you say something in a meeting, as a woman, and it's a pretty good idea but it kinda falls on deaf ears, doesn't really go anywhere. And then in the same meeting, a little bit further on, somebody says the same thing, usually a guy because there's mostly men in the meetings. A guy says the same thing in the meeting, and gets all the credit. We call that bro-propriation, because a bro has appropriated your idea, of course. That happened to me so many times.

 

Examples of Unconscious Acts That Contribute To A Lack Diversity And Inclusion In The Workplace

                               

Then there's also this thing, and it still happens to this day, where people give me what is called an unconscious demotion. An unconscious demotion...I bet this has happened to you, too. You meet someone for the first time and you might say, "Oh yeah, I work in tech." And they say, "Do you work in HR or marketing?" That's an unconscious demotion. Nothing wrong with those fields at all, but if you're a woman who's already in a very male dominated field, like engineering, computer science, tech in general, it's like this yet another reinforcement that you don't belong there. That's just not cool.

                               

It happened to me just a couple months ago. I was visiting my husband at his office and I met one of his new colleagues. Sure enough, he said, "What do you do?" I said, "Well, I used to work in tech, was VP at Adobe for a long time." And just told him something like that. And said, "Oh, well at Adobe, were you in marketing or HR?" I mean, literally, he said those words, and I just kind of...I wanted to punch him. But I ended up just sort of smiling and saying, "Actually, I was a VP of Engineering."

                               

So those are just a couple examples of things I've seen. I could share some more, but I think you probably have some more questions you wanna get to.

 

Poornima Vijayashanker:         Yeah, of course. It's unfortunate that you're experiencing this and seeing this happen inside of your companies and other companies. Were there things that you were also seeing in the community at large over the years?

 

Karen Catlin:                  Yes. Definitely started seeing...First of all, in support of women as well as other kinds of diversity, there's a lot of activity going on, a lot of conferences, a lot of discussions, a lot of research. All of that's great. And I'm starting to see men wanting to also really get involved and help with diversity initiatives, help support women in their companies, and so forth. I saw that first hand. I also saw it at places like the Grace Hopper Celebration.

 

The Grace Hopper Celebration...I mean, you and I know. We've been there a number of times—

 

Poornima Vijayashanker:         It's the largest technical conference for women.

 

The Origin Story of Better Allies: The Bingo Card At Grace Hopper 2014

 

Karen Catlin:                  Yes, exactly. In 2014, there was something called the Male Allies Panel. It was a panel of men who were leaders at their company, and talking about what they did for women in terms of allyship, to support them, to champion them, and so forth at their workplaces. Unfortunately kinda fell flat. It fell flat because ahead of time, some women were upset that men were taking up valuable stage time at this conference, right?

 

Poornima Vijayashanker:         Sure. Yep.

 

Karen Catlin:                  Some women also were concerned that these men really weren't the best allies.

 

Poornima Vijayashanker:         OK.

 

Karen Catlin:                  So they created a bingo card. They created a bingo card of phrases they expected those men to be saying that would show exactly how far they still had to go to become real allies. They handed the bingo card out, right? And of course, during that panel, the men were saying different things and falling short, and the women were checking off those bingo squares and started yelling bingo at different points during the panel.

                               

Now, when I heard about this...I wasn't at that panel, I sort of was following it on social media. When I heard about this, I sided with these poor men. These were actually good men, their hearts are in the right place. They wanna do the right thing. They just don't know exactly what women need. They certainly don't know what people of color need, or you put those together, women of color, and so forth. So, I see people wanting to do the right thing but not quite knowing what to do.

 

Why Diversity And Inclusion Initiatives Are Important Now More Than Ever                              

 

Poornima Vijayashanker:         Got it. Why is this even important, right? There's so many of these diversity initiatives that come out and benefits just are slow-coming or maybe not existent at all in some people's eyes. Why do you think this is important?

 

Karen Catlin:                  Yeah. First of all, especially in the whole me too era right now, you kinda hope that people just wanna do the right thing, and it feels maybe like a moral imperative to support people of all types of backgrounds. So you kinda hope that. But at the same time, there's so much research that shows that diverse companies are more economically profitable and successful, that there's better decision making, there's more innovation, there's better problem solving. It's so many benefits that have been proven in social science and economic research studies coupled with it's the right thing to do. Then you layer on top of all of that, there's a big talent shortfall in tech as well as across the whole United States in terms of we've got the lowest unemployment numbers in...I don't know, in a generation. So, we have a problem finding the talent to fill a position, so why wouldn't you want to cast the widest net possible?

 

Poornima Vijayashanker:         Yeah.

 

Karen Catlin:                  One more thing. Women can lean in all they want and all they can, but until we start changing our workplaces so that things that have always been done a certain way change, the women aren't going to be successful. We really need to start looking at our workplaces and changing our workplaces.

 

Why Workplaces Are Slow Or Resistant To Change And Embrace Allyship

 

Poornima Vijayashanker:         OK. What do you think is hindering that change?

 

Karen Catlin:                  There are a couple of reasons. I would say one is this is the way we've always done it. Why would we bother changing? An example of that is, well, I've always hired the best people for my network. Why would I go outside of my network? Well, if you don't go outside your network, and your network is your best buds, people who are probably just like you, you're gonna continue hiring people who are just like you and you're gonna have homogenous hiring, right?

                               

So, if we've always done it that way, maybe that's something that's holding us back. Another is that there might be concerns that we are taking away something from men who are in positions of privilege right now, right? If we hire more women or people of color or whatever underrepresented minority you wanna fill in the blank there, if we hire more of those people, there's gonna be less opportunity for me. That's not exactly a growth mindset. If you think about hiring the best people, assembling the best team, the pie and the opportunities are just going to expand and there's gonna be larger slices for everyone as a result. That's another thing that's holding people back.

 

The third, I'll say, is that there's just, at times, a lack of awareness. Unless you're living these situations of being interrupted or having your ideas appropriated and so on, and so on, you just might not be aware it's happened to other people. You might not be aware that...even walking around a trade show floor and seeing maybe a sexy pinup image on a T-shirt or a bumper sticker or something, or a laptop sticker even, you might just think oh, that's sort of funny, not thinking about how a woman might feel is she sees such a sexualized image on a conference swag giveaway. So I think that we need to raise awareness as well.

 

Poornima Vijayashanker:         What drew you into this?

 

Karen Catlin:                  What drew me into this is this desire, especially after hearing about the bingo card in, at the Grace Hopper panel of all the male allies, that, coupled with just hearing from man after man that I would just be talking to, maybe casually, or coaching, men really being curious of how can I help here, I really do care about diversity. I wanna create a diverse workforce. I wanna work with all kinds of people. I care. I'm a good person. But what am I supposed to do? There really seemed to be this desire without the information.

 

Why Karen Catlin Decided To Become Coach Others Into Becoming Better Allies

 

Poornima Vijayashanker:         Why did you decide to embark on this mission?

 

Karen Catlin:                  I decided to embark on the mission because I felt like I couldn't not get involved. I really felt like I had a unique perspective. I had been working in tech for 25 years. I understood this industry. I also had this desire to really help make the industry more diverse. I really wanted to have an impact.

 

I started tweeting. After that Grace Hopper conference, I started a Twitter handle called @BetterAllies. I started tweeting answers to this question of what am I supposed to do, and simply talking about here are some simple, everyday actions you can take as an ally to be better for people of all sorts of underrepresented groups in tech.

                               

So I started the Twitter handle. Then I started a newsletter and started getting some really positive feedback from both of those channels. People say Twitter is just a cesspool and everything, but I actually have fan tweets that I get.

 

Poornima Vijayashanker:         Nice.

 

Karen Catlin:                  People like my content. So I got positive reinforcement there. My newsletter is growing like gangbusters, so super happy about that. Again, positive reinforcement. I just decided recently that I had to write a book on the topic, too. I had to take the best of what I learned on Twitter, through what I've been tweeting as well as the reinforcement I was getting there, and the content from my newsletter, and create a book for people to be better allies.

 

What Is An Ally And What Is Allyship

 

Poornima Vijayashanker:         Let's dig into what allyship is. What is an ally, and then what's allyship after that?

 

Karen Catlin:                  Yeah. So, an ally is someone who uses their position of privilege to help someone who has less privilege. So, in tech, that typically is a white, straight, CIS man who has a lot of privilege. They can use that position of privilege to help others. They can do that by doing things like mentoring, sponsoring, championing, speaking out on behalf of them, looking for opportunities, connecting them to different opportunities, being just somebody who's an all around good person, but not just sitting still, not just not being a bad person, but actually taking action to help promote other people.

 

Poornima Vijayashanker:         Got it. So taking initiative.

 

Karen Catlin:                  Taking initiative, yes.

 

Poornima Vijayashanker:         You already touched on this, but who can be an ally besides the straight, white male?

 

Why You Don’t Need To Be A Leader To Be An Ally In Your Company

 

Karen Catlin:                  Definitely. So, allyship is not limited at all. That's the beauty, it's anybody can be an ally. You can be a leader at your company. In fact, I'll share a quick story about a leader that was my manager, a senior vice president at one point in my career. I still remember this time. I had just started working for him. I was new to the company, and I was in a very senior meeting with him. I heard him say, "Well, what I learn from Karen is the following." And then he said something.

                               

I thought at the time, first of all, I didn't say those exact words. So he took what I had shared with him in a one-on-one earlier and reframed it in the company speak. So he taught me how to speak the language as a result. But also, what a shout out he gave me. What he, the SVP, learned from me, was the following. So that's a great example of how a leader who has a lot of cred within the organization can be an ally.

                               

But an individual contributor can be an ally, too. An individual contributor sitting in a meeting and noticing someone might keep interrupting another person, might just pull them aside later and say, "Hey, dude, do you know you interrupt a lot?" And just raise awareness. So it's really a job for everybody.

 

Why Men Do Care About Being An Ally

 

Poornima Vijayashanker:         Yeah. I know we're gonna go into more best practices. Thank you for sharing those. I also know that there may be some people in our audience or just wondering are men really interested in this and questioning if they really care. Maybe you can share from your experience.

 

Karen Catlin:                  I'm sure there's some men who don't care, and that's fine. But there are so many men who do care. I get emails from people, they don't even know who I am. They're just emailing to or DM'ing the Better Allies handle, and they're asking for advice. They're asking for advice about...well, with everything that just recently happened around Judge Kavanaugh and the hearings there, how do I actually support women at my workplace who might be feeling upset about the way that Dr. Ford was treated? I'm getting emails, and messages, and questions of things like well, I just got this great job and I'm thinking about taking it, but hiring me is like the opposite of improving diversity, 'cause I'm a white guy and I really care about working at a diverse company that values that, so help me...Should I take the job? And the answer was yes. If you want the job, take it and go in and be an ally and a champion for diversity from your position of privilege.

                               

So, I hear about that. I get questions of just how can I...I want to respect women I work with. Is it cool to invite them out for coffee, for a one-on-one, just to get out of the office. Can I do that? So, there are so many men who are thinking about this very thoughtfully and really want to make sure that they are being supportive and doing the right thing.

 

How People Can Develop An Awareness For Allyship

 

Poornima Vijayashanker:         That brings up a good point, that you wanna be well-received should you choose to become an ally. How can people develop an awareness and make sure they're headed in the right direction?

 

Karen Catlin:                  Here's what not to do. What not to do is to assume you're the knight in shining armor riding in to save the underrepresented person from whatever-

 

Poornima Vijayashanker:         Princess, yeah.

 

Karen Catlin:                  The princess, whatever. Because there are a lot of women who don't need to be saved, frankly, and don't want to be saved and so forth. And so, instead, what I recommend you do to make sure that you're having the right kind of impact, is look for systemic changes as opposed to one off changes where you are maybe just saving the day. What I mean by that is, let's say you notice that someone on your staff is being substantially underpaid for her grade level. You could make just that fix, potentially, if you have the budget and assuming you have control over their salary. You could change the budget for that one person, her compensation.

 

But better is to look more holistically at your department or the company and request that a salary review be done by gender and perhaps by other minority kind of aspects, such as race, or sexual orientation, and so forth. But make a systemic change, not just a one off. So that's something that’s a best practice to follow.

 

How To Spot Or Approach An Ally To Work For

 

Poornima Vijayashanker:         For our audience out there who maybe want to work for an ally, how can they approach and spot one.

 

Karen Catlin:                  If you are thinking about in an interview setting, like let's say you're going to a company you wanna be working for, someone who is going to be a good ally for you, perhaps your manager, or perhaps coworkers, during that whole interview process, you can literally just ask them. It's like, so what have you done to support a diverse, inclusive workplace here? Just ask them to give you some examples. And then I think you'll be in a pretty good situation for seeing whether or not they're going to be the kind of allies you want them to be.

 

Poornima Vijayashanker:         Well, thank you for coming on the show, Karen, and sharing what allyship is. I can't wait to read your upcoming book. Maybe you could tell us a little bit about it.

 

Karen Catlin:                  The title of the book is Better Allies: Everyday Actions for Creating Inclusive, Engaging Workplaces. It's coming out early 2019.

 

Poornima Vijayashanker:         Now, Karen and I want to know if you've acted as an ally inside of your company, what did you do and what was the impact that you experienced. Share it with us in the comments below this video.

 

That's it for this week's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where we're gonna be diving into more best practices for becoming an ally. Ciao for now.

Nov 12, 2018

Last week on Build, we shared why it instead of rebuilding or redesigning an existing product, it might make sense to build a brand new product, and we walked you through how some folks on the Pivotal Tracker team arrived at their decision.

 

When you start building a new product, you have the best of intentions to revise old processes and move away from bad habits. But it’s easier said than done. So this week we’re going to share some best practices for keeping a new product on track!

 

And to help us out Lisa Doan and Vera Reynolds are back! You’ll recall Lisa is a product manager at Pivotal Tracker, and Vera is a software engineer at Pivotal Tracker.

 

As you listen to today’s episode you’ll learn the following:

 

  • Why it’s important to set a mission and vision for a product and what happens when you don’t
  • What being user-centric looks like in practice
  • How to create a balanced team and have members weight in on decisions during planning meetings
  • How to hold yourself and your team accountable inside a larger organization
  • How to remind people of best practices
  • How to go about testing a new product

-- 

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

 

## 5 Best Practices For Keeping A New Product On Track Transcript

 

Poornima Vijayashanker: In the last episode of *Build*, we talked about why, instead of doing a rebuild, or a redesign, it may make sense to build a brand new product for your company. If you missed that episode, I've included a link to it below this video.

                         

In today's episode, we're gonna dive into some of the best practices for keeping that new product on track. So, stay tuned.

                         

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions, related to building the products, companies, and your career in tech.

                         

In today's episode, we're gonna be sharing a number of best practices to keep a new product on track, as you're building it, and to help us out, I've invited Lisa Doan, who is a Product Manager at Pivotal Tracker, as well as, Vera Reynolds, who is a Software Engineer.

                         

Thanks for coming back on the show, Ladies.

 

Lisa Doan:  Thanks. Happy to be here.

 

Poornima Vijayashanker: Yeah. Let's do a quick recap from the last episode on why you decided, instead of doing a rebuild or a redesign, to build a new product.

 

Vera Reynolds: Yeah. So, initially we thought we were just gonna rebuild Tracker, and when we went out in to the world, we realized that the problem space was just way too big and that net was cast too wide and so we need to follow the pain and find what were the most effective things we solve for our users. You have to understand that Tracker does what it does well. They are other competitors, absolutely, I'm not here to toot my own horn but it's a pretty good product. And so we found that there are other problem spaces that we could talk that are adjacent to Tracker that could complement it in a nice way and so that's we ended up where we are.

 

Poornima Vijayashanker: OK, so whenever we have the chance to build something brand new we want to start with the best practices, new best practices. I'm sure you've both experience this as well as you were assembling your team. What were some best practices and how did you go about learning them.

 

Lisa Doan:  So on the product side we had to adopt a lot of new practices. So when Tracker was built back in 2006, product was less of a thing but since then, things like lean startup have emerged, lean product, user centered design and we needed to catch up on those things. And so we brought in an innovation coach who helped us learn how to do experiments and really think about product in a lean fashion. And so we've been doing a lot of practices around that.

 

Poornima Vijayashanker: And I remember in the last episode you talked about how your innovation coach also helped you with a mission and a vision

 

Lisa Doan:  Yeah.

 

Best Practice #1: Set a Mission And Vision For Your Product

 

Poornima Vijayashanker: So how did that come about or what did that look like?

 

Lisa Doan:  Sure, so when she arrived we had been doing endless research and so she recognized that we were paralyzed and that the first thing we needed to do was pick a direction and that's what the mission and vision were tools to help us do. Where they came from is, the designer and myself had done plenty of research in the years prior about what the major problems our users were facing on Tracker. And so we had a couple ideas of what we wanted to address with the new tool and so those were incorporated during a workshop where everybody on the team was throwing out their ideas and what they wanted this new tool to be, how they wanted to solve problems for users. And after, I think a whole morning of just workshopping it over and over we finally arrived at a mission that everybody could really agree on.

 

Poornima Vijayashanker:                     So what was the mission that came out of this?

 

Vera Reynolds:                I'm gonna paraphrase it a little bit. Our missions to empower individual contributors on a team to align around shared goals.

 

Best Practice #2: What Being User-Centric Really Looks Like

 

Poornima Vijayashanker: So I've heard you through around user centric a lot. It seems like it's a new direction that you're going in. How is this different from what you were doing before with agile.

 

Lisa Doan:  Tracker was born by engineers for engineers and for the majority of our span as a team, we've been a very engineering centered. A lot of our leadership is former engineers who worked on the project. All of our product manager back in the day were extremely technical. I was the least technical PM and I have a degree in computer science. And so we always had this mindset of doing the best engineering possible but we were less focused than we should have been on what our user needs were and that's been a huge cultural shift that we've tried to instigate with our new team, which is, let’s think about the user first. Let's always question why we would build something before we build and that's a muscle that we've really had to really grow and exercise a lot is, rather than just coming up with an idea and just immediately building it is, let's go make sure this solves the user problems, validate that the user actually has this problem. And just really having a discipline around that.

 

Poornima Vijayashanker: Is that because the user is different so maybe you're not dogfooding it as much as a builder.

 

Vera Reynolds: We do actually dog food our current product. So that was one of the first, we were our own first user and I do think that helps with keeping that front of mind, but as an engineer, I've always been getting used to getting candid stories, not so much asking about why we were doing it. It may have been my experience but from what we've learned from our users, that's not unique and there's not necessarily anything wrong with that, however we feel like a balanced team where everybody is involved and has is user centric to pull it up again, provides the better product.

 

Best Practice #3: How To Create A Balanced Team And Have Members Weigh In On Decisions During Planning Meetings

 

Poornima Vijayashanker: So let's talk about those balanced teams next 'cause I think that's the thing that's new to right, in your approach. What's a balanced team.

 

Lisa Doan:  So we like to think about it in terms of three spheres of influence, and so you have a sphere that's very concerned with the user, and so typically that falls to a designer. And then we have the sphere that's concerned with the business and so typically the product manager has been responsible for that. And then we have the engineering side, who's concerned about, usability, who's concerned about building, using the best patterns. And so balanced team isn't about specific roles and filling them but it's that, at any given time someone can weigh in for each of those spheres. And so at some point, whenever you're making a key decision, someone should be able to represent the user, someone should be able to represent the business and someone should be able to think about technical fusibility and the engineering impact of that.

 

Poornima Vijayashanker: Got it. So as you're moving forward and building this product, you have each of those spheres weighing in on the decision.

 

Lisa Doan:  Sure, an example of that is when we go to IPM stories, and we're-

 

Poornima Vijayashanker: What's IPM?

 

Lisa Doan:  Iteration planning meeting.

 

Poornima Vijayashanker: OK.

 

Lisa Doan:  And so as a team will go through the stories that are coming up next and talk about any concerns that we might have. A good example of that now is, sometimes I'll bring a story to the team, and the engineers are capable of challenging me and saying OK, what is the evidence that we should actually build this. Whereas before the engineers were like, "OK, we'll build it." But there wasn't that conversation about what is this actually doing for the user. So it has great impact that we see.

 

Best Practice #4: How To Hold Yourself And Your Team Accountable Inside A Larger Organization

 

Poornima Vijayashanker: Yeah. So while you are a new team you have assembled, you're still operating in a bigger organization. But I know your goal was to stay more startupy and the best startups are always keeping an eye on time as well as money. So how did you hold yourselves accountable?

 

Lisa Doan:  When we first started we...this was a huge challenge for us. We went out and started to do research, but it became this endless research thing and there was no one asking us...well people were asking us when are you gonna build, but we couldn't tell them. We had no idea. Everything was just so vague and open at that point and so we introduced a concept, which I believe comes from the lean startup of metered funding. And so in the startup world, you're only alive as long as the money is there and so you're always trying to convince your investors that they should continue to give you funding. In the enterprise world that doesn't really exist. You have a team, there is funding for you already, and so you just continue using that and there isn't anyone whose making sure that you're making good on it. And so we introduced what we call a growth board. And so we have some stakeholders within Pivotal across different business organizations who will meet with us every six weeks and will hold us accountable to our learning. And so every six weeks we show up and we say this is what we learned and that's how it's affecting our direction. And they make the decision on whether we should pivot, persevere or kill the product.

 

How To Remind People Of Best Practices

 

Poornima Vijayashanker: So it's great that you're following this framework of pivot, persevere and kill, but let's get real here. I'm sure there was a time where you felt like, "Is there  ever gonna be a light at the end of the tunnel?" And if so how did you reinforce or remind people of these best practices?

 

Vera Reynolds: Oh yes, there were times. And I haven't been with the team for as long as Lisa has so I'm sure she has even more times that she can conjure up, but for me there were definitely moments where I questioned what we were doing, I questioned why we were doing it and that's where that balanced team really shone because it wasn't just me from my engineering perspective. It was having those question, I think having designers, PMs and testers with us was really...we were up lifting each other and helping each other move along and get through those tough spots.

 

Poornima Vijayashanker: Lisa, anything you wanna add to that?

 

Lisa Doan:  Yeah, there were definitely a lot of times where we were just really

concerned about, is this even the right direction? What are we doing? There was so much ambiguity and that's an extremely uncomfortable place for many of use. The place we came from is, we thought of features and then we built them and there was this security in it. And the new world we were in is, let's go find problems, let's validate those problems. And the practices were new, it was a huge cultural shift. You're asking people to do things that are outside of their role. And so there was a lot of just stress for the early months and just trying to figure out, is this even viable? Are we even doing the right thing? Was this all just a mistake?

 

Poornima Vijayashanker: And so how did you put that team together?

 

Lisa Doan:  Well like Vera said, we had great people on our team and we still do and we hold each other accountable to our learnings. And so fortunately having all these different perspectives can bring a lot of light. And so sometimes as a PM, if I'm very down about something then the engineers can bring a point like, "Oh but the user said this in this one user interview." Which is something we never had before.

 

Poornima Vijayashanker: Oh, cool.

 

Lisa Doan:  But now they're involved and they can bring up just as much evidence as I can and it's extremely helpful when times get difficult.

 

Poornima Vijayashanker: Yeah. So it's having another, basically set of eyes and ears to pinpoint things that might have gotten overlooked. That's awesome. I know you're currently in beta, but let's switch gears and talk about some of the positive outcomes that have resulted from doing this new product.

 

Lisa Doan:  Absolutely. We've seen a tremendous cultural shift, not just in our team but across the broader Tracker team as well. And so as I mentioned, we came from a veery engineering centric place and so we started to see the other teams start to adopt a lot of lean practices as well. Another huge benefit is, as soon as people started to see us start to get momentum they saw that it was directly related to having a vision and mission. And so now those teams have also gone out and established their own vision and mission which is helping to drive their futures forward and their work forward as well.

 

How To Keep Stakeholders Involved

 

Poornima Vijayashanker: And last time we talked about stakeholders. So coming full circle, how do they feel about this?

 

Lisa Doan:  They're really excited. Our growth board is really enthusiastic and supportive of us. They're also able to connect us to different parts of the organization, and so we've seen tremendous outreach from different parts of Pivotal that are very interested in what we're doing and very excited to join and help us. And so that's been a wonderful outcome of ours so far.

 

Vera Reynolds: They still keep us on our toes.

 

Lisa Doan:  Yeah.

 

Vera Reynolds: It's good to have that positive energy.

 

Best Practice #5: How To Go About Testing A Brand New Product

 

Poornima Vijayashanker: I know you're in a beta phase right now. How are you going about testing?

 

Lisa Doan:  One example I can give, is just last week an engineer and I, we walked over to someone on a different team and we asked them to use our tool, and we sat there and we observed them going through the various steps, and just cringing as they get to steps that are like, "Ooh we gotta clean that up, we gotta fix that." But also seeing that it helped them in their day to day jobs and that was really exciting.

 

Poornima Vijayashanker: Yeah, so doing some usability testing.

 

Lisa Doan:  Yeah.

 

Poornima Vijayashanker: OK. Anything else?

 

Lisa Doan:  We're continuing to do evaluative research and so that's making sure that they're not just on our very specific persona, but we're validation that the problem exists beyond just that persona and how we can potentially solve for various scenarios.

 

Poornima Vijayashanker: I know we've covered a lot and there's probably a lot more we can talk about when it comes to new products and staying on track. What's one thing you would love our audience to just always remember.

 

Vera Reynolds: I would just say if you're engineers, question what you're building and question your PMs.

 

Poornima Vijayashanker: No that's great. Alright well thank you both, Lisa and Vera for coming on the show and sharing some of these awesome best practices.

 

Lisa Doan:  Thanks for having us.

 

Vera Reynolds: Thank you.

 

Poornima Vijayashanker: You’re welcome.

                         

Well that's it for today's episode of *Build*. Be sure to share this episode with your friends, your teammates, and your boss and subscribe to our YouTube channel to receive more episodes of *Build*. Ciao for now!

Nov 5, 2018

Happy November!

 

November is one of my favorite months mostly because I love Thanksgiving. Last year I had a wonderful time celebrating it with Meghan Burgain, Femgineer’s Community Manager in Bordeaux, France. We had a Frenchgiving, and had the opportunity to share how Meghan works remotely.

 

This November we’re going to be tackling a new theme on Build: building a brand new product.

 

If you’ve been building a product for a while, you know it’s natural to start accruing tech debt and product debt. And there comes a point where it becomes really hard to add new features without paying down the debt through rebuilding or redesigning the product.

 

However, there may come a point where neither of those makes sense, and you may be evaluating building a brand new product.

 

The Pivotal Tracker team recently did this. In today’s episode, Lisa Doan, who is a product manager for Pivotal Tracker and Vera Reynolds, who is a software engineer for Pivotal Tracker, are going to walk you through how they came to the decision to build a brand new product.

 

As you listen to today’s episode you’ll learn:

 

  • What spurred the conversation to consider building a new product
  • Why the team chose not to redesign or rebuild the existing product
  • What the team did to identify the problem it was solved with the new product
  • Why the team held off on coding and building and what they did instead
  • Why software engineers benefit from being involved in the research phase of a brand new product
  • How to recruit new teammates to help build, and identify knowledge gaps

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## Why Build A Brand New Product Instead Of Rebuilding Or Redesigning One Transcript

 

Poornima Vijayashanker: It can be really tempting to want to redesign or rebuild a product that's been around for a while. But often, it's much more of an undertaking to do that redesign and rebuild, and it can be easier to instead build a brand new product. The Pivotal Tracker team had to do this recently and in today's episode. they're going to share how they evaluated building a brand new product. So, stay tuned.

                         

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debug a number of myths and misconceptions related to building products, companies and your career in tech. When you've been building a product for a while, it's natural that you start to see tech debt and product debt accrue to a point where it backs you into a corner and it's really hard to add new features without rebuilding or redesigning it.

                         

But at some point, it may not make sense to keep adding to that product and instead, you may want to build a brand new product. In today's episode, we're going to dive into why you may decide to build a brand new product instead of redesigning or rebuilding your existing one. To help us out, I've invited two lovely ladies from the Pivotal Tracker team. Lisa Doan, who is a product manager for Pivotal Tracker as well as Vera Reynolds who is a software engineer on their team. Thanks for coming on the show you two.

 

Vera Reynolds: Thank you for having us.

 

Lisa Doan: Yeah, thank you so much.

 

Poornima Vijayashanker: I know that Pivotal Tracker now has been around for over 10 years, has over 100,000 active users and there's just been a lot of features, and a lot that you've accomplished in the past 12 years. And so, adding to it might have been a challenge and that's why you decided to go a slightly different direction.

 

What Spurred The Desire To Re-Evaluate The Product

                         

But before we even go and talk about that new direction, let's talk about what even caused this to happen. Let's get in a time machine, go back in time. What spurred the change for a different direction?

 

Lisa Doan:  It was really a confluence of a lot of different things happening all at once. On the product side as a team, we were frustrated because we weren't able to really deliver major features that our customers had asked for. On the engineering side there was a lot of tech debt, and a lot of frustration working in the code base. And on the customer side, there was also a lot of frustration that we hadn't really put out major features in a long time and our product had somewhat stagnated.

                         

All of that led to us realizing that we needed to do something big, but there were so many things in our way that we wanted to deal with. That's kind of what led to the origin of our project.

 

Poornima Vijayashanker: Can you give us a timeline, like roughly when did that start?

 

Lisa Doan:  I think as a team we started to recognize about a year ago that something big needed to happen. It's just been a gradual process since then.

 

Signs That The Product Needs To Change

 

Poornima Vijayashanker: Looking back, can you point to maybe a cause or several causes that led to the product starting to decline?

 

Lisa Doan:  Sure. The product was actually born out of an internal team. Pivotal itself started as a consultancy. Back in 2006, there wasn't a great backlog management tool, and so the engineers built one that suited their needs. But because of that, Tracker was always a bit of an accidental product. We built it for our own needs. But, clients would then ask to take it home after engagements and then it just grew virally there.

                         

Because of this, we never really had a clear mission or vision. It was just something that we built that we had a problem and then we solved for. That over time became a problem because we added all these different customers, but they had varying problems and we didn't have anything to pin our work too. We didn't have a strong opinion on which direction we should take the product so that led to lots of different features that were kind of scattered in how they addressed user problem.

 

Why Choose NOT To Redesign Or Rebuild A Product

 

Poornima Vijayashanker: I know in the next episode we're going to talk a lot about how you changed your engineering and your product team's whole process, so we'll pause on that. What I want to talk about now is why you decided against redesigning and rebuilding Pivotal Tracker.

 

Lisa Doan:  In maybe October of last year, as a group we had finally realized that we were at this point that we needed to make a big call on something and the initial thought was like, yeah, let's just rebuild. it's just so much easier, the code base is so challenging. No one wants to work in it anymore. Because it was an accidental product, there was never a strong architectural vision so it was all sorts of different tech stacks everywhere.

                         

So, we decided that we were going to have this team go out and they would re-envision Tracker. We even called it Tracker, but Better. Really quickly we realized that wasn't such a great idea. Tracker was built for a specific problem, which is backlog management. That was the problem in 2006.

                         

But here in 2018, the problems are different. There are lots of different backlog management tools that any team can choose and tailored to their specific needs, and Tracker has kind of falling behind on some of those things. At the same time, the problem that all of our customers have is around knowing what to build.

                         

Teams now know how to build software pretty well and there are lots of tools they can choose from, but how do they choose the right product to build? Tracker doesn't solve for that in any way at all.

 

Two Paths: Maintaining The Existing Product And Building A Brand New One

 

Poornima Vijayashanker: So, you make the decision that you're going to build a new product, and the Pivotal Tracker team is going to continue building that because there are two different needs, kind of two different missions and visions. Let's dive into what happens next with the new product.

 

Lisa Doan:  One of the goals for our team was to go back and reconnect and realign with a larger organization. Tracker kind of had its own destiny within Pivotal, and we wanted to make sure that both Tracker and whatever initiative we started with our team were more aligned with Pivotal. One thing we did is, we went back and talked to our leadership and we talk to other users within the organization to make sure that we were following their pain and solving the right problems for them, whether it's within Tracker or within your products.

 

Poornima Vijayashanker: You're at a point now where Tracker is continuing to be built by a team. You form a new team to discover what this new product is going to have in it.

 

Lisa Doan:  Sure.

 

Identifying THE Problem To Solve

 

Poornima Vijayashanker: So, what are some next steps?

 

Lisa Doan:  From Tracker, we knew there was a big space of problems that our users were dealing with, and so we wanted to really dig into that. Another goal that we had was bringing our team closer to the Pivotal Organization. Overtime, Tracker had sort of become a silo on its own, so part of our team's goal was to reconnect with the broader organization and make sure our product is aligned with that.

                         

So we went out and talked to various stakeholders. We talked to the CEO, we talked to the leadership in cloud and R&D and understood where they think the business is going and how we could support that. We had to rebuild a lot of those bridges, but it's been extremely valuable because they provide us input that we didn't have previously that helps guide us in terms of the decisions we make when we're building this new product.

 

Poornima Vijayashanker: What became the focus of this new product?

 

Vera Reynolds: To get a little meta, we've been using Tracker to develop Tracker. It's a great tool, and it allows teams to go fast. However, what it doesn't help with his direction. One thing we've noticed is that we as a larger Tracker team have been going fast for a while, but we've been struggling with direction. That's the problem space we're trying to solve with the new product, east to compliment Tracker in a way that allows you to find that direction and continue on it.

 

Poornima Vijayashanker: Got It. So you're now in a new problem space. Then, did you start getting your hands dirty? Did you start writing code? What's the next thing that you did after that after you defined the problem space?

 

What To Do Before Coding And Building A Brand New Product

 

Vera Reynolds: We did a lot of research. I say that kind of tongue in cheek a little bit...

 

Poornima Vijayashanker: How many months?

 

Vera Reynolds: I'm an engineer, so it was a learning experience to put it mildly.

 

Poornima Vijayashanker: How many months of research do you think you did?

 

Vera Reynolds: We did about four months. Is that right?

 

Lisa Doan:  Yeah.

 

How To Experiment Before Building And Coding

 

Poornima Vijayashanker: A lot of the time that you were doing these, were you also running experiments or something else?

 

Vera Reynolds: Yeah. We actually had a Lean startup coach that worked with us for some time. She really helped us understand those practices because there was a lot of paralysis early on. As we started exploring this new problem space, there was just so much that we, not hadn't thought of, but we hadn't seen eye to eye for a while. There was a lot of things we could solve, and you get a little bit distracted like a dog and a pavilion of squirrels or something.

                         

So, our coach really helped us develop a practice where we create experiments, like you said, we talked to users and we had really a defined assumption so we're trying to debunk, or prove. We did about 30, I think, experiments before we started building. So, we took it really serious.

 

Poornima Vijayashanker: Wow, 30 experiments. What did these look like?

 

Lisa Doan:  There's a huge range. We did a lot of generative interviews where we just sit down and talk with customers. We've also generated prototypes, put those in front of customers and see how they interact with them. We've also done fun things like feature fakes and experiments with the existing products to get a feel for what our customers are really looking for.

 

How A Feature Fake Can Help

 

Poornima Vijayashanker: What's a feature fake?

 

Lisa Doan:  A feature fake is where you build the facade of a feature and you present it to your users as if it's a real thing, and then see how they interact with it. If they like it; and then you gather feedback around that to see whether or not they had a positive experience or if that's something they might be interested in before you actually do any of the work to build it for real.

 

Poornima Vijayashanker: After 30 experiments, I'm sure you uncovered a lot. How do you decide to whittle things down?

 

Vera Reynolds: Some of the things we've done came from Pivotal Labs like discovery, framing and inception, those are early stage meetings that help you scope your work and decide what you're going to build. You have to remember, we were still in that phase of research and we were always trying to keep each other accountable about not building things prematurely and not building too much. We use those practices and we had a meeting where we wrote just the bare minimum stories we needed to accomplish in order to have an MVP and started there.

 

How To Pare Down Customer Insights And Scope A Prototype

 

Poornima Vijayashanker: After 30 experiments, I'm sure you've got a lot of customer insight. How do you whittle that down?

 

Vera Reynolds: As part of every experiment, we wanted to end on a headline or major learnings and pain points that our users needed to be fixed. That kind of gave us a list that we could start with. We started there and wrote down features. We actually aren't continuing experimenting as we're building. We're validating prototypes and making sure we're only building the minimum things and only building what we need.

 

How To Handle Knowledge Gaps On The Team

 

Poornima Vijayashanker: Got It. Did you ever run into knowledge gaps where people on your team didn't know?

 

Vera Reynolds: Yes, yes we did.

 

Lisa Doan:  So many knowledge gaps.

 

Vera Reynolds: Pivotal Tracker is a very engineer-centric team. For better or worse, and I think there are strong engineer practices, but I've never had done user research until this team so there was a lot of knowledge gaps there for sure. For me as an engineer, and I'm sure Lisa can agree as well with Lean practices and experimenting fast and focused learning, things like that.

 

How To Assemble A Team To Build A New Product

 

Poornima Vijayashanker: Got It. How did you go about assembling your team together because I know like you said, you had your Tracker team and then there was a new team together. How did that come about?

 

Lisa Doan:  Where we were in the beginning of the years is, we were still believing that we were going to rebuild Tracker at the time. And so, moving forward with a new product we knew we needed people on the team who were willing to step out of their roles a little bit. We knew we had to step into this big body of research. We also had so many engineers on the Tracker team that we also wanted to keep involved in and teach some of the practices.

                         

So, we added engineers on our team in addition to myself and a designer. Engineers who are very empathetic, who care a lot about building features that users care about and love. That was something we definitely look for when we were adding people to our team.

 

Poornima Vijayashanker: Let's talk about how you assembled your team because you mentioned there was the Tracker team and now you have a new team for a new product.

 

Characteristics To Look For In Teammates

 

Lisa Doan:  We were pulling from the original a Tracker team. But going into the new product, we knew there was a huge body of research that had to be undertaken. So when we were assembling the team, we were looking for people who are extremely empathetic and could really dig into...Would be willing to adopt some of the skills that we were lacking on the team. Things like user research, talking to customers. So, we looked for engineers, testers, designers and PMs who were very focused on understanding the user's problems and then trying to iterate our way towards a product for those people.

 

Poornima Vijayashanker: To recap, you have a conversation at the beginning of last year or some point last year where you decide you're going to build a new product, you go out dialing to stakeholders, and then from there you decided, OK, we're going to assemble a team, fill in knowledge gaps. What happens after all of that? You start building?

 

Vera Reynolds: Eventually. Like I said, it took about 30 experiments to get to the point where we started building, but it was a happy day. It was a happy day on the team. We started building around June, and we have just recently began rolling out our MVP. So, it's a pretty exciting time.

 

The Importance Of Having A Mission And Vision

 

Lisa Doan:  One major thing that we haven't talked about yet that was critical to our success so far is that we had to come up with a mission and vision. Prior to having that, we were just sent out into the world with this idea of we're going to re-envision Tracker, but that's so broad. That's such a huge space. Tracker has 100,000 users and they're all across the board. They could be just a small startup team, it could be multiple enterprise teams that are using this product.

                         

So, it was extremely difficult to know where to start. And because of that, we ended up in a place of paralysis because it's like, do we attack this problem, that problem? Who knows? We ended up spinning for a while, so when our innovation coach arrived, that's the first thing she noticed. The first thing she went about doing is getting us to agree on a mission and vision.

                         

That was really a huge turning point for us because whenever we can make a decision, we would bounce it against that and ask, is this in service of our mission? If not, then we would have to readdress it, otherwise we felt comfortable moving forward. That really started the ball rolling, is just having something to point at and agree on that this is what we're choosing to focus on.

 

Why Software  Engineers Need To Be Involved In Tasks Aside From Coding

 

Poornima Vijayashanker: Was there anything else that you you needed to do before you could start actually coding?

 

Vera Reynolds: I think the important part was to not head down into coding and not come up for air. We are trying to keep engineers involved in research, continue to spin a that track and not go off and just build. I think that's the most important thing to remember for us now.

 

Poornima Vijayashanker: Is there anything else that you did before you dug into building and writing code?

 

Vera Reynolds: Not really, that was about it. However, we were all trying to remind each other to be mindful of not go on the rails of building and start going fast as we did previously on Tracker, and really be mindful of that user-centric value.

 

Poornima Vijayashanker: I know we're going to share a lot of these best practices in the next episode, so I'm going to end it here. Thank you both for coming and sharing how you decided to go and build this new product instead of doing a rebuild or redesign.

 

Vera Reynolds: Thanks for having us.

 

Lisa Doan:  Yeah, thank you.

 

Poornima Vijayashanker: Now I want to know, are you thinking about doing a rebuild, redesign, or maybe building a brand new product? If so, what's been your approach? Let me 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're going to go into more detail around how to keep a new product on track. Ciao for now!

Oct 9, 2018

In last week's Build episode, we talked about why if somebody doesn't understand your explanation for a technical concept, it's not OK to just tell them to look it up or Google it. We also covered the effects of doing this, the main one being that you don’t come off as someone who is credible!

 

In today's episode, we're going to dive into the specific tactics for how you can explain abstract technical concepts to an audience of either lay people or one that may be a little bit more advanced.

 

Anne Janzer is back to help us out. Anne is a prolific author and recently published Writing To Be Understood: What Works and Why.

 

Here’s what you’ll learn as you listen to today’s episode:

  • What things we need to take extra time to explain
  • How to gauge your audience’s level
  • How to handle mixed audiences and explain in a way that is inclusive
  • How to avoid “dumbing down” an explanation
  • Why writing out an explanation is harder than sharing it verbally
  • How to pick analogies that are going to resonate with your audience
  • Which contexts to apply these techniques to

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

# 3 Techniques To Improve Your Explanations And Be Understood Transcript

 

Poornima Vijayashanker:           In the previous episode of Build, we talked about why if somebody doesn't understand your explanation for a technical concept, it's not okay to just tell them to look it up or Google it, and if you missed the episode and the reasons why it's important for you to explain, then I've included a link to it below. In today's episode, we're going to dive into the specific tactics for how you can explain abstract technical concepts to an audience of either lay people or one that may be a little bit more advanced. So, stay tuned.

 

Poornima Vijayashanker:           (pause)

 

Poornima Vijayashanker:           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, we've been talking about the importance of breaking down abstract technical concepts as the person explaining them. In the last episode, we uncovered why it's important as the explainer to take the time to explain things in a way that your audience is going to understand.

 

In today's episode, we're going to dive a little bit deeper to give you specific tactics that you can use the next time you're presented with having to communicate something to a teammate or to a lay audience.

 

Poornima Vijayashanker:           And to help us out, Anne Janzer is back. She is the author of a number of books that range on topics from writing to marketing, and she's kind of a cognitive science geek. So, thanks again for joining us today, Anne.

 

Anne Janzer:        Thanks for having me back.

 

Poornima Vijayashanker:           Yeah. So, I know in your upcoming book, you've got a range of techniques, and I want to kind of tease out just a few for our audience, and I know it focuses on writing, but I'm sure a lot of these techniques apply in a number of contexts. Maybe you can share with our audience some of the contexts that you think these techniques could apply to.

 

Anne Janzer:        Really, yes, I think they apply any time you've got to communicate about a complicated topic to someone who doesn't share the same background you have on that topic. So, it can be whether you're writing an email to somebody or presenting to investors, maybe trying to explain to your family what the heck it is you do for a living.

 

Poornima Vijayashanker:           Yeah.

 

Anne Janzer:        That can be a challenge if you work in tech, I know. There's all sorts of things, and it certainly applies to ... most of this applies to writing as well as speaking. The challenge with writing that's different than speaking is that when we're speaking, I have my body language, I have my voice, and I can see if you're checking out, checking your mail, or confused.

 

Poornima Vijayashanker:           Right.

 

Why writing out an explanation is harder than sharing it verbally

 

Anne Janzer:        It's very obvious, and when I'm writing, the reader's not present when I write, and the writer's not present when they read. So, everything's just on the paper. So, you have to work harder to really advocate for the reader as you are doing the work of planning and writing and revising so that it really, you can be almost present with them.

 

Poornima Vijayashanker:           So, let's talk about the things that we need to take extra time to explain.

 

Anne Janzer:        Right, so, here's the main thing. It's abstract topics.

 

Poornima Vijayashanker:           Mm-hmm (affirmative).

 

Anne Janzer:        Technology is itself just layers of abstraction, right, and you work in this silo of abstraction, and that person works in that silo of abstraction. Maybe I know storage, and you know Cloud infrastructure, right? They're really related things, but they're different things, and when people are faced with abstract ideas, this is part of human reasoning. We are animals that abstract things.

 

Anne Janzer:        There's a couch, and there's a table, and they're both furniture. Now, everybody's comfortable if I talked about furniture, you know what I'm talking about, but when it gets to technology, you can get to the point where people aren't comfortable with that, and so what we need to do is try to figure out a way how to take something that is abstract and sometimes intangible. It's just an idea, and make it concrete so that people can understand it.

 

What things we need to take extra time to explain

 

Poornima Vijayashanker:           Now, what are the specific things that we need to take extra time to explain?

 

Anne Janzer:        So, when we work in the tech industry, we're dealing with abstract ideas all the time, abstractions, and it's just layers and layers and layers and abstractions, and so we come up with a lot of words and terms and jargon that is short hand, and it's absolutely essential for us to communicate with each other, right, but it's not always essential for us to communicate with someone outside of our field.

 

Poornima Vijayashanker:           Mm-hmm (affirmative).

 

Anne Janzer:        And that is often the biggest barrier for people understanding what we're talking about when we're talking about technology, is the words that we use, the jargon and the abstractions that we use. So, that is the thing that the very low hanging fruit to take care of when you're writing or speaking, is what abstractions and what jargon am I using that could cause problems?

 

Poornima Vijayashanker:           Yeah. I've also noticed for a lot of my students and audience that they may have something that's internal to their company. So, yeah, sure something like HTML, okay, we get that that's an abstraction because of the acronym. It's kind of buzz wordy, but then they have something internal where they say, oh, we use this thing called an OKR, and they just assume everybody in their company knows it. Somebody on the outside's like, OKR, what is that, right?

 

Anne Janzer:        Right.

 

Poornima Vijayashanker:           Yeah, so how can we kind of figure out what things we may think are specific to our organization or even our team, are not necessarily commonplace.

 

Anne Janzer:        Yeah, so you have to get a little loose. I like to print out what I've written, and maybe highlight anything that is term, an abstraction, maybe anything that is abbreviated, capitalized, acronyms. You know what they are.

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        And for each of them, you need to ask two questions. Is it maybe, is it possibly unfamiliar to my audience, and is it necessary? So, if it's necessary to use it, the only way to talk about it, or everybody talks about blockchain is blockchain, right? Okay, I had to use the word blockchain. There's a law, right?

 

Poornima Vijayashanker:           Yeah.

 

Anne Janzer:        I have to use it. If it's necessary to use it, but it might be unfamiliar, then it is on you to define it or show an example the first time you use it, or use it in such a clear context that there's no confusion. If it's unnecessary and unfamiliar, if there's another way to use it, get rid of it. You're just adding unnecessary cognitive load to the reader.

 

Anne Janzer:        So, necessary or unnecessary, familiar or unfamiliar. I mean, you don't have to strip out furniture. You know, you don't have to strip out acronyms or things that people really should all know who are in your audience, but you do need to be anything that, yeah, maybe they know it, but maybe they haven't encountered it that many times.

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        So, they're going to have to do a little bit of extra work to fill in the blanks while they're listening to you or reading.

 

Poornima Vijayashanker:           So, is there a way we can gauge the audience level, because I know a lot of times people assume, well, I'm talking about this new framework, this new technology, and it's in the title of my talk. This conference is about this talk. So, I just assume everyone coming here is going to know what this is. Why do I really need to take an extra 30 seconds, one minute, PowerPoint slide, et cetera to explain this? Won't it seem like I'm "dumbing it down" for them?

 

How to avoid “dumbing down” an explanation

 

Anne Janzer:        Yeah, right. I think you don't want to dumb down for people. You want to respect their intelligence, but you also have to remember someone at the conference just came out of three other sessions. Someone picking up your article may be like, wait. Why do I want to read this? It's in the title. I forgot. I mean, people come from very interruptive and context changing day, and you need to help them reset even if you think that everybody coming is showing up for that reason. They may not be. They may be showing up for other reasons as well.

 

Anne Janzer:        So, it's always worth trying to put yourself in the audience shoes for a moment, and say let's say I'm new to this industry, and I'm showing up here to learn. What should I assume the people ... what that person might know? What if you were on your second week of your job, and you show up at your talk, or you pick up your article? You want to help that person as well as the next one, right? You want to help your audience. You should be doing this to try to be understood, and you would like to be understood by them.

 

Poornima Vijayashanker:           Yeah, or that person that got dragged to the talk, because hey, your buddy was like, this is going to be an amazing talk. I know the speaker, but you're like I don't know what this thing is.

 

Anne Janzer:        Yep. Yep. If all goes well, you'll be one of the speakers that people go to hear your talk even if they don't know what your subject is about, because you're so awesome as a speaker.

 

How to gauge your audience’s level

 

Poornima Vijayashanker:           So, how do we know who's going to show up, or how can we gauge the audience level before we write our post, our book, or give our talk?

 

Anne Janzer:        I think we have to try to put ourselves in the seat of the audience, the mind of the audience. Try to figure out who the people might be, and answer these three questions about them. What do they already know? Where are they coming from? And give them a little range. Don't assume everybody is at the top of the knowledge range there.

 

So, what do they already know? How do they feel about the topic? Are they there under duress? Are they there, because they're really fascinated by it, because they think it's a hot investment opportunity? I mean, there's a lot of different things that could be motivating people to learn about your topic, and it's interesting to know what they are. And what makes them curious? How can you engage their curiosity, and bring them in to learn more about what you're trying to explain? Because when someone's curious, they're going to be paying more attention. They're going to be coming with you as you explain your thing with them.

 

Poornima Vijayashanker:           Yeah.

 

Anne Janzer:        So, you have to give them a reason to be paying attention.

 

How to handle mixed audiences and explain in a way that is inclusive

 

Poornima Vijayashanker:           Sometimes we're in a mixed audience, though, where our teammates are there, some stakeholders, it's internal, or we're in an external conference or an event where there's people of varying levels. We don't necessarily want to bore the people who already know what we're saying, and we also don't want to talk down to the people who are beginners. So, how can we explain in a way that is inclusive?

 

Anne Janzer:        Yes, that's a challenge, and it's something that you're going to have to play with and balance, but I think it's important to remember that nobody gets upset if you quickly define a term the first time you use it, and you can also use to guide people who are different ranges, by using an interesting example.

 

Anne Janzer:        So, the people already know it find value from the example. People who don't know it, learned it, hear what you're saying. So, if you're talking about artificial intelligence and recommendation algorithms, right? Most of your audience may know what that means, but a few may be just like ... and then so you can say, you know, like when Netflix recommends, or the other day I went on Netflix, and I got a recommendation to check out this story. Now, you've anchored it in something that is an experience that everybody has. You've level set the people who weren't so familiar with that term. You've brought them right back up, and you haven't really bored the people who do know what it is.

 

Anne Janzer:        It's doesn't take a heavy lecturey touch to do this. You can do it through an example, through a story.

 

Poornima Vijayashanker:           So, I think that brings us to the first tactic. Let's dive right in.

 

Technique #1: Why using analogies or metaphors helps people understand your technical explanation

 

Anne Janzer:        Great. So, one of the first ways to explain technical concepts, this is something that you probably do instinctively all the time, which is to use an analogy. In fact, tech is just filled with metaphors and analogies. Like I said, we have files and folders, and we have, which there's no real folders on your computer.

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        There is not little folder. It's an icon, but it's an analogy that we're working with. So, metaphors, analogies, they can serve two things, actually. One is they can help explain what's happening or give us a useful way to engage with stuff that is amorphous, and two, they can actually connect on a different level.

 

Anne Janzer:        So, I found this metaphor the other day about, or analogy, about using units. It's kind of like driving a stick shift car, right? So, it gives you more power, more control, but learning it can be kind of uncomfortable, and it takes a little while. So, now if you've ever driven a stick shift car-

 

Poornima Vijayashanker:           I have, and I burned the clutch.

 

Anne Janzer:        You've learned, or your burned a clutch, right. So, when I used that analogy, we had a shared experience, and you're like, okay that makes sense to Unix, right?

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        That's interesting, but you also, the part of you that's listening to it probably, I did this thing with my hand, right? I have a physical memory of driving a stick shift. I have a physical memory of learning and the rabbit, the jumping thing that you do when you're like burning a clutch.

 

So, if you were listening to me or if you were reading those words even, the little parts of your brain that are involved with the physical memories or the visual memories of seeing something, those parts of your brain fired. Metaphor actually connects on a way beyond just our reasoning, thinking mind. People in functional MRI's, they show if they read a story, the action part, so their brains are actually firing as if they're doing the thing that they're reading about.

 

Anne Janzer:        So, our brains are not really ... we know rationally what's metaphor, but we also sort of connect on a different level. Now, if that happened while you're talking about Unix, that's a win, right? You're now more engaged. It's a little bit interesting to you, right? You've gotten the meaning, but you've also just become a little bit more interested in sticking with the experience of reading or listening.

 

How to pick analogies that are going to resonate with your audience

 

Poornima Vijayashanker:           Right, but I've also seen that backfire sometimes where you pick a metaphor, or you pick an example that you think the audience is going to get. Let's just call a spade a spade, and say there's a lot of sports analogies out there that get used, and the person on the receiving end's like, I don't know the first thing about baseball.

 

Anne Janzer:        Yeah, or that's like the 11th inning. It's like no.

 

Poornima Vijayashanker:           Or do you mean cricket? Yeah.

 

Anne Janzer:        Exactly.

 

Poornima Vijayashanker:           So, how do we know that our example or our metaphor that we choose is going to be universal?

 

Anne Janzer:        Yeah.

 

Poornima Vijayashanker:           How can we kind of test it out?

 

Anne Janzer:        Yeah. Testing it is exactly the thing. I mean, the analogies work if there's a shared experience. Sometimes you can have an analogy that isn't a shared experience. I think about the book, The Black Swan, or use The Black Swan, the story of the black swan as an analogy for an unanticipated risk. Something we assumed we didn't exist, because we didn't see it, right?

 

Anne Janzer:        That has to be explained. So, sometimes analogies are great, but it needs to be explained, but most of the time we want our metaphors to teach, not to need a lot of teaching.

 

Poornima Vijayashanker:           Sure.

 

Anne Janzer:        So, we need to understand the audience. We need to be empathetic and understand where they're coming from, and give a little explanation if we suspect there are cultural differences.

 

Poornima Vijayashanker:           Mm-hmm (affirmative).

 

Anne Janzer:        And be aware, too, that metaphors, because they activate those other parts of our brain, if you use a metaphor of a clown, and your audience is people that have that clown phobia thing.

 

Poornima Vijayashanker:           That's true.

 

Anne Janzer:        Do you know what I mean?

 

Poornima Vijayashanker:           It might activate the wrong part.

 

Anne Janzer:        You can activate the wrong things. Metaphors are powerful, and they can go in unexpected directions. So, be careful, especially across cultural. Working in tech is so multicultural. We need to be quite cautious with the metaphors that we use.

 

Technique #2: How storytelling helps an audience understand your explanation

 

Poornima Vijayashanker:           And what about the second tactic?

 

Anne Janzer:        The second tactic is, again, what we're trying to do is make something that is abstract more real to the reader, to the listener, and one of the best ways to do that is through story.

 

Now, I was an English major in college, and when I was in freshman year, a couple of my friends took a creative writing class. They were also English majors, and I saw them terrified. Every time they had to turn in a story, they'd pull all nighters, and I said to myself, oh my God. Storytelling is scary. It's stressful, and it makes you stay up all night. I am not doing any of that. Forget it. I'm a nonfiction writer. I'll be a literature major, and I'll go into technical writing, because there's no story involved.

 

Anne Janzer:        Well, so, years later of course, I was wrong. The best writers, when I read these books, I tell you the writers I admire who write about cognitive science, they use story incredibly effectively. They are not fiction writers. Story doesn't mean fiction.

 

Anne Janzer:        So, using story is a great way to connect with people, and it's something that we all need to do. Like I just shared with you a story about my personal transformation through that story. It's not that hard. I'm not a master storyteller. I didn't follow a three act structure. I didn't have rising and declining. I mean, you can do all that.

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        But a story can be very simple. It could be a moment of time when you realized something. It could be a certain situation. The best advice, for me, I had to shed my preconceptions about storytelling and just try something very simple. Just experiment with it, and gradually get a little bit more confidence.

 

How short stories can help get your point across

 

Poornima Vijayashanker:           I've noticed that especially with folks who are very technical, that I do a lot of public speaking coaching with, they have an aversion to starting with a story, because their preconceived notion is, oh, it's going to be long winded. The audience is going to tune out, pull out their laptop, cell phone, whatever, and is this really necessary?

 

Why can't I just cut to the chase and say today I'm going to talk about a distributed denial of service attack? Right? Yeah, okay, you kind of like cut to the chase.

 

People get it, but it's so much more compelling if you were to say, six months ago, we were under attack. We were facing a distributed denial of service attack.

 

Anne Janzer:        Yeah.

 

Poornima Vijayashanker:           And then all of a sudden, the audience is like, what's that? That sounds terrible, right? And it's just a very simple switch.

 

Anne Janzer:        Yeah.

 

Poornima Vijayashanker:           Like you said, it doesn't have to be long winded. So, how can we help our audience understand that when you're presenting a story, it doesn't have to be a poem. It doesn't have to be 400 pages. It can be pithy.

 

Anne Janzer:        Right, I mean, there are stories all around you. Any time you take an abstract technology and you look at a human interaction with it, there's a potential for a story.

 

Poornima Vijayashanker:           And use case.

 

Anne Janzer:        I mean, a use case is a story.

 

Poornima Vijayashanker:           Yeah.

 

When to NOT tell a story

 

Anne Janzer:        And actually, it's more interesting the more...not a ten page use case. God, no. Just a little short blip of this person using this to do this. It can be a story. It doesn't have to be...it shouldn't be a long thing. And don't give someone a story when they're asking for data. That drives me nuts.

 

Anne Janzer:        It's like you go up and say, what happened to the sales last year? Let me tell you a story. Oh, God, don't do that.

 

Poornima Vijayashanker:           Yeah.

 

Anne Janzer:        I mean, a story has its role.

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        It's not something that you should be overwhelming people with, but it's a really powerful tool for either engaging their interest, engaging their curiosity, or explaining something, because they come along with you as they understand it.

 

Poornima Vijayashanker:           Yeah. So, you could say something like oh, the conversion rate went up 75%, or went down 75%. You want to know more? Happy to give you the details.

 

Anne Janzer:        Yeah. Yeah, exactly.

 

How being brief helps you build credibility

 

Poornima Vijayashanker:           Nice. So, in the previous episode, we touched upon this desire to be long winded, and you mentioned how people often do it, because they want to come off as being credible. They worry, oh my gosh. If I take my 500 word bio and cut it down to 100, someone will miss something. They won't know that I wrote 200 books, or that I met with the Dalai Lama, and that's really important for being able to speak on Bitcoin. Right? So, how can we help our audience realize that it's okay to be brief, and it's not going to cost us our credibility?

 

Anne Janzer:        Right. Yeah, it's not going to cost you your credibility, and in fact, it's probably going to increase your credibility. People, again, credibility is based on being understood, and when we include too much, people perceive it that we're busy talking about us, and our needs, and not focusing on the reader's needs.

 

Anne Janzer:        So, if you are talking about Bitcoin, and you're an expert on Bitcoin, then just craft a bio about Bitcoin. I mean, people can link and find out more about you-

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        ...if they are so interested. Get them curious about you to find out more. That's awesome, but don't throw out everything at them in the bio, and put some of that stuff in your bio as opposed to in the body of your talk. You don't have to be, first let me tell you about my five startups or something, right?

 

Poornima Vijayashanker:           Yeah.

 

Anne Janzer:        I mean, people can look this up. You want to get them curious enough to look up the stuff rather than you feeding it to them, because if you think about everybody. We have so much stuff. I think that we're all reading less and less online. So, if you show up with 50 really great words, people will read them. If they see a block of 300 words, they're going to skip the whole thing.

 

Poornima Vijayashanker:           Yeah.

 

Anne Janzer:        I mean, if you want to be effective, be brief. Be concise, and give the reader what they're looking for rather than what you feel you need to be saying.

 

Poornima Vijayashanker:           Yeah. So, it's all about that topicality. What is it that the crux of the subject is, and how does your bio, your credibility fit into that?

 

Anne Janzer:        Absolutely, and you will be credible if you show up and give them useful stuff. That's going to be important.

 

Poornima Vijayashanker:           Yeah. So, what's the final tactic?

 

Technique #3: How tone and style impact an audience’s understanding

 

Anne Janzer:        So, the final tactic is to think about the tone and style that you're writing in or speaking in. Now, tone is kind of like brand. It's not something that you assert. It's something that other people interpret, right?

 

Poornima Vijayashanker:           Right.

 

Anne Janzer:        So, right?

 

Poornima Vijayashanker:           Yeah, that makes it really hard.

 

Anne Janzer:        It makes it hard. It makes it hard. That's why you actually have to get out and test your stuff. You have to test your writing. You have to test your speaking. You may think that you're showing up one way, and people may be interpreting it another.

 

Anne Janzer:        In speaking, we've got things to do, and you are expert in that to show up with a different tone, a different persona. In writing, all you've got is your words.

 

Poornima Vijayashanker:           Mm-hmm.

 

Anne Janzer:        So, there's some leverage that you can use in looking at, we've talked about them already, abstractions, the jargon. That has a huge impact on the tone of the written piece.

 

Poornima Vijayashanker:           Mm-hmm.

 

Anne Janzer:        So, going through and stripping out unnecessary abstraction, stripping out unnecessary words, actually makes the piece stronger. Sometimes when we add words like very and really, it weakens our prose, which is crazy. So, I mean—

 

Poornima Vijayashanker:           Qualifier words.

 

Anne Janzer:        Qualifier words just go through and cut them out in revision. Make your thing stronger by being more to the point and quick. The sentence length, you know, sentences don't have to go on for pages and pages. Short sentences. Not the way we speak, because obviously I ramble when I speak, but when I write, my sentences are short and to the point.

 

How to iterate and find your personal style

 

Poornima Vijayashanker:           Yeah. Well, these are all great tactics. Now, I know it's going to be a challenge, and it's going to take some work, some iterations. The first time we try some of these tactics, we may fall flat. So, how can we go about iterating?

 

Anne Janzer:        So, yeah, you're going to need to find your personal balance for what feels comfortable for you, works with the subject, and meets the audience needs, and that balance may change with everything you do, every talk you give, every blog post you write may be a little bit different. Well, hopefully not every blog post, but you're going to find your personal style and tone, and you're going to have to test things out.

 

The other thing to remember, even while we talk about brevity, is repetition, that people don't necessarily catch things the first time it goes past. In fact, they rarely catch things the first time it goes past.

 

Anne Janzer:        So, if you can find a way to repeat, iterate within your talk, or iterate within your article, by repeating your message in a slightly different way, a different example. Eventually it's going to sink in and have an effect. So, you may hit these readers with this thing, and these readers with a second occurrence, and these readers with a third occurrence when it's expressed in a slightly different way.

 

Poornima Vijayashanker:           Yeah. Well, thank you so much, Anne. This has been really helpful. I know our audience out there is going to get a lot of value, and will hopefully start to employ these tactics as they have to—

 

Anne Janzer:        I hope so.

 

Poornima Vijayashanker:           ...communicate those difficult technical concepts, whether it's inside their organization or outside.

 

Anne Janzer:        I certainly hope so. Yeah.

 

Poornima Vijayashanker:           Yeah. So, how can our audience get in touch with you?

 

Anne Janzer:        So, my website is my name. Anne with a silent E, Janzer, and you can find information there about the book, Understood, which is on Amazon and hopefully all the other places that you would buy books. We'll see. And also I have a regular blog about writing. You can sign up for that there, and I'd be happy if anyone had any questions, wanted to reach out to me. I'd be happy to hear from you.

 

Poornima Vijayashanker:           Yeah, wonderful. Well, we'll be sure to include the links below the video and in the show notes.

 

Anne Janzer:        Great, thanks.

 

Poornima Vijayashanker:           That's it for this week's episode of *Build*. Be sure to share this episode with your friends, your teammates, and your boss, and be sure to subscribe to our YouTube channel to receive more episodes of *Build*. Ciao for now.

 

Oct 3, 2018

Confession time…

 

A few years ago when someone asked me to explain a technical concept and I couldn’t successfully get through to them or didn’t have time, I would send them this link. ;)

 

And it seemed funny the first couple of times I did it.

 

It wasn’t until someone did it to me that I realized how obnoxious it was. I eventually stopped asking for them for help, because I knew they weren’t very good at explaining things and didn’t have the patience to help me.

 

I also realized that I didn’t want to be like them. I needed to get better at explaining technical concepts. Ever since then, I’ve been on a quest to improve how I communicate technical concepts when I write and speak to people and audiences of varying levels.

 

Part of my discovery led to me Anne Janzer. Anne is a prolific author who has recently written a book called Writing To Be Understood: What Works And Why, and she’s also a cognitive science geek!

 

I sat down with Anne to debunk the misconception that if someone doesn’t understand a technical concept immediately, then it’s their fault. They're too much of a layperson, and they should look it up. But it’s actually the explainer who needs to do a better job of explaining, and in today’s *Build* episode, we’ll explain why!

 

In next week’s episode, we'll provide techniques on how you can get better at explaining technical concepts to a mixed audience or to a layperson.

 

As you listen today’s episode, you’ll learn the following:

 

  • Why people on the receiving end of an explanation find the explainer to be less smart if the explanation cannot be easily understood
  • Why people are bad at explaining technical concepts using simple language
  • Why we assume our audience knows what we’re talking about
  • Why people may not get our explanation
  • The three questions to ask yourself about your audience before you communicate with them
  • Why we have a tendency to overexplain
  • Why overexplaining isn’t helpful either and being brief is better

 

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## Why Doing a Bad Job of Explaining Technical Concepts Hurts Our Credibility Transcript

 

Poornima Vijayashanker:  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 huge misconception that we all face is that when we're trying to explain a technical concept, if someone doesn't immediately get it, we think, you know what, it's their fault. They're too much of a layperson, and we advise them to just look it up. Turns out, the person who's explaining the technical concept, it's actually their fault for not explaining it.

 

I know that might seem counterintuitive, but in today's episode, we're going to explain why the onus falls on the explainer and in a future episode, we'll give you some techniques on how you can get better at explaining technical concepts to a mixed audience or to a lay person. And to help us out, I've invited Anne Janzer, who is the author of a number of books ranging from writing to marketing and she's kind of a cognitive science geek. Thanks for joining us today, Anne.

 

Anne Janzer:    Thanks for having me Poornima. I'm happy to be here.

 

Poornima Vijayashanker:   So you've got a new book coming out and it's all about explaining technical concepts and being understood. Maybe you can dive into the origin story for what inspired you to write this book.

 

Anne Janzer:    Sure. So, the title of the book is *Understood*. So it's about writing to be understood and it came from two things in my life. One, is that I spent a lot of my time in the technical industry as a freelance marketing writer working for dozens and dozens of different companies trying to explain these really geeky technologies to a business audience. So that's familiar to most of the viewers.

 

But second, I also, as you said, I'm a bit of cognitive science geek so I love to read all these books about the brain and psychology and behavior and behavioral economics. You notice that some authors are really good at explaining this stuff. And you think, so there's parallels between what they do and what I was doing, which is explaining complicated, abstract topics. So are some people just like born better at this? I don't think so.

 

I took a close look at what these writers do, now I've called up and talked to some of them about what they do which is great. It turns out that there are just methods and techniques and approaches that we can all use to become better at being understood when we're talking about something to people who don't share our knowledge about it.

 

Poornima Vijayashanker:   So it's great that there all these experts who understand why this is important, but for our audience out there, they're not sure why this is important. We can dive into that in a little more detail.

 

Why people on the receiving end of an explanation find the explainer to be less smart if the explanation cannot be easily understood

 

Anne Janzer:    Yes. So you may not feel like…you may feel, well, I'm the expert. It's not on me to make sure that everybody understands. It's not my problem basically, if I'm explaining it. But it is your problem. It really is and the cognitive science shows that.

 

When you explain something that's complicated and you use words or terms or even writing techniques that they don't understand, you are giving the audience extra cognitive load. You're making them do extra work, not to understand the thing that you're saying, but even to get through to the thing that you're trying to explain to them.

 

Research shows that when people experience cognitive load, certainly while reading, they don't assume that the writer is smarter, they actually assume that the writer is less smart. So when they don't get it, they don't think, gee, I must be stupid, they think, they're not so smart.

 

Anne Janzer:    There's a study by a guy named Daniel Oppenheimer, who's now at Carnegie Mellon, but he did this back when he was at Princeton. I have to read the name of the study because it totally illustrates what it's about. “Consequences of Erudite Vernacular Utilized Irrespective of Necessity or Problems with Using Long Words Unnecessarily.”

 

Poornima Vijayashanker:   Nice. Yeah.

 

Anne Janzer:    Which is great. And in the study they had people look at the same passage written two ways. One in a more straightforward way, one more complex using longer words or one piece sentence construction, let's say. People who read the more complicated ones rated the author as being less intelligent.

 

In one case, even when they knew that the passage was by René Descartes. They were reading translations and they're like, this is René Descartes from his meditations. They're like yeah, he's not that smart. If they read the more complicated one. So if you want to show up as being an expert you have to be understood. And it's on you. It's on you to do that.

 

Why people are bad at explaining technical concepts using simple language

 

Poornima Vijayashanker:   So why do you think people get into this habit of being long-winded or maybe using big words?

 

Anne Janzer:    I don't mean to be critical of it, because we all do it. It's a natural thing. If you work in a tech sector for a long time, you're surrounded by people who are all using these abstractions and these terms. You master the complexity of the subject. You're a part of a social group of people who have mastered that complexity. So it's natural to want to speak in a way that people around you understand, use those words.

 

But you need to remember that these abstractions that now come easily to you. Like now you can ride a bike, but a toddler can't ride a bike, looks up at the person riding the bike thinking, yeah, that looks really hard. So that's the situation. That you're really comfortable with these abstract terms, but if you're talking to people outside of your domain, outside of your area, those terms are much more difficult to operate with.

 

Why we assume our audience knows what we’re talking about

 

Poornima Vijayashanker:   So it's natural to evolve and get into this in crowd or you're surrounded by people who know. You kind of expect other people to know and then when they don't, you're kind of like, well, just Google it, right. So how can we get over this? This expectation that our audience just knows.

 

Anne Janzer:    Well, we have to remember that we suffer from the curse of knowledge, which is hard for us to remember not knowing the things that we not now know. So some of the times it's not that we're being dismissive of our audience, we're just assuming that they know the things. That these things are familiar to us are familiar to them.

 

So you really have to get outside of your own head for a moment and try to put yourself in the perspective of your audience. That's why the title of my book is Understood. It's not like, explaining, it's understood, because it doesn't matter what the words are coming out of your mouth or your pen. It matters how it sinks into the audience's mind.

 

Why we need to incite curiosity in our audience

Poornima Vijayashanker:   I don't know about you, but I definitely had a few college professors, their names will go unnamed. In their 101 class, kind of expected me to know certain things or to, again, spend the time looking it up. So how can we combat that as well?

 

Anne Janzer:    So that story drives me crazy because the purpose of a 101 class and the job of the professor of that class is to give people enough information but also to incite their curiosity so that they can learn enough to figure out if they want to pursue that field. If they want to learn more or what is useful to them from that class.

 

And in many ways, we all are in that same position as that 101 teacher. When we're talking to people who aren't familiar with our area, our job too, is not to tell them everything I know or expect them to step up to what we want to talk about. Our job is to incite their curiosity about our topic so that they'll pay attention and get something and to give them a little bit more and to lead them into it. That's a whole different way to think about explaining complicated stuff. It's not like I'm going to dump all this stuff on you you need to know. It's I'm going to pull into this topic and bit by bit get you interested in it, tell you how it applies to you and see what goes from there.

 

Why people may not get our explanation

 

Poornima Vijayashanker:   So it's good to know that we may suffer from the curse of knowledge and that not everyone is going to have a same level of expertise as us. What are some other things that may get in the way of people understanding when we communicate technical concepts to them?

 

Anne Janzer:    There's a couple things to be aware of and one is that sometimes people think they understand already and you have to work around their existing models of what's happening. People think they understand what's happening, for example, to their data when they go onto a website and use it and then go away. The data stays where they left it. Right?

 

And that's not always the case. So sometimes they think they have an understanding of something. We always talk...if you think about how do you understand using storage. How is stuff stored on your computer? You think, well, I've got a disk, maybe you think you have a directory and then I have a folder and I put files in it. That's nothing like what's really happening underneath. The file may be distributed over many areas of the disk. Some stuff is not on disk, it's in memory.

 

Poornima Vijayashanker:   It's in the cloud.

 

Anne Janzer:    It's in the cloud. You can't come up to people and say no, you don't know what's going on, you're wrong. So you need to understand what their understanding is and figure out how to work around that.

 

And then there are the topics that people, they want to cling to their understanding of it. They don't want to hear about something that disrupts their understanding of it. That's why, if you search for a swimsuit on a website and then you go to the New York Times and it's serving you an ad for that swimsuit that you just searched for. It can be really distressing, these retargeting ads, because they show us something that we don't want to hear about, which is that we're leaving this huge digital wake of data around that people can use. We find that distressing because we don't want to hear it, but it's there.

 

Poornima Vijayashanker:   So there's the concept of challenging people's current understanding and then there's a concept of ignorance is bliss.

 

Anne Janzer:    Yes, right, right.

 

3 questions to ask yourself about your audience before you communicate with them

 

Poornima Vijayashanker:   So those are both things that we need to be aware of. How can we know...because I know in the next episode we're going to dive into how to get around this. But how can we at least develop an awareness to know which camp our audience may be in?

 

Anne Janzer:    That's the key thing is to think about your audience. I think you need to answer three questions about your audience before you go to speak to them or before you write for them. It's what do they already know about the subject and this requires that you put yourself in their perspective. You may have to talk to people that are like your audience.

 

How do they feel about your subject? Do they have resistance to hearing the message? Is this something that they like talking about? Are they curious or are they showing up for your talk under duress because they have to? That's something you want to know too, right?

 

Poornima Vijayashanker:   Yeah. My boss is making me come to this.

 

Anne Janzer:    My boss is making me come to this. And the third thing is what makes them curious? What can you use to hook their interest in the topic? What going to make them want to explore more about it?

 

Why over-explaining isn’t helpful either and being brief is better

 

Poornima Vijayashanker:   Now one final thing I've noticed, especially with a lot of my students and audience members is they can be on the flip side, where it's not the case that they think they're the expert, but they feel like they really need to go down this path and be very, very long winded about an explanation instead of favoring brevity. So how would you recommend to kind of balance that?

 

Anne Janzer:    So there's two things I want to get at. One is that you need to make a careful distinction between what you want to talk about and what the audience needs to hear. There may be a small overlap and maybe you can widen that by making them more curious, but you need to respect what their needs are. And that's the hardest thing for us as writers to do.

 

When I worked on this draft, I wrote this whole section and I thought, this doesn't serve the book. I had to delete 10,000 words and just put it aside because it wasn't what the audience needed. It wasn't what the readers needed. So that's one thing.

 

Why we have a tendency to over-explain

 

And then second, I would look at the reason why they feel they need to explain everything and often I think it's an attempt to assert some kind of credibility. Credibility is such an important issue, right?

 

It's such a critical issue for speakers, for writers. But the way that we often go about asserting credibility can work against us. If you say, well, I'm going to get up and first I'm going to list off all my accomplishments so they know I'm serious. Or I'm going to just take them through every little experiment, every little process I did to get to this so they see that I worked really hard.

 

These things work against you because the root of the word credibility is believability. That's what it means. Well, to be believed you have to first be understood. So to be credible, you need to be understandable and that means you're going to have to cut out that stuff. People will respect you more, think more of you if they can really understand what you're saying. So if you were meeting their needs rather than asserting your own. So if you come at it from that way, it gives you an understanding for how to be more brief. What to cut and why to cut it.

 

Poornima Vijayashanker:   Well thank you so much, Anne, for sharing why our explanations may be convoluted and of course, why we need to do a better job at explaining them. I can't wait until our next episode where we're going to dive into a number of techniques and tactics to help our audience out there when it comes to explaining these.

 

Now Anne and I want to know, when was the last time you had to explain something that was complicated, maybe some technical jargon. Were you misunderstood? And if you were, how did you get over that misunderstanding? What were your techniques? Let us know in the comments below this video. And that's it for this episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where Anne and I are going to dive into some techniques to help you be more understood when you're explaining those technical concepts to your audience and to your teammates. Ciao for now.

Sep 23, 2018

All this month, we’ve been sharing best practices around hiring and interviewing product managers. If you checked out both episodes, you might be thinking: “This is a lot of work! How can we be sure we’ll end up with a stellar product manager, and that they won’t quit in three days or three months?”

 

We get that hiring and interviewing are just two pieces of a larger puzzle around talent management. And of course it’s not enough to just attract top talent; there’s more that needs to be done to make sure they stay motivated and productive. So to quell your concerns and help you figure it out, we’re going to do a deep dive in today’s episode around what to do after you hire a product manager. We’ll be sharing why current practices often fall short of meeting a new employee’s expectations and some alternate best practices for onboarding, training, retaining, and evaluating the performance of product managers.

 

Jeana Alayaay, Director of Internal Products and Services at Pivotal, is back this week.

 

Here’s what you’ll learn in this meaty episode:

 

  • How to onboard a new product manager and set expectations
  • Why you need to have a development plan ready for your new product manager and how to walk them through it
  • Why an annual performance review is too late to check in and provide feedback, and what to do instead
  • Why even a seasoned product manager will benefit from coaching and guidance as part of their onboarding process
  • What success metrics look like for a new product manager
  • How to evaluate your product manager’s performance in the midst of changes that are beyond their control
  • Why it’s good to set granular expectations around deliverables and milestones
  • What to do when your product manager stops performing or suddenly quits

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

# How to Train and Retain Top Product Managers Transcript 

 

Poornima Vijayashanker:        OK Jeana, we've covered a lot already. We've talked about some of the best practices when it comes to sourcing Product Managers, and then interviewing them. And, all of this before we even get into training, and retaining them. So, please tell me that we can guarantee for our audiences, we're going to find that mythical, or magical unicorn Product Manager.

 

Jeana Alayaay:      Unfortunately I don't know that they're findable. Because, I don't think unicorns are turnkey. But, I do think you can develop unicorns for your company, or your specific context.

 

Poornima Vijayashanker:        OK, but what if they leave in three days or three months? That's a lot of effort.

 

Jeana Alayaay:      Yeah, oh man. That's tough, we'll cover that. Yeah.

 

Poornima Vijayashanker:        OK, let's get to it then. 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, over the last couple episodes we've been sharing some best practices when it comes to sourcing, as well as interviewing and hiring top Product Managers. But, I'm sure you're still worried if your Product Manager is going to be the right fit, or maybe you hire them only to discover that they weren't quite a top performer as you thought they were in the interview process.

 

Poornima Vijayashanker:        Well fear not, because Jeana Alayaay is back. You'll recall, Jeana leads the Product Management, as well as Design team. We're going to share some best practices when it comes to training, as well as retaining your top performers so that they don't just up and quit. Thanks for joining us again.

 

Jeana Alayaay:      Thanks for having me again.

 

## Conversations to have with new product managers

 

Poornima Vijayashanker:        Yeah. OK, so like I said, we've taken a lot of time to kind of address the criteria for how to find candidates, and source those candidates. But then, we gotta make sure that these people are going to perform, and stick around. What do we do next?

 

Jeana Alayaay:      Yeah. So, I think the big thing is having a development plan that's shared with you and your Product Manager, right? I know that sounds a super simple common sense thing to do. But, it's amazing 'cause when we hire these top performers, we sort of expect them to just go on their merry way, cut wood and hull water. Then, one day they'll leave, right? We always think, "Oh, it's because it's more money," or whatever the case may be.

 

Poornima Vijayashanker:        Sure.

 

Jeana Alayaay:      But, often the feedback is, "I just didn't feel like I was growing." Right?

 

Poornima Vijayashanker:        Hmm, mm-hmm.

 

Jeana Alayaay:      Having that conversation at the beginning and saying, "Hey, how do you need to grow, how do you want to grow, and how can we have an actual development plan that puts you in the way of the opportunities to get you that growth?" Up front is really important.

 

Poornima Vijayashanker:        OK. What if they don't know?

 

Jeana Alayaay:      Then you're going to have to figure it out together.

 

Poornima Vijayashanker:        Mm-hmm.

 

## Don’t wait for the annual performance review to check in

 

Jeana Alayaay:      I think that obviously folks who tend to be a little bit farther in their journey tend to have a better idea. But, you always have folks who are just starting out. I think just coming up with some things initially, and then iterating your way towards it is totally fine. I think just having a lot of checkpoints there, right? I don't mean a development plan that you check in once in the annual performance review. I mean, something that you're visiting in every one on one.

 

Poornima Vijayashanker:        OK.

 

Jeana Alayaay:      That, you look at every quarter and you say, "Are we making progress against goal?"

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      With those folks who don't know, "Hey, what are we seeing, where have we gotten feedback, what are your feelings on this now that you've sort of been in the works for a while?"

 

Poornima Vijayashanker:        Yeah, so let's backtrack a little bit and just talk about onboarding.

 

Jeana Alayaay:      Yeah.

 

## How to onboard a new product manager

 

Poornima Vijayashanker:        Do you have some best practices when it comes to even onboarding a new Product Manager coming into your organization?

 

Jeana Alayaay:      Yeah. Have them spend a lot of time cross functionally at first.

 

Poornima Vijayashanker:        OK.

 

Jeana Alayaay:      Spend some time with the engineers, spend some time with the designers, spend a lot of time with leaders, those folks who, they're going to need to get alignment and decisions from.

 

Poornima Vijayashanker:        Right, mm-hmm .

 

Jeana Alayaay:      I think there's just a lot of up front networking that needs to happen, that we sort of gloss over. 'Cause we always want them to sort of jump right in.

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      And, just start doing things. But, that will get you only so far until relationships really come into play. And so, I always like to sort of invert that model and say, "Build the relationships first." The doing thing, that will happen.

 

Poornima Vijayashanker:        OK, got it. For yourself as either the Hiring Manager, or as the Manager for this new candidate.

 

Jeana Alayaay:      Yeah.

 

## Why even a seasoned product manager will benefit from coaching and guidance as part of their onboarding

 

Poornima Vijayashanker:        How do you think about coaching them, or training them?

 

Jeana Alayaay:      Yeah. I think the first thing is to come forward with really clear expectations. One of the things that I say is, I haven't seen a Product Manager who's blown my mind in less than a year.

 

Poornima Vijayashanker:        OK, yeah.

 

Jeana Alayaay:      Let me explain more of that. Even if you bring in a fairly seasoned, or senior person, right? They just don't even know the landscape, right?

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      So much of their job is moving people in the landscape. It's like, to expect them to be here when they don't even know who those people are, is the wrong expectation to set for both of you. I think saying, "Hey, I expect you to be cutting water, and hulling water in three months. At six months, I think you're going to have a good sense of what's going on. And, at a year you're really going to start to be able to make strategic moves with people."

 

Poornima Vijayashanker:        OK.

 

Jeana Alayaay:      I think that's actually a good approach.

 

## How to evaluate your product manager’s performance in the midst of changes that are beyond their control

 

Poornima Vijayashanker:        Got it, so kind of set some milestones. But, what if there are barriers? The company's goals change, or the product goals change.

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        Or, some giant customer comes in and takes up all of the priorities.

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        How do you kind of back channel that, or bring it back into their specific goals, or their career development?

 

Jeana Alayaay:      Yeah, that's a great question. I would say this sort of harkens back to what I consider to be a red flag for a Product Manager, is not asking for help. The other side of that is top performers are really great about raising their hand and saying, "I need help." Or, "I think something is changing." Right?

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      They're actually out there in the woods.

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      Sort of getting a sense of how the Earth is moving.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      So, sometimes they're the best person to say, "I think the tides are changing and we should pay attention to that." I think having, again, a lot of frequent touch points and saying, "Hey, is the roadmap changing? Should it change? Has the strategy changed? Are there things in the business that are evolving, that are going to affect us?" And, having that be a part of the regular conversation is super important.

 

Poornima Vijayashanker:        Got it.

 

Jeana Alayaay:      If we're waiting to the point that it's already changed, and we're in a fire drill mode.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      It's too late.

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      The feedback loop is too long.

 

## What to do if a product manager isn’t meeting your standards

 

Poornima Vijayashanker:        Yep. OK, so we're putting in a lot of effort to onboard, train, and consistently coach them. But for whatever reason, after they've been a product manager for you for a few months, you notice that they're just not really performing. They might have been stellar in that interview process, but something just isn't adding up.

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        What do you do?

 

Jeana Alayaay:      Yeah. I think the first thing I do is sort of turn the mirror back on myself and say, "Have I actually set expectations clear enough." Right?

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      'Cause often they just don't know what their job is. The flailing that you're seeing is them trying to figure that out, right?

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      We have this expectation that they're going to know exactly what to do-

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:     ...And, they don't. Maybe it's not you. Maybe it's somebody else in the system that has a lot of impact on their day to day work. I think the next thing is actually having a conversation about it. Are they aware of it?

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      And, can they actually give you some guidance about how to coach them, right? I think that you have folks who have a lot of self awareness. And so, saying, "Hey, I think we're struggling. What do you think is going on here?" And, seeing what they say. Then say like, "OK." If there's awareness there say like, "Why do you think it is that you're struggling? How do we get you the help that you need?" And, just having a very explicit conversation about it. I think it's totally death by a thousand cuts. Have the conversation early and often, and don't wait until it's gone on-

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:     ...And on, and on for too long.

 

## Why it’s good to set granular expectations for deliverables

 

Poornima Vijayashanker:        Yeah. I think even in the expectation setting, getting very granular. I know some organizations expect their Product Managers to do all the wire frames.

 

Jeana Alayaay:      Yep.

 

Poornima Vijayashanker:        Maybe do some consistent usability tests, and other organizations are like, "Oh no, we don't expect that from our Product Managers."

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        "That's like something a Designer does." So then, when the Product Manager doesn't deliver a very concrete thing, they're kind of like, "What are you doing?" Right?

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        But, they never conveyed, "These were some things we expected from you."

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        They just kind of conveyed the high level, "Improve our conversion rate."

 

Jeana Alayaay:      Yes.

 

Poornima Vijayashanker:        "Monetize our product. Get us out there, and get more customers." Right? I think you kind of have to have that balance of, "Here's the super granular stuff, here's the high-level stuff." And, maybe for the high-level stuff you figure out how to go out and do it. Maybe that's talking to customers.

 

Jeana Alayaay:      Yep.

 

Poornima Vijayashanker:        Maybe that's something else.

 

Jeana Alayaay:      Yeah. I think, again, keeping a really tight feedback loop on that is really important, right? Knowing that they're not sure what's going on.

 

Poornima Vijayashanker:        Sure.

 

Jeana Alayaay:      Or, you haven't gotten granular enough. Opening up that feedback channel is really important.

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      I even say, "Hey, if you're not getting the information you need from me, bang down my door."

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      "Please, early and often."

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      I think the other bit is like, that I forgot to mention, is make sure that they're shadowing a Product Manager who's already hit their stride in their work, right?

 

Poornima Vijayashanker:        OK.

 

Jeana Alayaay:      So, that they have a sense of what the day to day should look like, right?

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      Not to say that it should look exactly like that, but they know what normal is.

 

Poornima Vijayashanker:        Sure.

 

Jeana Alayaay:      You know? 'Cause it's like, how else will they know that you're supposed to do the wire frames, or you're not supposed to do the wireframes.

 

Poornima Vijayashanker:        Right, right.

 

Jeana Alayaay:      It's...you know?

 

## How onboarding and expectations differ for the very first product manager

 

Poornima Vijayashanker:        I think it can be a challenge though in a smaller organization.

 

Jeana Alayaay:      Sure.

 

Poornima Vijayashanker:        Where, this might be the first Product Manager.

 

Jeana Alayaay:      Yep.

 

Poornima Vijayashanker:        Maybe they're taking on somebody's responsibility who was the Lead Designer.

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        Or, the Chief Product Officer.

 

Jeana Alayaay:      Yep.

 

Poornima Vijayashanker:        And so, now they're taking on a bunch of tasks like daily to-do's, but then they also have the higher level kind of road mapping, thinking about where they're going.

 

Jeana Alayaay:      Yeah, so Product Manager, if you're stepping into this role, make sure you do stakeholder interviews up front, right?

 

Poornima Vijayashanker:        OK. Oh, that's good.

 

Jeana Alayaay:      So, when you get into that org, go in, figure out who's doing the work, who the leaders are, and saying, "Where do you need me to fill in the gaps? Where do you need me to take the load off you? What is the plan for this?" Right?

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      If you're the first on any team, figuring out what the hiring plan is—

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:     ...is super important, right? 'Cause that's how you can figure out where you're going to water between rocks, where you're going to need to fill in.

 

Poornima Vijayashanker:        Yeah, that's a good point.

 

Jeana Alayaay:      If the plan is to hire more and more Designers first, right? Probably don't focus too much on taking up all that work. Focus somewhere else, like, "I'm going to have to do more of this sort of classic Product Manager backlog stuff, because we're not going to hire them until later." Right?

 

Poornima Vijayashanker:        Right.

 

## Be sure to introduce your product managers to stakeholders as part of their onboarding

 

Jeana Alayaay:      Yeah, stakeholder interviews, have a sense of what the hiring plan is, make sure you get milestones from them. Say, "OK, I know that we don't have the funds, or the time, or whatever to hire today. When do we expect to hire?" Right?

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      So, you can even manage your expectations around how long your works going to look like this.

 

## What to do when your product manager stops performing

 

Poornima Vijayashanker:        Yeah. Even after all of this effort, right? We have open door policy, we're coaching, they're giving us feedback. Somebody just stops performing, and all of our efforts aren't going to kind of turn this candidate, this employee around. What do we do?

 

Jeana Alayaay:      Yeah, so I think when we first get the sense that it's not working, it's a service to them and to you to actually explicitly say, "This isn't working. What are we going to do about it?"

 

Poornima Vijayashanker:        Mm-hmm, mm-hmm.

 

Jeana Alayaay:      I know that seems like, again, very simple. But, you'd be surprised how many managers struggle to actually have that conversation. It's like, often the person doesn't know that they're not performing until they're put on a PIP, or they're asked to leave, right?

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      Again, saying early, or when you actually believe it's become true that like, "Hey, this isn't working." That's a really important step. 'Cause one, you're giving them the opportunity to turn it around. And, you're also giving yourself the opportunity to think differently about the problem. Let's say you go through all of that. I would say, coach them out, right? Have an explicit conversation about, "This doesn't seem like the right fit. How can I help you get onto the next thing?"

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      Now, of course there's extenuating circumstances where there are like-

 

Poornima Vijayashanker:        Sure, right.

 

Jeana Alayaay:     ...Crazy things happen with the job or whatever. But, I feel like that's a different case.

 

Poornima Vijayashanker:        OK.

 

Jeana Alayaay:      Usually it's just like, they no longer meet the needs of the org, or the orgs changed.

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      Or, they were the right person two years ago, but not the right person today.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      All those sort of things. It's usually fit things.

 

## What does a product manager’s performance review look like

 

Poornima Vijayashanker:        Yeah. Which brings up the kind of overriding question which is, the performance review, right?

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        Having to wait six months, or a year.

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        And, the performance review for a Product Manager is definitely different from your Engineer's, where things are a little bit more, I wouldn't say this in every case, but a little bit more cut and dry.

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        People are writing code, it's quality, it's tested, it gets out there, or they're fixing bugs. In a Product Manager role, it's a little bit more nuanced, where they may come back to you and say, "Well, here are all the things that I've done. But, now I'm stuck because the stakeholder won't move us forward."

 

Jeana Alayaay:      Yep.

 

Poornima Vijayashanker:        Or, "I'm stuck because marketing needs to have a bigger budget to attract more customers so that we can then convert and monetize them."

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:        So, how do you kind of structure that performance review?

 

Jeana Alayaay:      Yeah. I think this goes back to having a development plan early on, and actually keeping a pulse on it, like a very frequent pulse on it. It comes up, at least in passing in my one on one's biweekly, certainly monthly, and then on the quarter, and so on and so forth. I think the product, to what you're saying. The product management cycle is much longer than the dev or design cycle.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      I think it is harder to get strong signals.

 

Poornima Vijayashanker:        Right.

 

## Why it’s OK to iterate on goals

 

Jeana Alayaay:      But, I think there are success metrics that should be in the development plan that you're sort of measuring as you go, and you should also be iterating on them. Again, the thing that would alarm me, is if they hadn't told me about said stakeholder that's blocking them, until the performance review.

 

Poornima Vijayashanker:        Yeah, right.

 

Jeana Alayaay:      Right? That's the wrong time to tell me. I would say, that's a performance issue, versus being blocked, you know?

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      'Cause, if that was a thing that I could have tried to help you solve six months ago, we should have done that six months ago. I'm not sure why we're waiting-

 

Poornima Vijayashanker:        Sure.

 

Jeana Alayaay:     ...Waiting on it till now.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      The things that I would think of as a performance issue, performance issues are usually communication based.

 

Poornima Vijayashanker:        Mm-hmm. What are some specific success metrics?

 

## What success metrics look like for product managers

 

Jeana Alayaay:      Yeah, so the success metrics that I like to put in Product Managers plans are usually learning goals, right? At any given time, a product is in a specific life cycle. Thinking about what part of the funnel you're focusing on, or how you're trying to develop out that product and say to yourself, "OK, what do we need to learn as a team in order to get to the next phase for that product?"

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      And so, having learning goals for Product Managers that point to that is really important. Things like, "We should go out and learn from users, like what the next problem is." I'm being super generic here.

 

Poornima Vijayashanker:        Sure.

 

Jeana Alayaay:      But, "Do we have evidence about what platform we should develop out next?" Not so quantitative, but really like, "Hey, are they out there seeking the problem, moving the org in the direction?" Right?

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      'Cause that's a lot of their job, is do we see evidence of movement.

 

## What to do if a product manager quits

 

Poornima Vijayashanker:        Got it, OK. Finally, despite all of your best efforts someone just ups and quits. Because, this is such a critical role, how do you respond?

 

Jeana Alayaay:      Yeah, I guess it really depends on the circumstance. I think the first question I would ask myself is, "Did we give them enough permission not to buy in the interview process." Right?

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      There's always extenuating circumstances. Something with the family, they were offered double somewhere.

 

Poornima Vijayashanker:        Sure.

 

Jeana Alayaay:      I don't know what those things are. But, there's other things like they came in, and it's not at all what they expected it. That's the thing I want to fix.

 

Poornima Vijayashanker:        Mm-hmm.

 

Jeana Alayaay:      If we didn't give them a good sense of what the environments going to be like, I think that's on us. Again, I think the other bit is, make sure you always have your list of 20 people that you're going to hit up next.

 

Poornima Vijayashanker:        Yeah. Of course, of course. Go back and see our first episode on that.

 

Jeana Alayaay:      'Cause you just never know when you're going to need to fill a role. You just don't know, you should always be prepared.

 

Poornima Vijayashanker:        Right. I think it's also, it is a bit of a challenge though to suss some of that out in an exit interview because people want to leave, and they don't want to burn bridges, or they're kind of like, "I don't want to spell this out for you. I mean, if you don't know why I'm leaving, I don't know if you'll ever know." Sometimes that happens to-

 

Jeana Alayaay:      Right.

 

Poornima Vijayashanker:       ...It might not be your specific fault as the Hiring Manager-

 

Jeana Alayaay:      Totally.

 

## Why underperformance may not be limited to a single employee

 

Poornima Vijayashanker:       ...It might be a team issue, it might be kind of a company wide, or a leadership issue.

 

Jeana Alayaay:      That's right.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      Yeah. Having a postmortem within the working group, I think is a way that we've addressed that in the past, right?

 

Poornima Vijayashanker:        OK.

 

Jeana Alayaay:      'Cause, I totally agree with you.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      During the exit interview, they don't want to say all those things.

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      They don't want to air all the laundry.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:      So, I think having a postmortem as a team and saying, "Hey, so and so left. What do we know about that? Context?" Right? "What are the different perspectives here, what did we see, what did we not see?" Again, we can't all possibly have the information.

 

Poornima Vijayashanker:        Right.

 

Jeana Alayaay:      So, getting all that data from the different places, and pulling it together. At least to have a clear picture of what might have happened, super useful.

 

Poornima Vijayashanker:        Thanks a lot Jeana, for sharing your best practices when it comes to sourcing, interviewing, hiring, and retaining Product Managers.

 

Jeana Alayaay:      Thanks for having me, it's always fun to chat.

 

Poornima Vijayashanker:        Yeah. That's it for this week's episode of *Build*. Be sure to subscribe to our YouTube channel, to receive the next episode. And, be sure to share this episode with your friends, your teammates, and your boss. Ciao for now.

 

Sep 16, 2018

Last week, we dug into the various product manager personas, and how to go about sourcing candidates. 

This week, we’re going to talk about another critical step when it comes to hiring product managers: interviewing.

Unlike interviewing engineers and designers, where you can test their ability to code and design and their responses provide tangible results, it’s harder to formulate questions related to one’s skill and abilities as a product manager that will produce concrete responses. Let’s face it—product management is more nuanced because it often requires people to have experience analyzing data and making decisions related to the goals of the business, in addition to some technical skills. Exposing the spectrum and depth of these capabilities can make interviewing product managers a challenge. For example, it maybe easy to evaluate if someone can organize a backlog of user stories, but harder to evaluate whether they are really capable of creating and prioritizing a product roadmap that balances out various business goals and milestones to an acceptable level of quality and depth for your team.

 

Plus a product team usually has one product manager who interfaces with many engineers and designers, so hiring the first product manager who is going to gel with all those people puts them under a lot of scrutiny.

 

To handle all these challenges, many companies end up crafting their interview process to resemble a standardized test that candidates end up studying for, rather than demonstrating key skills that they will be using to support the team and product. It’s no wonder some of the best candidates fall through, and companies feel stuck with a product manager who underperforms.

 

This episode is a must watch if you’re a hiring manager who is concerned about losing a talented product manager, or you’re a product manager who is trying to assess a company’s interviewing process. In this episode, we’ll share some best practices around interviewing and coming up with objective criteria to use when screening candidates.

 

Jeana Alayaay, Director of Internal Products and Services at Pivotal, is back to help us out.

 

As you listen to today’s episode, you’ll learn the following:

 

  • Why there is such a thing as being a bad interviewer
  • How to prepare the people who will be interviewing candidates
  • How to expose skill sets during the interview
  • How to regroup after the interview
  • Why candidates that don’t meet a checklist are sometimes still hired
  • How to set expectations with candidates when your company is going through a period of change
  • How expectations and the role are different when you are the first product manager on a team

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

# How to Interview Product Managers Transcript

 

Poornima Vijayashanker:         In the last episode of *Build*, we talked about the various personas when it comes to the product manager role and how to go about sourcing candidates. If you missed that episode, I've included a link to it below. Next you're probably thinking given how nuanced the product manager role is, how do you go about actually interviewing and making sure they have the right skill set?

 

Poornima Vijayashanker:         Often this can cause the interview process to become really fragmented. You start to see some interviews that are very technical, others that try to expose business skills, and a third set that might just involve mostly soft skills. If you don't have that right set of criteria or practices, some of the best candidates can just fall through the pipeline. In today's episode, we're going to expose some of those best practices, stick around.

 

Poornima Vijayashanker:         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. We've been talking about the product manager role, how nuanced it is, how to source candidates and also, how to go about interviewing. Given how nuanced it can be, it's a challenge to set objective interview criteria as well as consistent practices to expose the skills that you need for your company and for your team.

 

Poornima Vijayashanker:         But fear not, because in today's episode, we're going to share some of the objective criteria and some best practices that you can adopt for your interviews. To help us out, Jeana Alayaay is back. You'll recall that Jeana leads the product management and design for Pivotal's IT group. Thanks for joining us again.

 

Jeana Alayaay:      Thanks for having me again.

 

Poornima Vijayashanker:         Yeah. I've got to admit that I've gone through a number of product management interviews myself. After spending countless hours doing interview questions related to technical skills, business skills and then having done the work of actually leading teams, building products and shipping them, I was surprised by the feedback that I got from some of the interviewers saying I needed to do even more to get the role.

 

Poornima Vijayashanker:         Why does this happen? It makes people feel like maybe you just need to answer the questions a certain way to get through the interviews so it’s like taking a test instead of knowing the information.

 

Jeana Alayaay:      I think there's three things here. I think one, there's a total disconnect between the job postings and what a company is actually looking for. I think the way that I've thought about it is, a job posting is actually part of the company's larger marketing collateral. So, you're not actually going to get the real deal on culture. This thing, it's never going to say like, "Hey, looking for a PM to walk into a super hostile environment." It's never going to say that.

 

Jeana Alayaay:      And so, I don't know that we can change that bit. But, I think what we can say is like, OK, where's the next touchpoint with the candidate? And it's with recruiting right? I think doing a lot of upfront work with recruiting sort of improves this, but I'm jumping a little bit ahead here.

 

Jeana Alayaay:      I think the second problem is that the hiring group itself isn't actually aligned on what sort of profiles they're looking for. You have anywhere from two to nine interviewers who are going in interviewing the candidate, they get to the end of the process, pull together all that data and you can't actually agree on whether or not to hire the person because no one ever said, "This is what a good candidate looks like." Or even better, "This is what a bad candidate looks like." As we all know, sometimes it's hard to know what good looks like, but we can definitely say what bad looks like or, this isn't going to fit.

 

Jeana Alayaay:      I think the third related thing is that the interview process most often doesn't actually resemble the environment that the candidate would actually be walking into should they get the job. A lot of companies have this prisoner's dilemma process where you go from person, to person, to person, to person and they ask you...Sometimes it's on script, sometimes they have their own scripts, but that doesn't actually resemble a product manager's job of doing a lot of work in groups, going around getting alignment like a lot of collaboration.

 

Jeana Alayaay:      I just don't think it resembles the environment at all. And so again, they get to that end of the process and they say no because they don't think the candidate's going to be successful in the environment but they've never actually given the candidate the chance to demonstrate whether they would be because it doesn't look anything like that.

 

Poornima Vijayashanker:         So then how do you get that criteria or how do you build that into the interview process?

 

Jeana Alayaay:      I think in general we don't put enough time into hiring. We put a lot of focus on the hiring manager, but we don't talk about the other interviewers. Everything from like, what is the group looking for to, are the interviewers themselves actually prepared to interview? I've come across these interesting situations where the interview process for one company or another posted on Glassdoor and that team says, "We've got to change the interview process because the candidate will know what to say."

 

Jeana Alayaay:      I go, "Well, do you actually know what questions to ask to get at that data outside of following the script? Do you know in your gut what you're looking for? What the company is looking for? Can you ask that question 10 different ways?" We don't often talk about whether the interviewers themselves are actually prepped to do this work.

 

Poornima Vijayashanker:         Totally, there is such a thing as a bad interviewer.

 

Jeana Alayaay:      Yeah, absolutely and so you end up with like again, two to nine people who are doing totally different things and none of that's really giving you a clear signal about whether or not this person is going to be successful in this company.

 

Poornima Vijayashanker:         Yeah. How do you then prep the interviewers and then convey the criteria back to the candidate?

 

Jeana Alayaay:      Two part here. I think one is, you actually need to train interviewers. At least on my team, I don't have folks interview who don't have experience interviewing. So, they should actually have to shadow other folks, cross-discipline and within discipline that have interviewed before and actually understand what that process should look like. And, understand from the hiring manager what they're looking for.

 

Jeana Alayaay:      Sending somebody in cold no matter what level they're at, you're not going to get the best outcome out of that. I think going back to the recruiting process, I think it's totally fine and good to tell the recruiter to tell the candidate, "Here's what they're looking for." And I think this is a lot like the Glassdoor problem that I was talking about before. I've heard people push back against that and say, "Well, then the candidate's going to know."

 

Jeana Alayaay:      And I say, "I'm not sure that that's the case." In our case at Pivotal, we hire for empathy, but I'm sure you can ask questions of the candidate to figure out whether or not they're empathetic. If you're relying on the candidate saying, "yes I'm empathetic," you've already gone off the rail.

 

Poornima Vijayashanker:         Yeah, and I think a lot of times candidates either don't necessarily follow the instructions they've been given or they decide to go off on their own tangent to make sure that they appear good in front of the interviewer's eyes. So, there's definitely different ways in which they can miss the mark, but if you can give them some crystal clear criteria of what to expect and what the interviewers are going to want to see in terms of their resume or their experience. I think that's more helpful. Now, in terms of the actual interview, do you have a set of practices that you recommend?

 

Jeana Alayaay:      Yeah. I actually usually step in in the second interview because I think it's really important they encounter the hiring manager early on and then at the end. I reiterate what the recruiter has said, which is like, "Hey, these are my expectations for the role," and I give them permission not to buy. I think this is really important because you're interviewing them, but they're also interviewing you and so you've both got to want to be there. And so, I think giving a candidate the chance to say like, "no, this isn't actually for me," before shepherding them into this longer interview process is important.

 

Jeana Alayaay:      The other thing I've talked about before, make sure you've prepped your team on how to interview and also set really clear expectations. I actually have a document, a really detailed document outlining what I'm looking for, things to watch out for, responses that I might expect, different scenarios that you might end up in. That way, the interviewers go on, they feel prepared and we get more consistency out of the responses.

 

Poornima Vijayashanker:         You do even list a bank of questions?

 

Jeana Alayaay:      Yeah.

 

Poornima Vijayashanker:         OK, that way it's not the same person or multiple people asking the same question or you found out that 50% of the interview was in data analytics and you're not even hiring for that.

 

Jeana Alayaay:      Yeah. And then, they're all sort of different versions of the same question. I always say like, "Hey, you folks are interviewing, figure out a way to say this that feels authentic to you, but this is what we're trying to get it. This is the data that we;'re trying to get from the person."

 

Poornima Vijayashanker:         I think that's helpful. I think also having the responses, like what the expectation is for some of the responses because some of the feedback that candidates either get or don't get is how detailed the response should have been. They may think they need to be pithy and save the interviewer time and just scratch the surface when the interviewer is really looking for, "No, I expected you to spend 30 minutes to highlight every single corner case of this particular product feature," or whatnot.

 

Poornima Vijayashanker:         I think it’s helpful if you have that bank of what should the response actually look like. Kind of like a test where at the end of the day you can go back and say, "This is how we graded you because this was the answer we were looking for."

 

Jeana Alayaay:      Yeah, and little ticks are helpful for that. I would say, if they're expecting a long answer, there's no reason why you shouldn't say to the candidate, "Say more," or, "Could you elaborate?" I think we too often just let the candidate fall into the dark and it's like, if you're after something, let's set them up to actually give the responses that we want.

 

Poornima Vijayashanker:         What do you so for new roles though? Because, this is great where maybe somebody left the company or got promoted and now you're filling this role. But in the case of a brand new role, I think a lot of time people don't even know, as in the interviewers, the hiring manager are like, "We need them to do this and this, but what else do we need them to do?"

 

Jeana Alayaay:      I think this is where it's really important that the hiring team actually get into a room beforehand and put a stake in the ground. You're not going to know 100% what you need the role to do, but you have some sense of it and people have an idea in their mind. It's really important that that idea come out in a way that's accessible to other people because otherwise you end up in the problem that I was talking about before which is, everyone has a slightly different idea and it has even less structure than you would for a role that already exists, so everyone's really all over the place.

 

Jeana Alayaay:      It's like Poornima goes in and she's like, "I think we need a data person," I go in and I'm like, "I think we need a community person." Ll and behold, we end up revving on this for months, and months, and months unable to fill the role.

 

Poornima Vijayashanker:         Yeah, I think oftentimes what happens is people don't know what they want and then the poor candidate's like, "What did I do wrong? I spent all this time preparing, followed the job description and listened to what the interviewer said. I just feel like I'm lost." Then it ends up being a branding issue for the company.

 

Jeana Alayaay:      Yup, and it's a really resource-heavy activity. I always ask, "Do we really want to send folks in who don't know what they want?" I know that we want to fill this role, but if we can't take 30 minutes or a couple hours to put some shape around it, is it worth us even opening up the pipeline? Those are conversations that don't happen enough and are hard to have.

 

Poornima Vijayashanker:         So then, how do you go about...Once you do have some candidates, you've walked them through the pipeline, how do you go about consolidating the feedback from each of the interviewers? Because again, there's definitely some tough interviewers who were aiming for 100%, 110% and then there are some people who are like, "This person knows 80% to 90% and they seem really coachable. We can all pull together and get them up to speed." How do You consolidate that feedback from all the individual?

 

Jeana Alayaay:      The first thing we do is actually jump into a room and do a Roman vote. We have everybody vote whether or not to even move forward with the candidate.what I've found in the past is, you could be in there for an hour talking through the candidate did this well, they didn't do this well and like five people have already decided that it's a no. So again, just being respectful of everybody's time like, "You don't need to do that."

 

Jeana Alayaay:      So, first let's get a count of who wants to move forward, who doesn't. Folks who are a no, it's important to have a few of them speak up and add some color to why they think it's a no, and then also on the yes side. Then again, a document or some sort of info radiator that captures what you are looking for to begin with is really important to bring to the table and say, "OK, here's what we're looking for. How do each of these candidates match this or don't match this?"

 

Jeana Alayaay:      I even include things like coachability and humility. Sometimes you're looking for somebody who's super coachable and so you've got to go around and say like, "Hey, I know you didn't hear what you wanted to hear, but are they coachable?" Reiterating what we're looking for, not do they know everything. Points like that become really important in synthesizing that data.

 

Poornima Vijayashanker:         For you, do you do an anonymous vote first and then once you have the yes/no counts then do a deeper dive? Because, otherwise people can get colored right?

 

Jeana Alayaay:      It's a silent vote, and a Roman vote's really interesting because you all do it at once. You do a one, two and then...Up is yes, sideways is move with will of the group and down is no, I are I have something to say. So, everyone votes at the same time. We start off that way then we move in. We usually reserve at least an hour afterward to talk it through.

 

Poornima Vijayashanker:         Some companies rely on a unanimous set of votes and some leave it up to the hiring manager to make the final decision. How do you view either one?

 

Jeana Alayaay:      I can't say for sure because it has to be right for that culture, but I would say I consider myself to be a tiebreaker more than the person who makes the decision at the end of the day, though functionally I often am. You know, thinking about your hiring team, these are the folk or should be the folks that your candidate's going to work with. And so, if you don't actually respect their opinion, you've got one problem. And if they weren't prepped for the interview so they don't know what they're looking for, you've got another problem. I don't think either of those is solved by me making the decision right? That's a problem we should've solved a couple hours ago versus now.

 

Poornima Vijayashanker:         Got it. And, any red flags or signals that you want to watch out for in candidates?

 

Jeana Alayaay:      For me, it's over-solutioning. What I like to see is a lot of curiosity and deep attention to the problem. I don't know if this is the best analogy, but we often refer to our project managers as like bloodhounds. It's like, you really want folks whoa re seeking after the problem and they're asking five why's. When they find a problem they say why and why again, why again and why again and that we're not jumping into solutioning.

 

Jeana Alayaay:      We're in this really interesting moment in time in the industry where it's actually super easy to build. And so it's like you don't want to build too quickly because all that stuff's going to be maintained. It's so expensive to maintain and maintain that thing into the future that you don't want to build anything you don't have to build. So, I would say if they're over-solutioning, I consider that to be a red flag.

 

Jeana Alayaay:      I think the other one is not engaging with the audience. You have a few different versions of this. Sometimes they're only focused on the hiring manager even when you have gender dynamics going on and whatever the case may be. You want to see that they're engaging with the whole room and that you're starting to get a sense of the type of communication that you're going to see from them on a day-to-day basis.

 

Jeana Alayaay:      Sometimes that actually means putting them into uncomfortable situations. In a later stage of our interview process, I actually throw them curve balls and I say like, "OK, something's gone wrong. What are you going to do about it?" To get a sense of how they think on their feet, whether they accept the situation with grace, whether they'll reach out for help.

 

Jeana Alayaay:      Another big red flag for me is product managers who are uncomfortable saying, "I don't know." Because, then we're hiring somebody who wants or thinks they should be a hero persona and is not going to rely on the wisdom of the group to make decisions. They're going to feel like they need to go away in a cave. You just can't do that with the types of products we're building because it's too multi-part. If you've got hardware and software and business or supply chain innovation, there's no way any one person knows all the things.

 

Poornima Vijayashanker:         What about feedback? Some companies are very strict about saying, "Nope, we absolutely don't give candidates feedback afterwards because of X, Y, Z reason." Others might give a little teaser, and then I've seen others where they're like, "We want you to come back in six months or even sooner than that so here are very deliberate things to work on for the next round."

 

Jeana Alayaay:      Two of those things resonated with me. I think one is giving feedback about why they weren't a fit today is really important. In most cases, it's because they're not a fit today, it's not because they're not a fit at all, sure there's always folks we're like, "This is never going to work," but that's not often the case. So, saying like, "Hey, here's what we were looking for. You weren't a fit for today, but maybe you would be a fit in the future for this specific scenario and here's what we'd be looking for," I think is a fine conversation to have.

 

Jeana Alayaay:      I don't know that nitpicking folks is necessarily productive because again, there's a lot of personal biases that go into that and I don't know that that's the best use of your time or the candidate's time.

 

Poornima Vijayashanker:         Sure, that makes sense. Sometimes when we're giving this feedback, or even when we're consolidating this feedback, we have this light bulb moment where we're like, "Oh, actually this candidate doesn't meet our one, three or 10 check boxes, but for some gut reason we feel compelled to want to hire them." Has that happened to you and how do you justify that to your team?

 

Jeana Alayaay:      When thinking about some of those checkboxes, and some that I'm familiar with across the industry, I think specifically about technical skills, and that's a broad term, that could be anything. But, if you're hiring a product manager, is that the most important thing? And I'm not saying hire somebody that's never built software, that's not, that's not what I'm advocating for.

 

Jeana Alayaay:      But, I do think we put too much stock into that where it's like, "Hey, there's a reason we have developers and data scientists and all of that." There's a lot of folks on a team who can pick up that specific work. So, thinking about what you actually want them to be doing and whether or not they fit that. Then again, thinking about whether they're coachable. Let's just suspend this belief here and say that we're always hiring smart people and I hope that's the case, though sometimes I've gotten in a room with other hiring people and there like, "Well, we should hire smart people."

 

Jeana Alayaay:      And I think, "Is there someone here that's not hiring smart people?" So, let's just say we're always hiring smart people, looking at what ramp time is for that person. Maybe they just need a few extra months to marinate in some specific hard skills, but they have all those other soft skills which are a lot harder to acquire. A lot of those soft skills are years, and years, and years and very experience-based.

 

Poornima Vijayashanker:         Right. Well, thank you so much Jeana for sharing your best practices when it comes to interviewing product managers.

 

Jeana Alayaay:      Thanks for having me.

 

Poornima Vijayashanker:         Yeah. Now, Jeana and I want to know, what are your best practices when it comes to interviewing product managers and candidates. Let us know in the comments below this video and be sure to subscribe to our YouTube channel to receive the next episode where we'll talk about how to train as well as retain your product managers. Ciao for now.

Sep 9, 2018

To build a product, you need a team of engineers, designers, and the glue that keeps them together: product managers!

 

The role of the product manager has dramatically changed over the past decade, and because it’s still a relatively new field that’s in flux, companies often struggle to find candidates, which in turn makes it hard for candidates to understand what companies are looking for.

 

So all this month, we’re going to focus on a number of best practices for sourcing, hiring, interviewing, and retaining product managers.

 

In today’s episode, we’ll focus on giving you a lay of the land, starting with how product management is evolving and how to go about sourcing candidates for a product manager position at your company.

 

To help us out, I’ve invited Jeana Alayaay, the Director of Internal Products and Services at Pivotal.

 

This episode is chock full of helpful best practices for both product managers and those looking to hire them. As you watch, you’ll learn the following:

  • How product management has evolved over the years
  • Why you need to think about the type of product manager you are looking for (hint: there is more than one persona!)
  • How to communicate the key criteria you are looking for in a candidate
  • How to build a pipeline of candidates
  • How to train recruiters to help screen candidates
  • How to stop hiring out of desperation
  • Why it’s actually helpful to give candidates a quick no

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## How to Hire Product Managers Transcript

 

Poornima Vijayashanker:        I know I'd love to just wave a magic wand and find top technical talent. But I've learned over the years that it takes a lot of effort to source, interview, hire, and retain that talent. It's become even more challenging in a new field like product management where company criteria changes as well as the skill sets that candidates have. So if you're struggling to find those product managers that are going to be the right fit for your company, stay tuned because we'll share a number of best practices in today's episode on sourcing candidates.

 

Poornima Vijayashanker:        Welcome to *Build*, brought to you by PivotalTracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies and your career in tech. When you got a lot going on it's very tempting to want to take short cuts to hire candidates. But those shortcuts can often backfire causing you to hire somebody that may not be a good fit for your team. And when it comes to a role like a product manager where they're going to be interfacing with a lot of different people as well as teams, you want to make sure you got the right fit and you may need to put in a little extra effort to make sure you get that candidate.

 

## Best practices for sourcing product managers

 

Poornima Vijayashanker:        In today's episode, we're going to talk about some best practices when it comes to sourcing product managers as candidates for your company. And to help us out I've invited Jeana Alayaay, who leads product management and design for Pivotal in their IT group. Thanks for joining us today, Jeana.

 

Jeana Alayaay:       Thanks, Poornima.

 

Poornima Vijayashanker:        Yeah.

 

Jeana Alayaay:       Good to chat with you.

 

## The evolution of product management and the role of the product manager

 

Poornima Vijayashanker:        Thank you. So you've been a product manager for quite a while now and you've seen it evolve as a role, so walk us through the evolution that you've seen and why it's come about?

 

Jeana Alayaay:       Yeah, so I think to answer your question about how product management has changed, think about how the market's changed. So there's a lot of touch points with technology and consumers and businesses and so the expectations for what quality and user experience look like are increasing, increasing, increasing. So in order to accomplish that like product teams have to do a lot of cross-discipline collaboration in order to create and maintain that experience. It's actually this one big people problem. One of the main jobs of product management is really to manage that people problem. So the folks who are both good at that and who want to do that work are really sought after.

 

Jeana Alayaay:       Before, when we think about product management we think more about project management which is like who's managing deliver in the backlog. And now we're thinking more about like who's managing people ecosystems within a product organization?

 

Poornima Vijayashanker:        OK. So that means inside of the company, not people as in users.

 

Jeana Alayaay:       Yeah.

 

## Types of product managers

 

Poornima Vijayashanker:        OK. Now you and I both know there's also a lot of personas out there when it comes to product managers. There's the growth hacker, the workflow warrior, the community, the creator or connector and then somebody that manages platform, data or just mobile. Do we need all these personas? What's kind of the...Are there a lot of differences and nuances between them?

 

Jeana Alayaay:       Yeah. That's a great question. I love personas because it gives you a sense of who to look for out in the wild but I don't know that a persona is going to solve the problem of the modern product. So I think what we're looking at is products are these big spaces now. They're multi-part, they're multi-platform. They have a lot of different pieces and components themselves can be considered to be products. When you're thinking about managing that you should really be thinking about managing a team. Not having specific people on specific verticals and I'll tell you why.

 

Jeana Alayaay:       So when you hire specific people on specific verticals what you get is a bunch of individual contributors doing their own thing and that team is unable to elevate the bigger product or offering right at the higher level. So you just sort of miss the mark on that I think.

 

Poornima Vijayashanker:        Got it. OK so kind of keep the skillset in mind for each of these but think a little bit more higher level.

 

Jeana Alayaay:       Yeah.

 

## Take stock of the skill set you need from a product manager for the long term

 

Poornima Vijayashanker:        Now this is the second PM team that you're managing and building at Pivotal. What did you learn from your first experience that you're applying now?

 

Jeana Alayaay:       Yeah, so I think the thing that I was talking about earlier was really think about the makeup of the team like the skillset, and figure out how to compliment the skillset and build it out very intentionally. So I think when I first started as a hiring manager so to speak or a team leader, practice manager, I thought, "Yeah I'm going to hire a person to do this and hire a person to do that and hire a person to do that." But the job itself is so cross-functional that no one actually really works in isolation. So really you need a bunch of people who can pair up and actually combine skills in different scenarios.

 

Jeana Alayaay:       And so thinking about that, I think OK what do I need in three months, what do I need in a year? What should this team look like, rather than what do I need now. And I think that's counterintuitive because by the time you have a wreck open there's a little bit of desperation there because you need somebody to cut wood in hot water. You can fall into the trap of hiring somebody that you need today but not necessarily the person you need tomorrow, if that makes sense.

 

## How to uncover and communicate the key criteria you’re looking for in a product manager

 

Poornima Vijayashanker:        Right, especially if your product evolves or the strategy evolves or if the market evolves as well. That's actually a great segue into my next question which we got engineering, that's become very nuanced. There's front end there's back end and then there's specialization within that for the same kind of thing with a product manager, how do I determine my needs and set up the sourcing criteria for my team?

 

Jeana Alayaay:       Yeah, that's a good question. I think the best thing to do is actually look to your team for that information. So I think as hiring managers, we're sort of set up into the system to make the decision in isolation but I think you can't actually know all the things that your team is experiencing on the day to day. So having your team do that gap analysis is really important. And having explicit conversations about what's working, what's not working, were we missing. Were you missing the mark? What kind of people do we need? Having that conversation is super important because I don't know that it is most that...Sorry let me back up. Most of the time the problem is not actually hard skills so to speak it's hard and soft skills. And so the thing that your team is missing is not somebody who can do really awesome data analysis or code or whatever, it's usually who's going to manage the most hostile, fiscal stakeholder group that you can think of.

 

Poornima Vijayashanker:        So what are those conversations look like or how do you bubble that criteria up?

 

Jeana Alayaay:       Yeah, so I think my team prefers more structure so we usually actually do a work session where we sort of dump and sort what those needs are, what problems we're solving for. And really what I think my job is is to make sure that we're looking, again, three months, six months, a year, even two years out and we're not just solving for we have a super painful thing right now but where's the team going? How do we see the organization's needs changing, how is the team going to have to shift its responsibilities to meet those needs? And have that be a very, very explicit conversation.

 

## How to source product managers

 

Poornima Vijayashanker:        So once you got that criteria, the next challenge is where do you find people that meet this criteria? What have been your watering holes?

 

Jeana Alayaay:       Yeah, so unfortunately I don't have a magical answer to this but for me it's been referrals. And even like intercompany transfers. So I like to keep the profiles of the next three hires in my head with me and I sort of talk about them out loud, to my network, both inside of the company, outside of the company. So I think there's a lot about just letting the universe know that you're looking and then folks will come. I think the other part of that is to always be looking. So I think if you get to the point where you're looking and you need to fill a pipeline you're probably already too far behind.

 

Poornima Vijayashanker:        Yeah that makes sense. So then creating that pipeline so that you have a constant list of potential candidates, how have you gone about doing that aside from the two techniques you just mentioned?

 

Jeana Alayaay:       I think it should be part of a hiring manager's weekly workflow. So I don't think this is a thing that you do in fits and spurts. I think it's a thing that's like every week you look at your list. You're trying to build out 20, you're trying to build up a list of people to talk to. You're going through resumes, you're sending out emails just saying like, "Hey, I would love to be introed to anybody who's going to be interested in product management sometime in the next year."

 

## How to build a pipeline of product managers

 

Poornima Vijayashanker:        That brings up another question of if you were looking to hire two or three candidates at the end of an interview round or maybe over the next few months, what's your magical starting number? What does the funnel look like? Is it one x, two x, 10 x, how many?

 

Jeana Alayaay:       Yeah our team's lucky to have a very high conversion rate but I think conversion rate is different company, company, team to team. So think about that and then think OK so how many people do I need to actually interview in order to get to that number and then well the pipeline should be three times that size. So, if you need 20 interviews to get to the one then you need 60 people in the pipeline.

 

Poornima Vijayashanker:        Wow, so that's 20 first-time interviews.

 

Jeana Alayaay:       Yeah.

 

## How to train recruiters to help screen product managers

 

Poornima Vijayashanker:        OK, got it. And what are some other steps you would recommend people do as they're considering sourcing candidates so prior to the interview phase?

 

Jeana Alayaay:       Yeah, so I think there's a big disconnect between usually recruiting and the hiring team. So I think having a lot more thoughtful conversations about what you're looking for is really important and it's where I've been successful. So I think even having a recruiter sit in on an interview with you so they better understand what sort of questions you're asking, what you're trying to get at and then actually having a debrief and sitting down with them and saying, "This is what I liked about the candidate. This is what I think was not a good fit. This was a red flag." Things like that so that when they're doing the initial screening in the future they have a better sense of where are you going to land with this person.

 

Poornima Vijayashanker:        Got it, so iterate and give them that feedback as you're in the midst of the interview and make sure that that goes out back to the sourcing step. Is there anything you would recommend in terms of job descriptions? Because I know that can also be a real challenge for the people writing them as well as the candidates reading them and there's usually a mismatch that happens.

 

## What to include in a job description and screening process for product managers

 

Jeana Alayaay:       Yeah. I wish I had something more to say about this. I think there's a problem which is that the job descriptions as you seen are super generic. And I think part of that is because they're sort of part of a company's marketing collateral. So what you're never going to get in a job description is looking for a PM to walk into a super hard conversation. They all sort of read the same. And so thinking about that initial screening process is the place that I chosen to fight the battle around because I've tried to fight the job listing battle but it's not worth it and for some of those reasons are good reasons, right. And so thinking about OK let's say they get to the recruiter, what does a recruiter going to say to them what's that conversation going to look like and put a lot of effort into that.

 

Poornima Vijayashanker:        Got it, so prepare them but yes the job description maybe a little bit more vague and then make it more specific as it goes down the pipeline so as you have that initial recruiter call and then maybe the initial phone screen.

 

Jeana Alayaay:       Yeah, and I think one of the things I like to tell recruiters, which they know but it's good to say it out loud, is like let's all try to be respectful of each other's time so it's like they're looking, we're looking. We shouldn't move people through the pipeline that we're not actually interested in. And the first step to making sure that that happens is let's not move people through the pipeline who are obviously not good fits.

 

## Why it’s actually helpful to give candidates a quick “no”

 

Poornima Vijayashanker:        Yeah that's a good point, and I think I've certainly experienced that challenge first hand is getting that quick no is often better than waiting months and months to discover, "Oh, maybe you weren't the right fit." Or they changed their requirements or changed their company's strategy so candidates are much more thankful when you just say no in a couple of days and save them time so they can go on to the next set of interviews.

 

Jeana Alayaay:       Yeah exactly. And it's like now might not be the right time but that doesn't mean that candidate's not a good fit in the future so I think just thinking about it as partially a networking exercise where it's like you don't know when they're going to come back around. You're going to encounter them in another company so just being super respectful within the process I think is really important.

 

Poornima Vijayashanker:        Well, thank you so much for sharing how you think about product managers and how to go about sourcing them.

 

Jeana Alayaay:       Thanks for having me, Poornima.

 

Poornima Vijayashanker:        Yeah, and I can't wait until next week where we're going to dive into some of the interview techniques. And for all of you out there, Jeana and I now want to know what are some of the product manager personas that your company thinks about and what are some techniques that you've employed to sourcing candidates? Let us know in the comments below this video and be sure to subscribe to our YouTube channel to receive the next episode where Jeana and I will be sharing some of the best practices when it comes to interviewing product managers. Ciao for now.

Aug 6, 2018

In the last episode of Build, we debunked a number of myths related to bitcoin, blockchain, and other cryptocurrencies.

 

Despite all the myths and hype these technologies have staying power in the market. But we get that you might be skeptical. So we’re dedicating today’s episode to showcasing how they are being incorporated into valuable applications that are making an impact in the market.

 

And if you’re still concerned about the volatility behind cryptocurrencies or how to get involved without losing your shirt, we’ll dive deeper into each of those topics.

 

Our guest, Audrey Chaing is back. You’ll recall Audrey is a crypto trader as well as a Blockchain analyst and consultant, and blogs on Blockchaing.  

 

Here’s what you’ll learn from today’s episode:

 

  • How Bitcoin, Blockchain, and Cryptocurrency Are Being Applied To Financial Services, Identity, and Supply Chain
  • What Is An ICO (Initial Coin Offering)
  • What Causes Volatility In Bitcoin And Other Cryptocurrencies
  • What Are Cryptocurrency And Bitcoin Exchanges And Marketplaces
  • What Are The Up And Coming Business Applications For Blockchain Transactions
  • How Blockchain Is Being Used To Monitor Identity
  • How To Get Involved In Learning, Building, and Investing In Blockchain

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

# How Bitcoin, Blockchain And Cryptocurrencies Are Being Incorporated Into Valuable Applications That Are Making An Impact In The Market Transcript                  

 

Poornima Vijayashanker.:                     In the previous episode, we debunked a number of myths related to Bitcoin, blockchain, and cryptocurrencies. If you missed that episode, I've included a link to it below. In today's episode, we're going to dive a little bit deeper and talk about some of the cool applications that have come out of Bitcoin, blockchain, and cryptocurrencies and let you know which ones are here to stay and how you can get involved. 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. In today's episode, Audrey Chaing is back. You'll recall that Audrey is a crypto trader, as well as an analyst and consultant. Thanks for coming back, Audrey.

 

Audrey Chaing:                Thank you.

 

Bitcoin, Blockchain, and Cryptocurrency Applications: Financial Services, Identity, and Supply Chain

 

Poornima Vijayashanker.:                     Yeah. Today, we're going to talk about some pretty cool applications of Bitcoin, blockchain, and cryptocurrencies, and why they're here to stay, and how our audience can get involved. Let's kind of dive right in. Let's talk about, what are some of the applications of each of these?

 

Audrey Chaing:                Sure. To be honest, everyone's still trying to figure out the killer use case, but there's a lot of really exciting work happening. They tend to fall into kind of three buckets. One is financial services, which we are kind of more familiar with, with the cryptocurrencies and things like that, cross-order payments, remittances. Another area is identity, and another area is supply chain, and so—

 

What Is An ICO (Initial Coin Offering)?

 

Poornima Vijayashanker.:                     Let's start with the financial services. I know there's a lot of ICOs, initial coin offerings. What are those?

 

Audrey Chaing:                Yes, initial coin offering, that's basically how a new cryptocurrency comes into existence. I mean, it's almost a new way to fund a startup that is related to blockchain. They could be doing any number of things. An example could be, "We're doing distributed storage, so then in order to buy and pay for services, you have to use our token coin." Yeah.

 

What Causes Volatility In Bitcoin And Other Cryptocurrencies?

 

Poornima Vijayashanker.:                     Got it. What's causing a lot of the volatility now in the market then, as it relates back to these ICOs?

 

Audrey Chaing:                A lot of it is, frankly, just speculation, because people have heard of how much money that some others have made in cryptocurrencies, and people are interested because they want to make a quick buck. Right?

 

Poornima Vijayashanker.:                     Yeah.

 

Audrey Chaing:                Also, for the people who are less familiar, there tend to be different stages of a sale in an ICO. You would get kind of in-the-know institutional investors that would come in on the early rounds and get a very large discount. Then they might have several rounds of sales, and then by the time you reach the crowd sale, they might also have a tiered, "If you get in now, you get a larger discount. Wait till next week, you still get a discount, but it's smaller," and so—

 

Poornima Vijayashanker.:                     So it is very much like fundraising—

 

Audrey Chaing:                It is, yeah.

 

Poornima Vijayashanker.:                     ...from like venture capitalists or angel investors.

 

Audrey Chaing:                Now, the difference is that you get liquidity a lot faster. If your token ends up getting listed on exchanges, that means you can start trading right away. Sometimes there are kind of lockups for the large institutional investors, but that is one big difference.

 

What Are Cryptocurrency And Bitcoin Exchanges And Marketplaces?

 

Poornima Vijayashanker.:                     Yeah. Actually, let's dive into that. There are a lot of other applications in the financial services, like what you just mentioned, exchanges and marketplaces. What exactly are these? Walk us through.

 

Audrey Chaing:                Yeah, sure. Actually, just to clarify, too, ICOs, the tokens could be in any number of industries. It doesn't have to actually relate to financial services. Some of the more straight financial services use cases might be...There's something called Coins.ph. It's in the Philippines. A lot of Philippine workers work internationally, remit money back to their homeland. This actually is interesting, because it brings on a lot of the unbanked population, so there's...In order to participate in our current banking system, you need to have a minimum amount of deposits in order for it to even be worthwhile for the bank to have you, and a lot of people don't have that. Now, with crypto, integrated with our current banking system, you can use the Coins.ph app to send money to friends, and they could go to an ATM and pick up cash, or just the corner store, pick up cash. You can pay for your tuition that way, your cell phone bill, all sorts of things.

 

Poornima Vijayashanker.:                     Very cool.

 

Audrey Chaing:                There's also, there are traditional ways of sending money around, which is Western Union, wire transfer, which tend to be slow and relatively costly, but now with crypto, it can happen a lot faster and a lot cheaper.

 

Poornima Vijayashanker.:                     Got it.

 

Audrey Chaing:                Those are kind of the financial use cases, but you asked about exchanges. There are many. A lot of the reason that there are so many is because there are so many coins, and not every exchange will have all of the coins you want to trade. Most people in the U.S. would be familiar with Coinbase. I think they have a pretty good brand name, and pretty on top of their regulation, their...It's easy to use. However, they only trade four different coins, so if you want a coin that is not one of the four that Coinbase has, what you have to do is put your fiat, or your U.S. dollars, into Coinbase by some either Bitcoin or Ethereum. Identify what other coin you want. Let's say you want Monero. Right? Then you have to find which of the exchanges has Monero, send your Bitcoin over to that one, and then buy your Monero that way.

 

Poornima Vijayashanker.:                     In the previous episode, you started to hint at some business applications for blockchain. Not the cryptocurrencies, but just the underlying technology. Why are people using this for business?

 

Business Applications For Blockchain Transactions

 

Audrey Chaing:                I guess going back to the kind of large categories, we already talked about financial services a bit, but let's talk about supply chain for a second. Right? There are some very interesting proof of concepts going on. I can talk about a couple. One is with prescription medication. You can basically track that it is legitimate, right, it's not like a fake or copy, and then you can make sure that, say, it needs to be refrigerated, that it was taken care of the whole way through.

 

Poornima Vijayashanker.:                     How do you, how can you tell that?

 

Audrey Chaing:                Kind of like, well, you could kind of use sensors to say that, "OK, the temperature never reached above X amount that would make the medication bad." You could, kind of like how you already scan along the way, say, a FedEx package, you could track all these different stages and have them write to the blockchain.

 

Poornima Vijayashanker.:                     OK, got it.

 

Audrey Chaing:                Then since it's on the blockchain, you can't go back and edit the database. Right?

 

Poornima Vijayashanker.:                     Right, so basically, it's stuck there, and then people can see the audit trail because it's on-

 

Audrey Chaing:                Yeah.

 

Poornima Vijayashanker.:                     ...blockchain.

 

Audrey Chaing:                Exactly. Another interesting use in supply chain is provenance for food. For example, if you are eating bacon and you are interested in, "Where did this pig come from?" All the way from which farm, what it was fed, how it was...The whole process of how it reaches you, you can now track that.

 

Poornima Vijayashanker.:                     Very cool. How does somebody then get onto the blockchain to have the entire supply chain and each of these transactions listed?



Audrey Chaing:                Yeah, so blockchain, in the traditional sense, is a public blockchain, so you, or I, or anyone could go onto Blockchain.info, for instance, and look up any Bitcoin wallet or Bitcoin transaction. There is this idea of permission ledgers, which, especially, some enterprise are looking into because they don't want everyone to have access to everything, but in the traditional sense anyone can look it up.

 

Poornima Vijayashanker.:                     Yeah, but then it's only as good as the reporting, right?

 

Audrey Chaing:                Yes. There is this kind of...When you try to mesh the real world with the digital world, how do I know, "So-and-so is attesting that this is true. Well, is that legitimate?" Then, so that is something we definitely need to think about when we try to kind of mix the digital and the real world.

 

Poornima Vijayashanker.:                     Got it, yeah, so going back to your bacon example, if somebody forgets, maybe in the packaging stage or one stage before that, to list a transaction, what happened, then the public isn't going to know what that is, so there is going to be still a hole in it.

 

Audrey Chaing:                Yeah, so these are the things that are being kind of worked out right now, with all of the kind of proof-of-concept work and research.

 

How Blockchain Is Being Used To Monitor Identity

 

Poornima Vijayashanker.:                     Very cool. What's another application that you think is here to stay for blockchain?

 

Audrey Chaing:                Identity is another area where there's a lot of work, a lot of interest, kind of how it could look like in the end. Right? You could have full control over your data. For instance, if you had your medical data here, your social media data here, your shopping data here, you could say, "I want to grant you this particular piece of information," and you can even decide to be compensated for it or not. That's kind of the self-sovereign identity piece. There's already some work happening in this area in governments, even. The government of Finland, they have this blockchain-enabled card for refugees. This card will be an identity card, but also, they load it with money, so that's one interesting use case. Estonia now has e-citizenship, so there's a lot of interesting stuff going on.

 

Poornima Vijayashanker.:                     I know one concern that our audience may have is, which of these things are fads? Which of these things are here to stay? It sounds like some of the things that are more groundbreaking, like identity and supply chain, are here to stay, but can we really know?

 

Audrey Chaing:                Yeah. Actually, we can't. That's a good warning for anyone trading crypto or getting to blockchain is that there's a lot of potential. It's very exciting. However, there are some real technological hurdles, including scalability. That's the largest one. There are a lot of smart people working on it, including like off-chain solutions, but we won't know for sure. Yeah, I would say if you're going to invest, I think it's smart to have something, but don't put in more than you would be OK losing, because that is a possibility. You could completely lose it all.

 

How To Get Involved In Learning, Building, and Investing In Blockchain

 

Poornima Vijayashanker.:                     Yeah, and in terms of investing and learning about applications of blockchain, or getting involved in building something on the blockchain, what would you recommend?

 

Audrey Chaing:                Well, I guess there are a lot of choices, but not a whole lot of great resources, to be honest, so you have to decide kind of like what kind of do you want to build on an existing chain? Do you want to build your own? I mean, building your own is quite a undertaking, but people have done it. I think the best way would be just start. There's no, it's very, not a whole lot of documentation, not a whole lot of tutorials. There are meetups all over, so I'm actually a part of Oakland Blockchain Developers and SF Ethereum Developers. They have people come in and do technical talks and sometimes code labs. That really helps, but it's very, it's not fun to work with yet.

 

Poornima Vijayashanker.:                     Yeah.

 

Audrey Chaing:                Right?

 

Poornima Vijayashanker.:                     OK.

 

Audrey Chaing:                It's very early, and-

 

Poornima Vijayashanker.:                     So not for the faint of heart, but maybe for those—

 

Audrey Chaing:                Yeah.

 

Poornima Vijayashanker.:                     ...who want to get in, eager—

 

Audrey Chaing:                And it changes very quickly. I mean, even if you're looking at Solidity, which is what a lot of people use for Ethereum, the syntax changes frequently.

 

Poornima Vijayashanker.:                     Yeah. Well, that also might also be a good thing, so for people who are eager to always be at the cutting edge—

 

Audrey Chaing:                Yes. It's definitely-

 

Poornima Vijayashanker.:                     ...and want to be involved.

 

Audrey Chaing:                ...cutting edge. You know what's shocking is, sometimes I talk to people, and I'm like, "Yeah, I've written a smart contract in Ethereum," and people are like, "Oh, my God," so just like this is crazy that this is like a thing, but it's so early that not very many people have done that.

 

Poornima Vijayashanker.:                     Yeah. Wonderful. Well, thank you so much, Audrey, for sharing all your expertise when it comes to Bitcoin, blockchain, as well as cryptocurrencies.

 

Audrey Chaing:                Thank you for having me.

 

Poornima Vijayashanker.:                     Yeah. That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode. Ciao for now. This episode of *Build* is brought to you by our main sponsor, Pivotal Tracker.  

Jul 30, 2018

Got a laundry list of questions that have gone unanswered when it comes to blockchain, bitcoin, and the myriad of cryptocurrencies out there?

 

Questions like the following: What’s going on with the boom and bust cycles? Are cryptocurrencies really here to stay? Are there really a myriad of applications for blockchain? And how can one get started playing around with the technology when bitcoin has such an expensive price tag, and blockchain is so challenging to develop on?

 

Well, we’re going to answer all these questions for you and more by kicking off this month with today’s Build episode that debunks a number of myths related to blockchain, bitcoin, and cryptocurrencies. In next week’s episode, we’ll share some of the cool applications that are making an impact in the market and prove the staying power of these technologies.

 

To help us out I’ve invited Audrey Chaing who is a crypto trader as well as a Blockchain analyst and consultant, and blogs on Blockchaing.  

 

Here’s what you’ll learn from today’s episode:

 

  • How to go about explaining the differences between Bitcoin, Blockchain, and Cryptocurrency in simple terms to friends and family
  • How bitcoin works with public key and private key encryption — and what is public key and private key encryption
  • Why People Think Bitcoin Transactions Are Anonymous Or For Criminals
  • What The Real Value Is Behind Bitcoin
  • Whether Bitcoin Will Replace Credit Cards And Cash
  • Other Cryptocurrencies Besides Bitcoin
  • How To Get Started Playing With Cryptocurrencies And The Blockchain

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

The Real Deal Behind Blockchain, Bitcoin, and Cryptocurrencies Transcript

 

Audrey Chaing:                            So congrats. How far along are you?

 

Poornima Vijayashanker.:                     Thank you. Yeah, seven and a half months.

 

Audrey Chaing:                            Great.

 

Poornima Vijayashanker.:                     So just 10 more weeks to go.

 

Audrey Chaing:                            Awesome, awesome. Are you ready?

 

Poornima Vijayashanker.:                     To be honest, no. Kinda spent junior's college savings on Bitcoin.

 

Audrey Chaing:                            Well, you never know. By the end of this interview, it might be totally back up.

 

Poornima Vijayashanker.:                     That is true.

                                                 

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. You're probably wondering what's going on with Bitcoin and Blockchain, the boom and bust cycles, and whether cryptocurrencies are here to stay.

                                                 

Well, in today's episode we're going to unearth some of the common myths, and in a future episode we'll dive into some of the applications to let you know what's really here to stay.

                                                 

And to help us out, I have invited Audrey Chaing, who is a crypto trader as well as a Blockchain analyst and consultant. Thanks for joining us today, Audrey.

 

Audrey Chaing:                            Thank you for having me.

 

Difference Between Bitcoin, Blockchain, and Cryptocurrency

 

Poornima Vijayashanker.:                     Yeah. So, let's first talk about what's the major differences between these three: Bitcoin, Blockchain, and cryptocurrencies?

 

Audrey Chaing:                            Sure. So there is a common misconception that Blockchain is the same thing as Bitcoin, and that's actually not true. The reason why people get confused is because they were kind of invented at the same time. So in 2009, someone named Satoshi Nakamoto...now, this is a person or a group. We don't know. They're kind of anonymous. They came out with a white paper that describe the Bitcoin protocol. And so that was how Blockchain technology was born. But Blockchain is much bigger than just Bitcoin.

                                                 

So Bitcoin is a cryptocurrency but Blockchain refers to this technology.

 

Poornima Vijayashanker.:                     Got it. And what got you interested in this?

 

Audrey Chaing:                            So basically, it has everything to do with everything I've done in my career. I studied computer science at MIT but graduated in the dotcom bust, so I ended up on Wall Street for about a decade. And then after that I founded two startups. So the technology, the finance, the startup entrepreneurial part, Blockchain kind of encompasses all those things.

                                                 

But specifically how I got started was back in 2013, I decided, "Hey, I might want to start my own companies." In order to do that, it would be good to refresh my programming skills because it had been a little while. So I took a Stanford online [MOOC 00:02:44] startup engineering, taught by [Balaji Srinivasan 00:02:47], who's pretty well known in the Blockchain space. And so our final project was to build a Kickstarter clone. And there was a leaderboard and you moved up on that by tweets and Bitcoin funding.

                                                 

And so friends and family, they're like, "Great. We want to support you. What the heck is Bitcoin?" And I'm like, "Don't worry. Just tell me in dollars and I'll trade it for you." And so that's how I got into doing that. And then I realized, "Hey, it's really volatile. I can trade this like anything else and try to make some money off of it."

 

Poornima Vijayashanker.:                     Yeah. Awesome. And so now, you are independent and you blog on Blockchaing.

 

Audrey Chaing:                            Mm-hmm. Yeah. So it's Blockchaing, and it's basically Blockchain and add a G, dot org. I just...my name actually is perfect for this.

 

Myth #1: Bitcoin Users Are Anonymous

 

Poornima Vijayashanker.:                     Yeah. Wonderful. So, on this show we love to debunk a number of myths and misconceptions. I am sure Bitcoin and Bitcoin and cryptocurrencies are just ripe for this. So, let's start with the first myth, which is Bitcoin users are anonymous.

 

Audrey Chaing:                            Yeah, it's actually pseudonymous. People have that idea because there are these wallets that are this big string of numbers and letters, but since everything is on the Blockchain you can trace at any point. You know X wallet paid Y wallet at this time, this and that. So even though you don't know who necessarily who owns X wallet or Y wallet, you know that that happened and you can trace that. And actually, law enforcement has already started doing that.

 

How Bitcoin Works With Public Key and Private Key Encryption

                                                 

Sometimes it's really easy to out yourself as well, so there's public keys and private keys. If you post your public key somewhere, then that now is associated with you. Even if you don't think anyone can track you, then maybe they can actually. But that's why there are now privacy coins where that's much more of an anonymous thing.

 

Poornima Vijayashanker.:                     Let's backtrack a little bit. What's public key?

 

Audrey Chaing:                            So, in cryptography there's a private key, public key. They're mathematically related, and they can be used to...For instance, I'm sending you an email and I don't want the whole world to see it in transmission, so what I can do is if you send me your public key and the public key's OK to share, I can take my message, encrypt it with the public key, send it over and it'll just be garbled, and then you can take your private key and decrypt it that way.

 

Poornima Vijayashanker.:                     Nice. So it's a way to encrypt signals, messages, any sort of data?

 

Audrey Chaing:                            Mm-hmm.

 

Poornima Vijayashanker.:                     OK. So let's get back then to talking about some of these myths. Now, what's perpetuated this myth that Bitcoin users are anonymous?

 

Why People Think Bitcoin Transactions Are Anonymous Or For Criminals

 

Audrey Chaing:                            So, I think people think it's anonymous because there are transactions that are wallets, but there are no names or identities necessarily associated with them. So it's a long string of numbers. However, that's not fully true at least in the case of Bitcoin because, yes, you have these numbers that are not associated with people, but you can trace the movement of funds and kind of what happened with what.

                                                 

So, if wallet X decides to send 5 Bitcoin to wallet Y, you don't know who owns wallet X, you don't know who owns wallet Y, but you do see that it was sent. And there are many ways that you can kind of out yourself by accident, therefore someone knows that I own wallet Y for instance.

 

Poornima Vijayashanker.:                     Yeah. So, another myth: Bitcoin is beyond the law and it's for criminals.

 

Audrey Chaing:                            Yeah. So there's a lot of people that talk about Bitcoin along with drug deals and things like that. There's good reason for this because there are things like Silk Road, which was a black marketplace that got shut down. But you know, having said that, the black market will always...it's been around a long time, will persist, and no matter what sort of medium you use, it'll still be there. I don't think that the levels have increased due specifically to cryptocurrency. And actually, the largest source of money laundering is the U.S. dollar.

                                                 

So there's that, but also on top of that there are a lot of legitimate companies getting very interested in Blockchain technology, not just Bitcoin, that's one thing which a lot of companies are actually invested in, but Blockchain technology as a whole, a lot of Fortune 500s, names that you would hear are investigating into Blockchain.

 

Myth #2: Bitcoin Has No Market Value

 

Poornima Vijayashanker.:                     Yeah. And we'll get into that in the next episode for sure. So, let's talk about another: Bitcoin has no value. It's not backed by anything.

 

Audrey Chaing:                            This is true. It is not backed by anything. Some people like to point to, "Well, you know, there was electricity put in, and that's proof of work, calculations." But you know what? A lot of things don't have intrinsic value like the U.S. dollar. It's just that the government says it's worth something, and we have all collectively agreed it's worth something.

 

Poornima Vijayashanker.:                     OK. So that's actually not a myth. That is true. It is-

 

Audrey Chaing:                            It is not backed by gold or anything like that, yeah.

 

Poornima Vijayashanker.:                     Got it. All right. The next one: Bitcoin is not secure.

 

Audrey Chaing:                            So, secure could mean a lot of different things. In one sense, Bitcoin is more secure because the whole...it's a distributed database, so a lot of people have copies, therefore you have no one point of attack. So in the Equifax half for instance, they were holding a lot of people's data. I know I was definitely affected. You were probably affected. But there's [nodes 00:08:15] everywhere. You can't just take down one and get everybody. You actually have to get over 51% to trick the system.

                                                 

In one case it's kind of more secure, but one thing that I do want people to understand is that we've become used to things being reversible, so if someone got your credit card number, they made a bunch of transactions, you can call your company and say, "You know what? That was not me. Can you reverse it? Can you credit me," right?

 

Poornima Vijayashanker.:                     Right.

 

Cryptocurrency Works Like Cash

 

Audrey Chaing:                            And we're all very used to that. That's not how it works in cryptocurrency. It's like cash. If someone steals it from you, it's gone. You can't be like, "Oh, can you just reverse that back."

 

Poornima Vijayashanker.:                     Right. OK. So it's basically...it's sunk cost. You're not gonna ever get it back.

 

Audrey Chaing:                            Basically, yeah, like cash.

 

Myth #3: Bitcoin Will Replace Credit Cards And Cash

 

Poornima Vijayashanker.:                     OK. Next myth: Bitcoin will replace credit cards and cash.

 

Audrey Chaing:                            So, I don't think most people think that is the point of Bitcoin. So, the point of Bitcoin is that it's a store of value, and it's done a good job doing that. Having said that, there is potential for other cryptocurrencies to potentially be more of an everyday transactional...you go buy your coffee with it. Some include maybe Bitcoin cash or Litecoin. They're a little faster, a little cheaper.

                                                 

But one thing to keep in mind right now is that scalability is a huge problem. So if you're talking about these Blockchain systems, right? We're doing eight to 30 transactions per second, credit cards handle about 5,000 transactions per second, so it's like a really big difference.

Bitcoin Energy Consumption Explained

 

Poornima Vijayashanker.:                     Yeah. So actually, that brings up a good point. A lot of people have said that given how intensive each transaction is, Bitcoin can be a huge energy consumer. Is that true?

 

Audrey Chaing:                            Yeah, I think that's...there's people that have been running mining rigs in really cold places and it heats their home.

 

Poornima Vijayashanker.:                     Oh, OK.

 

Audrey Chaing:                            Yeah, which is kind of clever. So yes, there is an energy cost. People are aware of it. There are a lot of other consensus mechanisms. So proof of work is just the first one, right? If we think about email when it first came out. You can complain, "Oh, this is not efficient," or whatever, but it was the very Version 1, so that's Bitcoin and proof of work and these whole calculation things and using up electricity.

                                                 

But there are a lot of other ways to reach consensus. Examples include proof of stake, and there's a lot of other ones in the works now where you're not actually calculating. And there's actually an interesting idea of what if you did proof of work but it actually did something? Because right now you're doing calculations but it's not really adding to anybody. If you did almost like a Mechanical Turk in that we're doing calculations but it's actually helping us solve something, then you could be doing two things at the same time.

 

Myth #4 Bitcoin And Blockchain Are The Same

 

Poornima Vijayashanker.:                     Got it. All right. And last one, which we talked about in the beginning: people think Bitcoin is the same as Blockchain.

 

Audrey Chaing:                            Mm-hmm. Yeah, and I understand why because in the media people usually talk about Bitcoin because of the price moves. People are interested in that, right? A lot of people haven't even heard of the term Blockchain, and when they do they think it's the same thing. But yeah, Bitcoin is one cryptocurrency. There are now over 1,500 cryptocurrencies. They are all using the Blockchain technology, but it's very possible to work with Blockchain and not even have a currency.

 

Poornima Vijayashanker.:                     OK. So what is the Blockchain technology, then?

 

Audrey Chaing:                            So that's basically...if you've heard of distributed ledger—

 

Poornima Vijayashanker.:                     Mm-hmm.

 

Audrey Chaing:                            That might be driving you. But at the very very base, it is a large database that everyone has a copy of.

 

Other Cryptocurrencies Besides Bitcoin

 

Poornima Vijayashanker.:                     Got it. All right. So, what other cryptocurrencies are out there?

 

Audrey Chaing:                            There are a lot, and I would recommend if you wanted to look into them, CoinMarketCap has a list of all of them basically. But some of the ones you may have heard of, like Ethereum is a really big one. Some quarked off of Bitcoin so there's Bitcoin cash, Bitcoin gold. There's any number of coins that exist and sell through ICOs, which I think we'll talk about later.

 

Poornima Vijayashanker.:                     Yeah, great, thank you. So, for our audience out there who...they're gonna want to arm themselves and be able to tell fact from fiction, how can they explore Bitcoin, Blockchain and cryptocurrencies and know that they're getting the right information?

 

Audrey Chaing:                            Yeah, it's really hard because there is information out there but it is hard to say what's real and what's not, and the people really deep in the community, you look at things like Reddit and Twitter, but if you're just starting out...This is actually why I started writing because I didn't think there were very many good resources out there. But one that's quite good is Blockgeeks.com. They do introductory stuff all the way down to explaining zk-SNARKs.

 

How To Get Started With Cryptocurrencies

                                                 

So there's stuff out there. I think the best way to get learning is actually to just go buy some cryptocurrency, because once you have something on a line, you'll want to learn how it works.

 

Poornima Vijayashanker.:                     Nice. And hopefully there's something that's cheaper than Bitcoin that we can all purchase.

 

Audrey Chaing:                            So here's another thing...another common misconception is that you need to buy one coin at a time. You really don't. You could do like .001 on any of these things.

 

Poornima Vijayashanker.:                     Oh. Very cool. Well thank you so much, Audrey, for helping us bust all of these myths and sharing your expertise on Bitcoin, Blockchain and cryptocurrencies. I know our audience out there is gonna get a lot of value out of this. If there's a question or a myth that we didn't answer today, be sure to let us know what it is in the comments below this video. We'll be sure to answer it. And subscribe to our YouTube channel to receive the next episode, where Audrey and I will talk about a number of applications that are hopefully going to stick around that you can get involved in when it comes to Blockchain and cryptocurrencies.

                                                 

Ciao for now.


This episode of *Build* is brought to you our main sponsor, Pivotal Tracker. We'd also like to thank our Platinum Patreon Patrons: Corgibytes, the Develop[Her] Show, Dee Gill, and Jamie Hand.         

Jun 20, 2018

In the last episode of Build, we exposed a number of myths about current augmented reality and virtual reality trends, and how new products are evolving by learning from predecessors like Google Glass.

 

If the episode piqued your curiosity and left you wondering how you can get started or where you can find more resources, today’s episode is for you!

 

Rose Haft the CEO and Founder of Lumenora is back. Together we’re going to share some the applications of augmented reality and virtual reality that are here to stay, and how you can get started tinkering with the technology.

 

You’ll learn:

 

  • How 200+ companies are using augmented reality and virtual reality
  • Why augmented reality and virtual reality isn’t just limited to industries like gaming but others like healthcare are adopting it
  • The software tools and resources that are available today — making it easier for early adopters like you to start tinkering and developing applications!

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

Episode Transcript

Poornima Vijayashanker:           In the previous episode of *Build*, we shared some of the most common myths and misconceptions related to augmented and virtual reality. If you missed the episode, I've included a link to it below. In today's episode, we're going to do a deeper dive into some of the applications of augmented and virtual reality, and talk about how you can get involved and your hands dirty using the technology. So, stay tuned.

                   

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker, the founder of Femgineer, In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. In today's episode, we're back with Rose Halt, who is the CEO and founder of Lumenora, and we're gonna be doing a deeper dive into augmented and virtual reality, talking about some of the applications, as well as how you can get started using the technology. Thanks again for joining us Rose.

 

Rose Haft:               Yeah, thanks for having me.

 

How 200+ Companies Are Using Augmented Reality And Virtual Reality

 

Poornima Vijayashanker:           Yeah, so, let's go ahead and dive in. Last time, we talked about some of the myths. This time, I want to talk about some of the applications, so maybe you can walk us through what you're seeing in terms of use cases for AR and VR.

 

Rose Haft:               Yeah, so even though people think that AR and VR is done. We talk about on the last episode, there are over 200 companies who are using it today.

 

Poornima Vijayashanker:           Wow.

 

Rose Haft:               Which is pretty significant. They're using it to help reduce errors in production lines, helping to provide instructions where people might not have a lot of experience in a job, and helping to make sure that everyone is doing what they're supposed to do when they're supposed to. So, a lot of optimization.

 

How Augmented Reality And Virtual Reality Is Helping The Healthcare Industry

 

There are companies starting to work on Healthcare, trying to help to improve the patient-doctor experience, and that's another prominent one that's starting to take off. And then also in gaming. I'm sure you guys have all seen a lot of gaming videos of your friends on the internet, and so that's another one that people really like, and enjoy.

 

Poornima Vijayashanker:           Yeah, I think the gaming one has been going on since the 90's, right? So, that's definitely one that's sort of here to stay. So, are there any other applications? I know I've seen some stuff around simulating things like surgeries, anything else that comes to mind?

 

Rose Haft:               Yeah, absolutely. So, on that surgery front, being able to train people and have the opportunity to practice something, before doing it in real life has been known to increase the likelihood of success. And so, people who are going into surgery it's really helpful to know the doctor has practiced a couple more times on a specific patient with similar body types, and expectations, and unique scenarios before they go in for a dangerous surgery. So we're really starting to see them being used to help humans make fewer errors in general, which is really interesting. As we're increasing the robotic technology to create machines, that can do things perfectly, we're also helping humans to do things perfectly.

 

Additional Applications And Use Cases For Augmented Reality And Virtual Reality

 

Poornima Vijayashanker:           Well, I don't know if perfection is necessarily the goal, but that's good to hear that that's what they're aiming for. So, are these just trends, or are there more applications that you see coming down the pipeline?

 

Rose Haft:               Yeah, these definitely aren't trends. There are people who are starting to get to know and understand, and the right tools are being built now, from software and the hardware perspective, that will allow people to start adopting them. Today, I just had an interview with somebody who has tried using it in a business setting, and there's still some issues that they're running into even with billions of dollars being put into developing headsets. And so, as an engineer, I'm trying to...they say laziness is one of the virtues of being an engineer, and trying to do things right the first time, so as a startup, after people have put a lot of money in, we're able to take a hard look at some of the reasons why people aren't able to use them, and be able to put them design to prevent those flaws, and make them more adoptable.

 

Poornima Vijayashanker:           Yeah, so it's gotta be a really high cost of production right? And for people in the audience who want to play with the technology, it costs like several thousands of dollars just to get a headset, and then of course there's a software being developed, so how are you seeing the cost come down, or how companies trying to bring down those production costs?

 

Rose Haft:               Yeah. So, companies like mine know the importance of these technologies. I've spent time in India and Peru, and I've seen how much a lack of similar tools has really made an impact on the world. And so, we're designing specifically to have a headset that can be used as functional, works great, and has a price point we can't fully disclose that yet, but ours won't take thousands of dollars to actually use and integrate with. We don't need to buy an expensive laptop in order to work with it. Our will be able to work out of the box, for about the cost of a cell phone, what you'd find now.

 

Software Languages And Platforms Compatible With Augmented Reality and Virtual Reality

 

Poornima Vijayashanker:           And what about the software that goes in it? Since, nothing yet is standardized, are company's thinking about this? How can our audience develop applications?

 

Rose Haft:               Yeah. So, Android is probably one of the easiest ways to get started. Android, if you know how to build apps, and there are a lot of tutorials, you can start to integrate with some of the same systems that will work on a phone, as well as a headset like ours. Most headset companies do integrate in that ecosystem. So, that really helps. Otherwise if you're more familiar with HTML or CSS, you can go to aframe.io, and there's also a Slack channel where you can get help learning how to use HTML and CSS to build applications using just regular web browser technology. It's a little more technical than that, but it's a good place to get started. And then, also Unity is another big skill that people can...another software platform that people can use in order to get started.

 

Poornima Vijayashanker:           Oh, great. So, it's good to see that this same software platform is being leveraged, and it's not new languages or new frameworks that people have to adopt, except for maybe a couple things, like you mentioned, Unity.

 

Rose Haft:               Yup. So, I know there's a lot of different software languages to learn, and that can be very overwhelming. For the most part, all of them will talk to each other in some sort of way. And so, if you are wanting a specific language to write in, usually C or C++ is pretty universal, it'll allow allow you to plug in with one platform or another. Java, as well.

 

How To Deploy Software Application On Augmented Reality and Virtual Reality Headsets

 

Poornima Vijayashanker:           Yeah, and what about the actual way to sort of put the application into these headsets, is there...is it all internet enabled? How does that work?

 

Rose Haft:               Yeah. So, every headset will have its own SDK that you can access and download, typically through the internet, and something you have to work directly with the company, and so it really depends on what you want to use. Android tends the easiest, because you can buy phones for less than $100, and you can start building and testing with that. And a lot of them are really functional and capable.

 

Poornima Vijayashanker:           Yeah. Maybe you can help us break down what SDK is.

 

Rose Haft:               Oh yeah. So, SDK is our software development kits, and so it'll have standardized code that will help you to talk to the hardware, or talk to other pieces of software, to make sure everything is compatible. For instance, with the different display systems, there are specific ways in which the display will be changed, so it has a coherent image, and that will be part of an SDK.

 

There’s A Market Need For More Software Infrastructure To Support Augmented Reality And Virtual Reality Products

 

Poornima Vijayashanker:           So, to draw an analogy to when mobile devices were first coming out. A lot of these platforms had emulators that you could put on your computer so that you didn't have to have every single device. You didn't have to have an Android phone, and a iPhone. Are there similar emulators being developed?

 

Rose Haft:               There should be. I haven't developed specifically for other headset companies. I'm trying to keep the IP stuff differently, but Android does a really good job with emulators, and it should work standardly, and each headset company will have an easy way to integrate, make it look the same on their headset, as well.

 

Poornima Vijayashanker:           OK, so maybe a market opportunity for some enterprising audience member out there.

 

Rose Haft:               Yeah, absolutely.

 

Poornima Vijayashanker:           But certainly, that opens the door for testing. I'm sure there's a lot of testing frameworks out there as well.

 

Rose Haft:               Yup.

 

Resources To Help Early Adopters Like You Get Started Tinkering and Building Augmented Reality And Virtual Reality Applications

 

Poornima Vijayashanker:           Wonderful. So, for those that want to get started, you already mentioned a few resources. Do you have any other resources out there that you can share with our audience?

 

Rose Haft:               Yeah I think if you're wanting to get started, it is really great to you find a mentor, or somebody else in the space who has worked, joined Slack channels and communities, and also talked to people who have been in the industry for a while, and find out what's worked, and what hasn't worked, what they need help with, and a lot of people are very willing to take the time to share knowledge, and information to help you move forward and get started. So, never feel ashamed to clarify, to ask for help, and to make sure that you're getting started and doing things in the best way.

 

Poornima Vijayashanker:           Yeah, wonderful. And we'll be sure to share those links with our audience out there. Thank you so much, Rose, for coming on the show today.

 

Rose Haft:               Yeah, thank you for having me.

 

Poornima Vijayashanker:           That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive our next episode, and share this episode with your friends, your teammates, and your boss. And a 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.



Jun 20, 2018

Remember Google Glass? Yeah it didn’t quite take off did it… It was just one example of a failed attempt to productize virtual reality. Its short lifespan along with a number of other products since the 90s has probably got you thinking that there is just a lot of buzz around augmented reality and virtual reality.

 

While the technologies seem exciting, you might be on the fence when it comes to investing your time and energy exploring the technology.

 

It doesn’t help that the cost associated with production and acquisition of the devices, and the limited toolset have made them both a challenge to tinker with.

 

But I have some good news for you: much of the market is changing! There some great applications that are disrupting businesses and industries like healthcare, and a number of resources making it easier to build.

 

In today’s Build episode we’re going to dive into the major differences and similarities between augmented reality (AR) versus virtual reality (VR). Then we’ll debunk the many myths around AR/VR. And in next week’s episode, we’ll share some of the cool applications that are coming on the market and a number of resources to help you get started!

 

To help us out, I’ve invited Rose Haft who is the CEO and Founder of Lumenora.

 

As you listen to today’s episode you’ll learn the following:

 

  • What are the major differences between augmented reality (AR) versus virtual reality (VR)
  • Why products like Google Glass failed to take off and what new products are learning from its demise
  • Why you haven’t heard from companies that are actually making a mark
  • Why big companies like Facebook are investing in a more long-term strategy
  • How Rose Haft got introduced to AR/VR and how her company Lumenora is approaching the market

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

Episode Transcript

Poornima Vijayashanker:        Wondering what all the buzz is about when it comes to augmented reality and virtual reality? Well, stay tuned to find out more. Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. You've probably heard that augmented reality and virtual reality are the way of the future and maybe you're reluctant to join all the buzz. Well, I don't blame you. In today's episode we're going to debunk a number of myths and misconceptions related to augmented reality and virtual reality and then in the future episode we're going to talk about some of its applications. To help us out, I've invited Rose Haft, who is the CEO and founder of Lumenora. Thanks for joining us today, Rose.

 

Rose Haft:          Yeah, absolutely. Thanks for having me.

 

Are augmented reality and virtual reality the same?

 

Poornima Vijayashanker:        Yeah. Why don't we just get started by introducing to our audience, in case they're not familiar, what exactly is the difference between augmented reality, AR, and virtual reality, VR?

 

Rose Haft:          Absolutely. Yeah, so augmented reality and virtual reality are a way to have a computer interface that's very close to the eye that allows for there to be a different way to interact with the computer than what you're used to today. Augmented reality makes it possible to see what's happening in the real world that everyone else can see, with a little bit of image overlay that will help to display text, or data. If you've heard of Magic Leap, it'll also help to display holograms and things that look very lifelike. The difference between augmented and virtual reality is that in virtual reality you have your own environment and you're not able to access any of the exterior world, so you're completely immersed inside of that environment. It makes it a little bit more difficult to see what's happening elsewhere, but there are a lot of really useful applications for being fully immersed and reasons why people really enjoy using it.

 

Why Rose Haft (CEO and Founder of Lumenora) Got Interested In Augmented And Virtual Reality

 

Poornima Vijayashanker:        Maybe you can tell us what got you interested in augmented and virtual reality and then we can talk about why you decided to start your company.

 

Rose Haft:          I got interested in augmented and virtual reality in high school. I knew I wanted to be an engineer and I had an opportunity to work as an intern at one of the local prototyping facilities. At that facility we were working on building advanced headsets for the military. I really had a chance to see how having a hands-free tool that could be worn can really do anything from help to save lives, as well as help to communicate silently between people. I thought it was really interesting, a different way of interacting in technology, than had ever been there before.

 

Why Building Headsets for Augmented And Virtual Reality Was Challenging And Led To Limited Product Adoption

 

Poornima Vijayashanker:        What inspired you to start your company Lumenora?

 

Rose Haft:          Yeah. After working at several companies, including working at Meta helping to design the Meta II, I realized that there were a lot of logistical and engineering reasons why people weren't able to build the headsets that I felt like were ideal and also why those reasons are also part of the reasons why people don't want to adopt them. I was studying at Stanford a little bit of biomedical engineering and how to use sensors, like you would in surgery, and I thought it'd be great to incorporate them into a headset. Again, there were logistical reasons to doing that. After I found a partner company that could help solve one of the major problems in the area, and with my unique background in design, knowing how to design things differently, was really a great match to build something that is more advanced, more capable, and people actually want to wear it and use it.

 

How Businesses Are Applying Augmented Reality and Virtual Reality To Their Business Processes

 

Poornima Vijayashanker:        Yeah. Do you mind sharing the application of what you're working on?

 

Rose Haft:          Yeah. Right now, we're kind of fitting into the maintenance repair and operations space. There are over 200 companies internationally that are using it to do things like supply chain management, companies like BMW who build cars find it useful to make sure they're choosing the right parts and putting them together in the right way, and making sure that their quality process, you don't have to go back and double check work, they're doing it right and the first time.

 

Poornima Vijayashanker:        Got it, so it's really a training platform—

 

Rose Haft:          Yep.

 

Poornima Vijayashanker:        For people, yeah.

 

Rose Haft:          We're adding in extra features and we're doing some fun and cutting edge things that will help to even more improve those industries, especially training. In order for people to learn skills, and trade crafts, and the majority of Americans who hold the same job title need to go to school to learn these things, and how to work on specific machines, and machine types. We'll be integrating a real-time training system where you can learn a new skill or a craft in real-time and you don't need to have the several years of school, so we'll be able to adopt robots faster, and self-driving cars, and those sort of things.

 

Why People Have Been Reluctant To Adopt Augmented Reality And Virtual Reality Products

 

Poornima Vijayashanker:        Very nice. You mentioned early on that there's been a lot of reluctance to adopting this new technology, AR and VR. Why is that?

 

Rose Haft:          There's a lot of reluctance for a variety of reasons. People haven't found that they're stylish enough, or cool enough, and also really haven't found the benefits. They've really only seen the detriments and pullbacks as far as feeling like their security is being threatened or their privacy would be threatened because of the ability to record and take in information. I think the use cases are just now starting to be developed. One of my favorites is there's a 3D graphing app, and so you can use it for calculus. I know we're doing some fun and cutting edge things that really will help the average everyday person meet typical goals and those sort of things and it'll make it better and easier to adopt once those use cases are there.

 

Poornima Vijayashanker:        Yeah, and we'll hold that thought. We're going to dive into those use cases in the next episode. There's also a lot of myths being propagated right now and I think one of them, because of the lack of adoption, people just are saying that AR/VR is dead and there's not much going on. Is that true? Are people not building these headsets anymore? Are they no longer investing in the technology infrastructure?

 

Rose Haft:          Yeah, that's absolutely not true—

 

Poornima Vijayashanker:        OK.

 

Rose Haft:          Whatsoever.

 

Poornima Vijayashanker:        Yeah.

 

Why You Haven’t Heard From Companies That Are Actually Making A Mark In The Augmented Reality And Virtual Reality Market

 

Rose Haft:          There's still a lot of investing to try to find the right solutions and the right designs, so people can actually wear them and adopt them. I know companies like mine have tried to stay as much out of the media as possible, because people have spent billions of dollars trying to find the right solution, and as soon as you put something out there, people feel like they can help themselves. Working on companies like mine who are working on very proprietary things, or making sure that they're developing and building strength, and so we're doing a lot of things in the background that can't be seen quite yet, and eventually will come to mainstream once we really feel like we'll be able to offer something that people really want.

 

Poornima Vijayashanker:        Are there any other myths that are being propagated, aside from the one around it being dead?

 

Rose Haft:          Yeah. People think they're ugly.

 

Poornima Vijayashanker:        Right.

 

What Led To The Demise Of The Google Glass And How New Products Are Learning From Its Failures

 

Rose Haft:          The glass hole is the scared term that's used and we're building something that will be a lot more sleek and stylish and have a lot more options in order to wear it and have it look different. I think the use cases that we're developing will be cool enough and necessary enough that people will want to adopt it anyways.

 

Poornima Vijayashanker:        Yeah. You're seeing a lot of friction just in terms of the adoption because of change of behavior because people don't see this as prevalent, so that makes sense. There's already a number of big players in the market today. Facebook has Oculus. Google, like you mentioned, used to have Google Glass. What exactly is the difference between some of these big players, and maybe what you're building, and what you see other people building?

 

Rose Haft:          The main differences between each of the companies are the form factor and the tech-

 

Poornima Vijayashanker:        OK.

 

Rose Haft:          The technology that's being used to develop them. There are several different optical technologies that are used and those really make a big difference in what a headset looks like. Most of the virtual reality headsets have a screen like your cell phone that's in front of the eyes and there are lenses that help you to see an image clearly. That's one type of technology. Companies like Google have something called a beam splitter inside the Google Glass and while it's a smaller form factor, it has limited capabilities. Companies like Vuzix have something called a wave guide that has limitations around it as far as the brightness of the image, and the amount of the screen that's able to be filmed. That might be a very technical explanation, but-

 

Poornima Vijayashanker:        That's OK, we have a very technical audience.

 

Rose Haft:          Well, this is...I'm hoping to share-

 

Poornima Vijayashanker:        Yeah.

 

Rose Haft:          Relevant information. The biggest difference between each of the systems is the way the computer image is generated so somebody can see it. Those are really the big three ones that you see right now. Meta has a direct reflection. I helped to come up with that design. I built a...Meta hired me because I had built a prototype and they thought my prototype was cool and they hired me on to help with that.

 

How You Can Separate The Fact From Fiction Around Augmented Reality And Virtual Reality

 

Poornima Vijayashanker:        Yeah, that's awesome. When our audience out there is trying to evaluate between fact and fiction when it comes down to augmented reality and virtual reality, what would you say to kind of arm them?

 

Rose Haft:          Yeah. In order to help understand the difference between fact and fiction in an augmented and virtual reality environment, a lot of companies are going out and giving a lot of information and showing pictures and those sort of things, without actually having a product. It's really important to look at how close is whatever is seen actually able to go out and be used in the world.

 

Also, companies that have a lot of hype, where they are getting the most press and it seems most exciting, aren't necessarily the ones who are building the most useful tools. I think it's kind of...Companies can be like people. If they're kind of showing off a whole lot, but not really putting anything behind the game, then there's probably a problem with it.

                   

Otherwise, I encourage your audience, everyone out there, to really learn the science behind what's happening. Part of the reason why we've been able to do things differently at Lumenora is because I knew the science, and I was able to go through and do things differently, because I knew the limitations of the methods trying to be implemented. Science, and also fact check, and double check if something's actually ready, or usable, or wearable.

 

Why Big Companies Like Facebook Are Investing In A More Long Term Strategy Around Augmented Reality And Virtual Reality

 

Companies like Facebook who have a five-year plan in order to build something and they've talked about that at F8 and those sort of things, they haven't necessarily released anything publicly to show what they're working on, and those are the companies that are more genuinely putting an effort into creating something useful before they go out and get credit for something they've not yet done.

 

Poornima Vijayashanker:        Yeah. No, that makes a lot of sense. Well thank you so much, Rose. This has been really eye opening for us. I appreciate you coming on the show and sharing.

 

Rose Haft:          Absolutely.

 

Poornima Vijayashanker:        Yeah. Rose and I want to know, do you have any questions related to augmented reality and virtual reality? Let us know what they are in the comments below. 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 do a deeper dive into talking about some of the applications on augmented and virtual reality. Chow for now.

                   

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

 

Jun 18, 2018

All this month we’ve been talking about remote working as it relates to recruiting, training, and retaining remote works. We started out by tackling how to recruit remote workers for people who may be new to it. Then we discussed how to train, hold accountable, and retain remote workers.

 

In the final episode for this month, we’re going to address a BIG concern that often holds people back from recruiting and managing a remote team: the nature of the work that needs to be done.

 

Most hiring managers we talk to are OK with hiring a virtual assistant to handle day-to-day tasks. But when it comes to a mission critical project like launching a startup or handling very important client or customers, going remote seems too risky, and people opt for hiring a team on-site.

 

In today’s episode, we’ll talk about why it boils down changing your process depending on the nature of work your remote workers are doing.

 

Holly Cardew the Founder of Pixc is back to help us out. Holly has grown and scaled her team across Australia and Asia. And has done so in a number of job functions spanning both the business side with roles such as virtual assistants and marketers, to the technical side hiring software developers and designers to build the product.

 

As you listen to today’s episode you’ll learn:

 

  • How to manage a remote team that is working on a mission critical project
  • How customers and clients benefit from a team of remote workers
  • Why facetime is still important for remote teams—especially when kicking off a project
  • How to facilitate facetime amongst remote workers
  • A simple first step for people who are on the fence about hiring remote workers

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## What A Remote Team Needs To Be Successful When Working On A Mission Critical Project Transcript

 

Poornima Vijayashanker:        In the last two episodes of *Build*, we shared a lot of the benefits of remote working. We also shared some best practices when it comes to recruiting and retaining employees and the processes you want to put in place to keep everybody productive.

                   

In today's episode we're going to share how these processes will change depending on the nature of work so stay tuned.

 

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.

                 

We're continuing our conversation with Holly Cardew who is the CEO and founder of Pixc on remote working. Thanks for joining us Holly.

 

Holly Cardew:       Good to see you again.

 

Poornima Vijayashanker:        Yeah. Every episode of *Build* is inspired by amazing audience members like you, sharing your experiences and asking insightful questions. Today's episode is also inspired by an audience member, Kai. I want to start by reading an email that Kai sent me because I think it could help many of you who are out there.

 

How to manage a remote team that is working on a mission critical project

                   

Kai wrote, "Hi Poornima, I've been following your show since the pilot episode with Ben Congleton on building a remote team and recently caught the one you did with your team mate Megan as well. Thanks for revisiting this topic of remote working over the years. One thing I've been curious about is how processes change when you're managing a critical project versus a normal day to day? I know for things like startups, or mission critical projects, coordination appears easier when everybody's in the same location. I say "appears" because it can also be a huge distraction. What do you see are the trade offs and how does a remote team dynamic change between a critical project versus normal day to day tasks? Sincerely Kai."

                   

This is a great question Kai, and Holly and I are going to tackle it. So, if you're watching this episode, thank you for writing in. OK Holly, let's start with Kai's first question, which is, what are the trade offs when it comes to these mission critical tasks versus sort of the day to day?

 

Have remote workers be within a few time zones for mission critical projects

 

Holly Cardew:       I think mission critical tasks, you really need to understand what needs to be done and stick to that goal and that time zone. Also, understand that other people, aren't maybe in different time zones and you may need to stay up a bit late or go to bed, you know, I mean may not go to bed till 5 am. Whereas day to day tasks, it doesn't really matter when they happen in the week.

                   

For us, what we've really done is we've kept all our tech and product in Europe. So they're not in the same location, but they are in a similar time zone, so the time difference is really 4-5 hours, five hours max. Which allows everybody to communicate, but I think it can be beneficial, again to have somebody in another location in case there is a customer issue with the technology side.

 

Categorize tasks as asynchronous versus synchronous tasks to help remote workers collaborate

 

Poornima Vijayashanker:        Yeah. So what we did early on was actually break this up into asynchronism, what we like to call sort of those day to day tasks that people can do whenever they have availability, and then synchronism, where it's like you said, something that's customer facing, something that's critical, or something that requires a lot of coordination and figuring out that 3-5 hour time difference where everyone's kind of, be in the same day versus you have a problem, someone's asleep, you don't necessarily want to wake them up, right?

                   

If it's a customer facing issue than it can be a challenge, but I also like what you said about having people in different time zones in case it's a customer issue and then you've got more hands to kind of help out over the various time zones.

 

Holly Cardew:       Definitely.

 

How customers and clients benefit from a team of remote workers

 

Poornima Vijayashanker:        Do you have any, do you have a specific example you'd like to share with us?

 

Holly Cardew:       So as I mentioned, we definitely have taken product in Europe. We do have a project manager in the Philippines but that's OK because she understands that the rest of them are in that time zone, so she will work with that time zone. For our content and marketing, it's kind of, Europe but Western Europe and then flows over into America. That works absolutely fine.

                   

There's about, maximum there's eight hours difference, with social media included but they don't mind that because they've just set a time, each week to get the tasks done, but as you said, it's tasks that sort of come and flow. You don't need to do it at a certain time, it's not critical that you know, our social media post went up one hour difference, doesn't make that much difference to us as a B to B software company, but I think for customers, so customer service is really important because customers can not wait 12 hours. They can't wait eight, they need a response within 20 minutes.

 

Facetime is still important for remote teams—especially when kicking off a project

 

Poornima Vijayashanker:        Yeah. Now I will say that even aside from the time zones, another thing that I've found helpful is when you're kicking off a project, or you do feel like it's something really mission critical, it can be helpful to have people at the start of the project, all working together. Early on I will do either a retreat or maybe coordinate with some subset of the team, do you do anything like that at Pixc?

 

Holly Cardew:       We haven't yet. We've actually, we're talking at the moment about having our first meet up. Somewhere in Asia, so sent out a Google form with potential dates of what would work, but I think it would be really valuable for people. If you are located closely together, what we will do is try to meet up at conferences.

 

Poornima Vijayashanker:        Oh perfect.

 

Holly Cardew:       Or, you know other events, or you know if I'm traveling to Indonesia I'll try and meet up with a team member, but for us we haven't yet done the in person thing yet.

 

Poornima Vijayashanker:        Yeah. I think it's also good that you said you meet up with your employees, right. So, even if it's just a one on one or kind of a smaller group getting together that can be really valuable.

 

Holly Cardew:       Yeah, I've also said to them, like give them a budget to travel too. So if there's a lot of them in Asia, it's quite cheap to travel within Asia, so they could meet up for a dinner or lunch.

 

Poornima Vijayashanker:        Oh, great.

 

Holly Cardew:       So it doesn't necessarily mean it's just for the project, it's again, links back to the culture, because if you create a good culture and they have a social gathering together, then when they do go away they sort of understand each other a bit more.

 

Poornima Vijayashanker:        Right and it stills helps to kind of elongate that process and they feel like they're part of team and not just somebody working somewhere in some part of the world.

 

Holly Cardew:       Yeah. Definitely.

 

A simple first step for people who are on the fence about hiring remote workers

 

Poornima Vijayashanker:        Wonderful. Any final words of wisdom for our audience out there when it comes to recruiting remote talent and retaining them?

 

Holly Cardew:       I think when I speak to people and they're like I've never hired someone remote, what should I do? I think the first step is having a virtual assistant for yourself. So those tasks that you do every single day, that you could pass to someone else, just try it. Have someone 10 hours a week, or even five hours a week so it's one day a week, doing some of those tasks and you'll soon build a culture that works for them.

                   

The other thing is I would really think about them as not outsourcing or part of someone else's company. I stick with hiring individuals and not agency's or outsourcing companies. Then I send them birthday cakes and cards just because it makes them feel included in the bigger vision and bigger company and picture rather than just doing a task at hand.

 

Poornima Vijayashanker:        Oh yeah, they're definitely contributing to the overall company so that's good. That's good that you recognize them. Well these are all great tips Holly. Thank you so much for joining us.

 

Holly Cardew:       Thank you.

 

Poornima Vijayashanker:        That's it for this week's episode of *Build*. Be sure to share this with your friends, your teammates and your boss, if you are thinking about putting in place a remote working culture. Be sure to subscribe to our YouTube channel to receive the next episode. Ciao for now!

                   

This episode of *Build* is brought to you by our sponsor PivotalTracker.

 

Jun 11, 2018

In last week’s episode of Build, we dove into the benefits and best practices around recruiting remote workers. But as you’ve learned from last month’s Build episodes, it’s not enough to hire talent, you also need to onboard new hires by training them!

 

Training someone to be on a remote team might seem like a challenge since they aren’t sitting next to you. Those who are new to setting up a remote team think that training face-to-face is just easier because you can answer questions as they come up. And it may seem easier when it training multiple hires. But rest assured you can train remote workers, and in a way that scales as you hire multiple people at once.

 

In today’s episode, we’re going to share a number of proven strategies that have worked across job roles.

 

Once you’ve trained your remote workers, you might be wondering how to hold them accountable and retain them long term. Don’t worry, we’ve got you covered ;)

 

We’ll be share fool-proof techniques for holding remote workers accountable and how to retain them long-term.

 

One last thing to keep in mind—there is a difference between a remote-first versus a remote-friendly company. If you’re not familiar with the difference, we’re going to dive into it and talk about how it can impact long-term retention of your remote workers.

 

Holly Cardew the Founder of Pixc is back to help us out. Holly has grown and scaled her team across Australia and Asia. And has done so in a number of job functions spanning both the business side with roles such as virtual assistants and marketers, to the technical side hiring software developers and designers to build the product.

 

As you listen to today’s episode you’ll learn:

  • Why remote working doesn’t work for some companies and cultures—impacting long-term productivity and retention of remote workers
  • Best practices for training and onboarding remote workers
  • How to hold remote workers accountable
  • Why you need a communication escalation framework to keep your remote workers productive
  • How to coach remote workers to be more resourceful

Check out these additional resources on remote working:

If you have a remote team, how do you train, retain, and hold your employees accountable? Let us know in the comments below.

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

 

## Proven Strategies For Training And Retaining Remote Workers Transcript

Poornima Vijayashanker:        In the previous *Build* episode, we shared a number of strategies for recruiting remote workers. If you missed the episode, I've included the link to it below. Now, it's not enough to just recruit employees. You've also got to train them, hold them accountable, and retain them. In today's episode, we'll dive into how to do this, 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. As an employer, once you've recruited remote workers, you need to train them, you need to hold them accountable, and of course figure out ways to retain them. If you're wondering how, Holly Cardew, who's the CEO and Founder of Pixc, is back. Today we're going to be sharing a number of strategies on how to do this. Thanks for coming back, Holly.

 

Holly Cardew:       Thanks for having me again.

 

Remote-first versus remote-friendly

 

Poornima Vijayashanker:        Yeah. OK, Holly, one of the biggest misconceptions around retaining remote workers is this idea of remote-first versus remote-friendly. Maybe you can explain what each of these are and how they impact retention.

 

Holly Cardew:       Sure, so the difference...Well, what remote-first is means that everybody is remote. There is no head office. There is no main office. Everybody can work from home. They could work in a coworking space or a café.

 

Remote-friendly is that there is essentially an office, and then the office allows you to be at home or at the office when you would like. We've never had remote-friendly. We've always been remote-first.

 

Why remote working doesn’t work: communication and collaboration breaks down with remote-friendly

 

But the issue I see with remote-friendly is that there is a lot of miscommunication, because everybody is...You can either choose to be involved in the culture and be at the office, or you can be at home. It's kind of a little bit warped, whereas remote-first, because we were remote-first, we had to build a really strong culture from the beginning. There's no thing that I was at the office, or I was at wherever, a space, with three employees and not the other 20. That's where I think in terms of retaining, it's just really important to build a strong culture either way, but there is a little bit of miscommunication in the remote-friendly one.

 

Poornima Vijayashanker:        Yeah. Do you think people feel left out maybe?

 

Holly Cardew:       Yes, definitely. Well, they may or they may just not want to get involved, which therefore impacts the team because the team feel like...The team who are in the office feel like they're doing more, and the person at home may not be.

 

What you need in place before you train remote workers

 

Poornima Vijayashanker:        Got it. OK. We also know that in any company, in order to retain employees, you have to train them, but it can be a challenge to train people when they're not right in front of you. What are some best practices when it comes to training remote workers?

 

Holly Cardew:       It's so important to document. At the beginning, I didn't document. I would get on Skype or Google Hangouts, and I would tell the same person the same thing. I realized that I was repeating myself.

 

Our best practice is really to document, but also make everybody responsible for documenting.

It's not my job to write everybody's roles. I always tell the next person I hire that they're going to be responsible for the next team member that joins. They need to keep their own documentation.

 

We've also started Google Sites, so we have Google Sites which also connects to Google Drive and Google Documents, but that place is like...Google Sites is really the place for us where we can talk about the culture, the values, and the missions of the company, but then have all the documentation in there. It's a one, sort of essential portal.

 

Best practices for training remote workers

 

Poornima Vijayashanker:        Nice. Then what about when it comes to actually training people?

 

Holly Cardew:       It depends on what team they're in. We usually have an onboarding process with their team lead, whether it's marketing or customer service or engineering. Then we have a weekly team meeting. They'll have an onboarding session, but we have check-ins, more check-ins I would say at the beginning than further on down the track.

 

Poornima Vijayashanker:        Mm-hmm. A couple things that we do at Femgineer are I record all the videos, because like yourself, I got tired of saying the same thing over and over again. The other is I have screencasts, and I also have an employee handbook, and much like yourself, have people update that once a quarter. As we scale my training efforts, do you have any that you recommend?

 

Record training sessions

 

Holly Cardew:       We actually do a lot of what you do. I think that you made a really good point. We do a lot of screencasts as well. I think we try and implement the philosophy that even if you're just doing a quick call...They may have been in the job for six months, but if you're doing a call with somebody via Google Hangouts, record it. It doesn't have to be perfect. Just put it in the folder with that question or showing that person how it's done, so the next person who comes along doesn't have to ask the same question.

 

Poornima Vijayashanker:        Yeah. I also do it for our meetings, because sometimes people get sick.

 

Holly Cardew:       Yeah, definitely.

 

Poornima Vijayashanker:        Instead of having one person type up all the notes or play phone tag, it's easier to just say, "Hey, watch the recording. If you want, watch it, double the speed." It's a great way to stay efficient and keep everybody in sync.

 

Holly Cardew:       Do you record every week or every meeting?

 

Poornima Vijayashanker:        Yes, we do record all of our all-hands. Then if it's a particularly training meeting, if I'm walking somebody through it, then I'll also do the recording. Zoom has been great for us to do the recordings. It just automatically records it. Then I'll upload it to Google Drive and label it whatever the training was about.

 

Holly Cardew:       Cool. Where do you put all your documentation?

 

Poornima Vijayashanker:        In Google Drive.

 

Holly Cardew:       OK.

 

Poornima Vijayashanker:        Yeah.

 

Holly Cardew:       Sorry.

 

How to hold remote workers accountable

 

Poornima Vijayashanker:        Similar. Yeah. On the flip side, there's also accountability. I know a lot of times managers feel like if somebody's just sitting right next to them or in the cubicle farm somewhere, they're a lot more present and they're getting work done. But I've been in environments where people spent that eight hours in their cube surfing the internet. How do you hold people accountable in a remote team when they're not even near you, you can't see them?

 

Holly Cardew:       For us, it's really about the goal and the work that they achieve. We could be counting hours and minutes and what they're doing. Some days, I do get a little slightly frustrated, because I want the person to be...I expect them to be there and they're not, but at the same time, we're flexible with time. It's about getting the work done. If people have never hired online before, I actually suggest for them to use a time tracker. I know that platforms like Upwork have...What they do is they take a screenshot of the screen every 10 minutes, and you can check a work diary of what the person's doing.

                   

How to divvy up tasks and set goals with remote workers

 

For us, it's really about trusting the person at the end of the day. I don't want to sit there and look over their shoulder every single minute on what they're doing online. I just want them to deliver high-quality output of their work and their goals for the month or for the quarter. What we've done is we've set up team goals. Instead of me setting goals for the team, we agree on them. They can say, "Holly, that's not achievable," or, "Yes, that is achievable," or, "That's a push goal," but we both agree before moving forward. Then they can't come back and say, "That was too much work," because they also agreed to it.

 

Poornima Vijayashanker:        Yeah, but what about some of those nitty-gritty tasks like, "Oh, I thought so-and-so was going to write this blog post, but then they didn't, so it didn't get it done"?

 

Holly Cardew:       No, we have everything documented in spreadsheets.

 

Poornima Vijayashanker:        Good.

 

Holly Cardew:       Like the task at hand and the person responsible and the due date.

 

Remote working and collaboration

 

Poornima Vijayashanker:        Yup. Yeah, we actually do that as well at the beginning of the week when we do our all-hands. People are supposed to come in with their Trello already filled out—

 

Holly Cardew:       Oh, that's interesting.

 

Poornima Vijayashanker:      —on what the tasks are going to be. It's also a great way to then, if somebody can't do a task, to hand it off. The checklists and all the documentation is in there, and that way, if for whatever reason it doesn't get done, someone else can pick it up and run with it. We're still flexible within that. If it's really like, "Oh, this person had five tasks, and it was unreasonable that week," then it's OK, but if you look and see that none of the five tasks were done, then clearly something is up. I feel like the tools have evolved to a point now where it becomes very transparent on who's getting stuff done and who isn't.

 

Holly Cardew:       Definitely. We have all the tasks listed out. We have used Trello depending on what the role is, again, so we're doing some new feature builds. It involves having the UX and the front-end engineer and the back-end, so we want to keep it all on track. We do use JIRA, too. We probably use one too many tools, but I think everything's well-documented, so we know who's doing what and if it's being achieved.

 

Poornima Vijayashanker:        Yeah, and then just going back and kind of grooming that periodically to see if things are no longer a priority or aligned to your goals.

 

Holly Cardew:       Yeah, definitely.

 

Why you need a communication escalation framework to keep your remote workers productive

 

Poornima Vijayashanker:        Yes. As your team scales, communication obviously becomes a bottleneck. What would you recommend to keeping people in sync?

 

Holly Cardew:       What we do is we've actually broken up in the teams into mini-teams, so tech and product, and then marketing and customer service, and then internal operations. The reason for that is we don't...The tech don't really need to know some of the details, and I don't want to confuse everybody. We have weekly meetings but in those sort of mini-meetings. Then it means that there's no miscommunication. It's quite easy for a small team of four to get together rather than a team of 23.

 

Poornima Vijayashanker:        Sure, that makes sense. Another best practice that I have kind of discovered over time is communication escalation, because it's very easy for people to think that texting has to happen no matter what. I actually over time came up with a framework where, for example, email was for reference. Using a tool like Slack is great for daily communication, archiving messages, kind of going back and taking a look. You could even have a water cooler. Do you have anything like this in terms of communication escalation?

 

Holly Cardew:       We do. I haven't put in a proper framework, but I think over time it's evolved that people do understand that, yeah, Slack is for daily chat. Email, we still quite like email, because it is a bit like to-do. For me personally, it's like a to-do list. Then if it's an ultimate emergency, WhatsApp. WhatsApp's the place.

 

Poornima Vijayashanker:        Yeah, that makes sense. Yeah.

 

Holly Cardew:       No matter where you are, it's handy. We actually have our groups on WhatsApp, so we have our tech and product, our marketing and customer service broken down, so when there is an issue, they can go to a different group. It's a little bit like Slack in that way.

 

Poornima Vijayashanker:        Yeah, but it's good to have that breakdown. Otherwise, people feel like, "Why are you texting me all the time?"

 

Holly Cardew:       Exactly.

 

Poornima Vijayashanker:        Or, "why are you emailing me all the time?" Having that, I think, is important and figuring out what works for your team versus another team.

 

How to coach remote workers to be more resourceful

 

Holly Cardew:       I think also as the leader, it's important that if somebody does email you something, and there is information out there, rather than giving them the answer, in a nice and polite way point them in the direction to say, "You didn't need to email me this for this question. You could have figured it out."

 

Poornima Vijayashanker:        Right. Exactly. This is great advice, Holly. I know our audience out there is going to benefit from all this.

 

Holly Cardew:       Thanks for having me again here.

 

Poornima Vijayashanker:        Yeah. Holly and I want to know. If you have a remote team, how do you train, retain, and hold your employees accountable? Let us know in the comments below this video. That's it for this week's episode. Be sure to subscribe to our YouTube channel to receive the next episode where we're going to talk about how a number of these processes will change depending on the nature of work, whether you've got a high-stakes project or just daily tasks. Ciao for now. This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

 

Jun 6, 2018

Remember our fun live pilot episode back in January 2015? In case you forgot about it or missed it, it was on How To Build A Happy And Productive Remote Team with Ben Congleton the CEO and Co-Founder of Olark. In it, we debunked a number of remote working myths such as:

 

  • Remote employees won’t be as productive and progress will stagnate
  • Communication between remote employees and remote teams will break down
  • A remote team will be devoid of culture

 

It was great for teams, but then we got questions from individuals who wanted to know how they could get started. So last December, we revisited remote working and focused the conversation around How to Succeed In Your First Remote Working Position with Femgineer’s very own Community Manager: Meghan Burgain.

 

And it seems like we have only scratched the surface because we still get a lot of questions and concerns on the topic from startup founders and hiring managers.

 

Most recently, we’ve received questions and concerns are around the hiring process like:

 

  • How do you know someone is a culture fit without a face-to-face meeting?
  • Can you hire a remote worker for any role or only specific ones?
  • How do you test a remote worker’s capabilities and competence?
  • What is the best way to onboard and train a remote worker?

 

So this month we decided to revisit the theme and created three more episodes on the topic, focused on recruiting, training, retaining, and managing remote workers.

 

To help us out, I’ve invited a pro on the topic: Holly Cardew the CEO and Founder of Pixc. Holly has grown and scaled her team across Australia and Asia. And has done so in a number of job functions spanning both the business side with roles such as virtual assistants and marketers, to the technical side hiring software developers and designers to build the product.

 

As you listen to today’s episode you’ll learn:

 

  • The benefits of remote working for employers and employees
  • The criteria you need to set to source candidates
  • Roles that are well-suited to remote work
  • How to suss out culture fit without a face-to-face meeting
  • What to watch out for—red flags to spot early on when hiring remote workers
  • Why it’s good to give people a test or trial project and how to structure it

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

 

## How To Recruit Remote Workers Transcript

 

Poornima Vijayashanker:        We've covered a number of benefits when it comes to remote working in previous episodes. If you've missed any of them, I've included links below. In today's episode, we're going to talk about how to actually go about recruiting for your remote team, 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.
                   

Remote working is becoming the way of the future, and employers who have started embracing it are starting to see the competitive advantages. It's very attractive for employees. In today's episode, we're going to dive into the numerous benefits that employers and employees face when it comes to remote working, and we're going to talk about some of the best practices when it comes to recruiting and retaining employees. And to help us out, I've invited Holly Cardew, who is the CEO and founder of Pixc. Thanks for joining us.

Holly Cardew:       Thanks for having me.

 

Remote working benefits for employers

Poornima Vijayashanker:        Yeah, thanks for joining us. You and I have experienced a number of benefits when it comes to running a remote team. For our audience out there, maybe you can share some of the benefits as an employer.

Holly Cardew:       Running a company, a remote company, has been beneficial for us, or beneficial for any employer, because what you can do is, you can scale up and scale down depending on what task you need done. You can also hire from a remote pool...Sorry, global pool of talent, rather than a local one. We can also provide customer support 24/7, and in other languages, which is amazing. It's also great because as a company, we're flexible. If something goes down or something happens on the weekend, the employees or the team members can also jump online. They're not so constricted to a specific time.

 

Remote working benefits for employees

Poornima Vijayashanker:        Yeah, and I'm sure there's a number of benefits for the employees, so let's jump into those.

Holly Cardew:       I think, for the employees, they love it because it is flexible. At the end of the day, they can live and travel and be wherever they want to. They can work the hours that they want to work. I don't expect someone to be there 9-5. I didn't want to build a company and be in an office 9-5. The employees don't have to necessarily spend an hour and a half in traffic each way every day. So, they can spend that time really focusing on their task at hand.

Poornima Vijayashanker:        Yeah. Another thing I learned recently was that people who are disabled, or an elderly population, can stay in the workforce longer because of having the ability to work remotely. So, I think that's another great thing, if we can keep maintaining the size of the workforce.

Holly Cardew:       Definitely, fantastic. I've also seen that with mothers. We've hired content writers, proofreaders. They're mothers in middle America, or the Philippines. It doesn't matter where they are, they're now able to be with their children before and after school, be really flexible at home.

Poornima Vijayashanker:        Yeah, we've got one, Meghan, who's been on an episode before. So, yeah, I think it's great for motherhood as well. These are great benefits. Let's talk about the types of roles that are conducive to remote work.

 

Types of roles for remote workers


Holly Cardew:       I actually think anything can be remote. I mean, there are definitely times when you need to be on the ground with the customer, or you need to build a physical product, if you're in hardware or other industries. But really, we have, I don't like to use the word "outsourced," but we have people doing legal, accounting, bookkeeping, engineering tasks, design tasks, customer service, marketing. You name it, it's been done with us. So, I think you can actually use a remote or distributed team for any job.

Poornima Vijayashanker:        But I'm sure there's some employees who are better suited for remote work versus others, so tell us what somebody should be looking for in an employee.

Holly Cardew:       Yeah, definitely. I find that the people who are most proactive and take initiative are the ones who are better off when they're remote, because they don't need the guidance or the team around them to keep them motivated. I also find that someone who is slightly entrepreneurial, like they may...I had someone who was in the Philippines, and I said, "What do you do in your free time?" And she said, "I import things from America and I sell them at the market on the weekend." And doing that, it makes them think outside the box, as well. You don't have to train them as much.

 

What to watch out for when recruiting remote workers

Poornima Vijayashanker:        That makes sense. And are there signs that you want to watch out for?

Holly Cardew:       The signs I would watch out for are people who do need to be around others, and they do need that guidance and training, and they're waiting for you to tell them the next thing to do.

Poornima Vijayashanker:        So, people who maybe aren't as self-directed, or possess some of the self-leadership qualities.

Holly Cardew:       Definitely.

Poornima Vijayashanker:        Which I think is necessary for any employee, but...

Holly Cardew:       Definitely, but there are people who are starting out, and they're not used to taking the initiative to go find something. They're used to turning to the person next to them at the office, or university, or wherever they're starting out, and finding the answer.

Poornima Vijayashanker:        Yeah, that's a good point. So, being proactive about being resourceful, and getting the answers that you need on your own.

Holly Cardew:       Especially if they're remote, and I'm sleeping, and another team member's not awake, so they can't get help that way.

 

Criteria for sourcing and filtering remote working candidates

Poornima Vijayashanker:        Yeah, that's a good point. So, do you have a set of criteria for sourcing candidates that fit?

Holly Cardew:       We have quite a, I wouldn't say strict, but a process that we follow every single time. Essentially, we always hire contractors straight away. The reason for that is that we don't have to onboard them for every single task.

 

So, what we do is, we put out simple things when we put out the job. People, nowadays, they're applying for absolutely everything. They just click the apply button. So, we'll put some sneaky question inside the job, even it's "start your cover letter with a smiley emoji."

 

And then you can clearly filter out the people who have read the job description. Because when you're remote, there's a lot of reading, rather than face-to-face conversation. So, that filters down some people.

 

Interview process for remote workers

                  

And then we make a short list, and we interview, and just have a Skype call, about 10-15 minutes. In 10-15 minutes, you can figure out if you're going to...if they culturally fit with the company. I think that's really important. They may be the most amazing person on paper, but if they don't fit with your remote culture, it won't work. And then we give them a trial task, and then after that, if they're successful, we hire them for approximately two weeks to a month to figure out how it works with the company, and then we scale up from there.

 

How to setup a trial project to test candidates

Poornima Vijayashanker:        Yeah. The trial task is one that I do, too. I call it a "task project," and I time box it to about 5-10 hours. I limit it to maybe the two people that I feel have gone through the interview and done a good job, and I actually end up paying them for that trial time.

Holly Cardew:       Yeah, that's exactly what we do. Exactly the same. We also do a trial task, about 5-10, depending on the role. If it's a social media thing, it might be, give me 20 posts that you would post up, or some advice on what you would change on our current social media. But if it's an engineering project, yeah, it would be 5-10 hours, maybe a page, and pay for that task, and then decide from there.

Poornima Vijayashanker:        Yeah. And how do you communicate that to them? Because I know some people are immediately like, "I'm not doing this," and then some people actually take the effort, and I can tell just based on that, who's going to be a good employee versus, OK, clearly you're not interested. So, do you start to see signals like that?

Holly Cardew:       We've definitely had the same thing.

Poornima Vijayashanker:        Yeah? OK.

Why a trial project helps filter candidates

 

Holly Cardew:       It's sort of like a self-filtering mechanism for us. I think most people who have already...If they're local and they haven't had a remote job yet, they're probably a bit standoffish. But most people who are freelance, or have worked remote, they are used to that.

Poornima Vijayashanker:        And then there are some people that think remote working is for them, even though they've never done it before. Like you said, someone who is new to remote working, and they might not know the criteria. Do you have any filters, or ways in which you recruit them?

 

How you can spot signs that a remote worker can be self-directed and resourceful

Holly Cardew:       I think, what we have looked at is that if people are entrepreneurial, they usually have done some small task by themselves. The other one is, I've asked if they've done any side projects, and I ask them to show me their side projects. Like, what do they do in their free time on the weekend? If they don't do something that is slightly work-related...engineers may build something. Marketing people might start their own website to self-promote. So, I look for those things before hiring someone who hasn't had a remote job.
                   

If they have started, it's really about trial and error, and talking to them, talking through. I have friends who are definitely, they say straight up, "I need to be around people." The other option is, you can actually provide them with co-working space.

 

How to provide remote workers opportunities to be around other people
                   

In some situations, I've either provided them with co-working space, or there was another situation where I had someone in Manila, and I knew the people at the Uber office in Manila, so I made a connection for her to go meet with the community manager at Manila, so she could learn from them. And then, it doesn't necessarily mean that they have to have the people in your company around them, they just need inspiration from other people.

Poornima Vijayashanker:        Nice. Yeah. And that's a good point, because it does get lonesome, and coffee shops don't always have the best internet. The co-working could be great. Hiring sight unseen can be challenging. I know, when I initially did it, I wasn't as good, but over the years, I've gotten better. How have you managed to get the best candidates out of the pool?

 

What to watch out for—red flags to spot early on when hiring remote workers

Holly Cardew:       I think, going back to my previous answer, is that really it's about the cultural fit of the person. If your values and the culture doesn't fit, it won't work. I had someone who I was interviewing, and they were so good. I really wanted them. They were an early employee at a huge company that's IPOed. They would have been...It would have been really beneficial to the company, but we didn't see eye-to-eye on hiring, growing the team. We discussed how we would grow the team, and how we would go about it, and it did not fit. Even though it wasn't an issue then and there, I could foresee, going forward, that it would be a huge issue when we wanted to expand the team. So, it was really about the values.
                   

The other thing is that you really need to trust your gut. At the beginning, you're early on, you're starry-eyed. You think everything is amazing, and you just want to get these people on board, but deep down, if you know that it's not going to work, don't do it.

 

Crucial conversations to have with candidates

Poornima Vijayashanker:        One nugget in there was having these crucial conversations, right? You said that you had the conversation about how they were going to approach hiring, and you didn't start to see eye-to-eye. So, maybe when it comes to the tasks, or whatever the next milestone is, have those conversations, and that way, you start to uncover what their philosophy is, to see if there's alignment and a good fit.

Holly Cardew:       Yeah, definitely. I think, it's like any relationship. You need to be able to have a hard conversation. And sometimes, you don't...As a CEO, what's really challenging is, you don't actually get along with everyone perfectly. But as long as you can have a hard conversation, and come to a conclusion, then it's OK. But if something really doesn't fit in your values...

Poornima Vijayashanker:        Better to expose that early on.

Holly Cardew:       Yeah, exactly. Move on, rather than try and make it fit at the beginning.

Poornima Vijayashanker:        Well, these are great practices, Holly. Thanks for sharing them with us.

Holly Cardew:       Thanks for having me.

Poornima Vijayashanker:        So, now, Holly and I want to know, if you have put a remote team in place, what was your process for recruiting? Let us know in the comments below. And that's it for this week's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode, where we'll talk about how to hold employees accountable and retain them. Ciao for now.
                 

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

May 14, 2018

All this month on Build, we've been talking about on-boarding techniques for your new software engineering hires. We started out by talking about why on-boarding is important, and then moved on to showcase how pair and mob programming can help ramp up a lot of hires at once.

The next step is to give them a project!

Giving a new hire a meaty project can seem like a big risk. Seems easier to have them fix bugs while they ramp up on the code base.

But endlessly fixing bugs can be demotivating.

If you’re not sure when the right time is to give your new hires a meatier project, then you’ll definitely want to watch today’s Build Tip.

Chris Jobst who is a senior software engineer at Pivotal Labs is back to share some tips on how to balance bug fixes with meatier projects.

As you watch the episode you’ll learn:

  • Why bug fixing is often a priority, and how to motivate new hires through it

  • Why new hires are in the best position to spot technical debt and tackle it

  • When does it make sense to transition from bug fixes to a project

  • How to structure the project, when new hires are unfamiliar with the code base

  • Why pairing more experienced software engineers on a project with new hires can help new hires level up faster

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

Episode Transcript: When Does It Make Sense To Give A Newly Hired Software Engineer A Meaty Project 

Poornima Vijayashanker:           Hey Ronan, how are you doing, how's your team?

 

Ronan Dunlop:                They're doing great, they're doing really good. In fact, I'm concerned, they're almost through the entire backlog of bugs and I'm not too sure what to give them next?

 

Poornima Vijayashanker:           Maybe a project?

 

Ronan Dunlop:                I don't know, I was really hoping to keep them on bugs for another six months.

 

Poornima Vijayashanker:           Six months? You've got to give them something else, maybe like features, infrastructure work. You've got to mix it up or they're going to burn out.

 

Ronan Dunlop:                I'm not sure they're ready. I'm nervous.

 

Poornima Vijayashanker:           Well, I think that we're going to need to talk about the importance of balancing bug fixes with projects in today's *Build* tip.

 

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker.

 

In the previous two *Build* episodes, we talked about the importance of onboarding new hires and shared how you compare or mod a program. In today's episode, we're gonna dive a little bit deeper and share why you want to not just give new hires bug fixes, but also transition to have them work on some meaty projects.

 

And to help us out, we're back with Chris Jobst, who is a Senior Software Engineer at Pivotal Labs. Thanks for joining today, Chris.

 

Chris Jobst:              Great to be back. Thanks for having me, Poornima.

 

When To Move Past Fixes And Give Newly Hired Software Engineers A Project

 

Poornima Vijayashanker:           So, Chris, you and I have been in the trenches, and you know a lot of times in generating leads and some companies, we won't name any, will start new hires out with a lot of bug fixes, some menial projects. It's no fun, but they do this, why?

 

Chris Jobst:              I think they don't trust them, ultimately, but it's such a great way to get people to not care about the product.

 

Poornima Vijayashanker:           So, at some places they do this for six months, bug fixes and stuff, when does it make sense to actually move past this and give someone a meaty project?

 

Chris Jobst:              I think it's great to get them innovated as soon as possible. Fixing bugs can be a great way to learn about the code, but you want to give them a mix. Get them on features. That's how they're really gonna enjoy their job.

 

How To Structure A Project For A Newly Hired Software Engineer

 

Poornima Vijayashanker:           So, I assume there's some way you want structure a project, because a lot of them won't know their complaint code base. There's gonna be reset a technical debt or other issues that come up, so what's a good way to set them up for success?

 

Chris Jobst:              I think that using pair programming is an excellent way to both onboard them, and get them into the code.

 

Poornima Vijayashanker:           Yeah.

 

Chris Jobst:              You can have somebody more senior help them along as they're developing their first features. At the same time, doing some bug fixes, can get them to learn more about how the code really works at a deep level.

 

Poornima Vijayashanker:           Yeah, and so what do you think the benefit is of doing that peer programming with a senior person?

 

Chris Jobst:              Well, they're gonna ramp up a lot faster, and they'll probably learn a ton from a senior person. It's a great way to have your Junior Developers become Senior, very quickly.

 

How To Train Newly Hired Software Engineers To Handle Technical Debt

 

Poornima Vijayashanker:           So they're probably gonna come across some technical debt and make it stock, not knowing what decision to take or how one thing will impact another module. What are your recommendations?

 

Chris Jobst:              I think new team members are the best positioned to see technical debt, where others may have just put it off to the side for later. So, what they can do, is they can bring fresh eyes, and talk about it with their leads. Then, their leads can help them understand what are the priorities right now, and how to prioritize those things.

 

Poornima Vijayashanker:           OK.

 

Chris Jobst:              It just makes them feel heard, and it lets them understand what are priorities of the project.

 

Poornima Vijayashanker:           So, how do we gauge the success of a project, because there's gonna a lot of learning and ramping up to do, so it's not like somebody can do a release every week?

 

Chris Jobst:              Right, well I think it's really subjective, but a successful project, to me, is one that satisfies the users. If the users are happy, then that's success.

 

How To Motivate Newly Hired Software Engineers To Fix Bugs

 

Poornima Vijayashanker:           Now, I know there comes a time for every software engineer where you've got to hunker down, do some bug fixes, do some menial work, clean out that technical debt, but how can you, as an engineering lead message that, especially to your new hires?

 

Chris Jobst:              We have a weekly meeting to talk about the features coming up. You can make that a meeting, actually, about the chores, and the bugs that need to get done. This involves a PM, and gives the team a sense of unity. It can also give them a direction to go, so they don't feel like its' just gonna go on and on forever, and finally, make sure they understand why they are doing this. It's all for the user's benefit, and for their own. The code is gonna look cleaner by doing the tours and refactoring, and the bugs are gonna solve user problems.

 

Poornima Vijayashanker:           Should there be a carrot at the end of the stick?

 

Chris Jobst:              Absolutely. I'm a huge proponent of celebrating success, so have the team go out to lunch, or have a hackathon that gets them to take their minds off of it, do something else for a bit. In addition, if you have that weekly meeting, then you can setup your next feature, and get them excited about it.

 

Poornima Vijayashanker:           So, Chris, you've shared a lot of great tips when it comes to onboarding new hire. Any final words of wisdom for us?

 

Chris Jobst:              Well, this is a process that can always improve, and I think companies really do themselves a service by iterating and continuing to improve that. A healthy team always has new members joining, because you're rotating you're teams. You're getting new hires. So, make that an enjoyable process for them.

 

Poornima Vijayashanker:           Wonderful. Well, thank you so much, Chris. This has been great.

 

Chris Jobst:              Thank you for having me again. It's been really fun talking with you.

 

Poornima Vijayashanker:           That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more great episodes like this one, and be sure you share it with your teammates, and your boss, and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.

 

Speaker 3:          This episode of *Build* has been brought to you by our sponsor, Pivotal Tracker.

May 9, 2018

In last week’s Build Tip, we dove into the importance of onboarding new hires, and the benefits your team and company will experience if you invest the time into doing it.

 

Next, you might be wondering, what do you do if you have more than one hire? Or you have a hire that isn’t familiar with the language or framework your team uses and you want to ramp them up quickly?

 

Have you heard of techniques like pair programming or mob programming, but aren’t sure if they efficient and effective?

 

Well in today’s Build Tip, we’ll be sharing why pair programming and mob programming can be beneficial to getting new hires up to speed quickly on a new language or framework, and help you scale your efforts efficiently and effectively.

 

Chris Jobst, who is a senior software engineer at Pivotal Labs is back to help us out!

 

As you listen to the episode you’ll learn the following:

 

  • Why pair programming may seem daunting but it’s very efficient
  • How pair programming improves the quality of your code base and product
  • What mob programming is
  • Why it may seem inefficient to have everyone working on a single line of code at once with mob programming, but it’s actually very efficient when onboarding many new hires

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

Check out these additional resources on programming methodologies:

How Pair Programming And Mob Programming Help Quickly Onboard New Software Engineers Transcript

 

Poornima Vijayashanker:        Hey Ronan, how's it going with your new hires?

 

Ronan Dunlop:              Great. I did everything that you and Chris suggested and...but I've run into a small snag.

 

Poornima Vijayashanker:        Oh, what's your snag?

 

Ronan Dunlop:              Most of my new developers don't know RAILS.

 

Poornima Vijayashanker:        Oh, well just peer program with them.

 

Ronan Dunlop:              There's just one of me.

 

Poornima Vijayashanker:        Oh, that's right. And five of them. Well, have you considered Mob programming?

 

Ronan Dunlop:              That sounds dangerous. What's that?

 

Poornima Vijayashanker:        Don't worry, it's not. In fact, why don't we cover the benefits of pair and mob programming in today's *Build* tip?

 

Ronan Dunlop:              That sounds cool.

 

Poornima Vijayashanker:        Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In the last *Build* episode, I shared some tips for onboarding new hires.

                   

In today's episode, we're gonna dive in and give you some more tips around how you can onboard engineers, get them up to speed on a code base or a programming language they may not be familiar with really quickly. And to help us out, Chris Jobst is back. You'll recall Chris is a senior software engineer at Pivotal Labs. Thanks for joining us again, Chris.

 

Chris Jobst:        It's great to be back, Poornima. Thanks again for having me.

 

What Is Pair Programming In Software Engineering

 

Poornima Vijayashanker:        Yeah, wonderful. So let's dive right in. What's Pair programming?

 

Chris Jobst:        Pairing is when you have two people sitting at one computer. We often have two monitors and two keyboards and two mics, and they're literally working on the same code at the same time.

 

Poornima Vijayashanker:        That's gotta be really time consuming to have two people doing the exact same task at the same time. What's the benefit?

 

When To Use Pair Programming

 

Chris Jobst:        It sounds really daunting, but it's actually very efficient. You're basically doing code review a hundred percent of the time.

 

Poornima Vijayashanker:        OK.

 

Chris Jobst:        And you get to refactor together, so you avoid a lot of these common things that you'll see in other code bases.

 

Pair Programming and Refactoring

 

Poornima Vijayashanker:        OK, so maybe for some folks that don't know code reviews or refactoring, maybe we could share what those are as well?

 

Chris Jobst:        Sure. Oftentimes before something gets committed or accepted into the code base, you'll have somebody review it and make suggestions and then the original committer has to go back and change it, and then it goes back to the code review and gets accepted.

 

Poornima Vijayashanker:        OK.

 

Chris Jobst:        That's a feedback loop that we completely avoid with Pair programming.

 

Poornima Vijayashanker:        And with refactoring?

 

Chris Jobst:        Refactoring is simply where you take code and change the implementation without changing the functionality.

 

Poornima Vijayashanker:        OK.

 

Chris Jobst:        To improve the readability and maintainability of the code.

 

How Pair Programming Really Works

 

Poornima Vijayashanker:        So in pairing, since you've got two sets of eyes checking each other's work, it probably moves a lot faster as a result?

 

Chris Jobst:        I think so. There's code review going on, you're refactoring together, you're always talking about the best way to solve a problem and if you don't know what to do, instead of having to go ask someone or stop and email, you've got your pair right there.

 

Poornima Vijayashanker:        Yeah. Which is probably the benefit for new hires?

 

Chris Jobst:        Absolutely.

 

Poornima Vijayashanker:        For our audience out there who may be new to pair programming, how can they get started?

 

Chris Jobst:        Well, you know one computer and another monitor, and you need two keyboards and mics. Most people already have that on hand.

 

Poornima Vijayashanker:        Yeah, and are there any rules, I'm guessing?

 

Chris Jobst:        Absolutely. The biggest one is have empathy, and just be kind to your pair. You're both working together, it's pretty intimate, but it's a lot of fun too.

 

Poornima Vijayashanker:        Now are both people writing code at the exact same time?

 

Chris Jobst:        No. You decide who's going to drive at a certain time and type on the keyboard and the other person will navigate and maybe suggest, "Hey, what if we went over here and did this thing?"

 

Poornima Vijayashanker:        So it's like a pilot/co-pilot and maybe you trade off?

 

Chris Jobst:        Yeah, that's a great way of describing it.

 

Mob Programming Versus Pair Programming

 

Poornima Vijayashanker:        Awesome. There are some situations where you can't Pair program, like in Ronan's case where he's got five engineering hires and they don't know RAILS so how can you work with a bigger group?

 

Chris Jobst:        Well, you can do what's called Mobbing.

 

Poornima Vijayashanker:        OK.

 

What Is Mob Programming

 

Chris Jobst:        You get one computer and often a TV screen or projector and you have a bunch of people, five or more, look at the code. One person is typing and you're generally more teaching or gathering suggestions about how to best achieve a goal.

 

Poornima Vijayashanker:        Got it. I'm sure somebody who's looking on from the outside is gonna be like, "Why are five people sitting around one machine and writing a single line of code?" What are some of the benefits? Why we would wanna do this?

 

Benefits of Mob Programming

 

Chris Jobst:        As you pointed out, it's great for onboarding new people.

 

Poornima Vijayashanker:        OK.

 

Chris Jobst:        And what you'll have is people asking questions, oftentimes they'll ask a question somebody else didn't think of but it's a question that they need answered.

 

Poornima Vijayashanker:        Got it. And I'm sure it also helps with the bus factor, right? Everyone's gonna know something, or know the same thing.

 

Chris Jobst:        Definitely, you want everybody on the same page. You want them all knowing how the code works and if you've got a bunch of new people, it's actually more time-consuming to go and teach every person individually than to get them in a room and help them learn from each other and from the person who's the expert.

 

Poornima Vijayashanker:        Got it.

 

Resources On Pair Programming And Mob Programming

                   

This was a great primer on pairing and mobbing. For our audiences out there who maybe want to dive a little deeper, do you have recommendations on resources?

 

Chris Jobst:        Definitely. There are two great books that I love. *Extreme Programming* and *Extreme Programming Explained*, both by Kent Beck. I recommend the former for engineers. It really talks about these practices and the process in more detail. *Extreme Programming Explained* is a great resource for PMs. It talks about it on a higher level and how a whole project can benefit.

 

Poornima Vijayashanker:        Thanks for sharing these great resources and tips for us. I know our audience is gonna get a lot out of this.

 

Chris Jobst:        Thank you for having me. I'm a huge proponent of pair programming.

 

Poornima Vijayashanker:        So, for all of you out there, Chris and I wanna know, have you done pair or mob programming with your teams as you onboard new hires? If so, what are the benefits you've experienced? Let us know in the comments below.

                   

That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more episode like today's 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.

May 1, 2018

Have you recently hired a software engineer or maybe a few? Congratulations!

 

Are you starting to worry that they haven’t shipped any code yet?

 

Maybe they’re a bad hire...

 

Seems kinda harsh to think someone is a bad hire if they haven’t shipped code in their first day or week, especially if they haven’t been ramped up on the code base.

 

But who has time to train a new hire?!

 

Unfortunately the lack of onboarding new hires, and seeing it as unnecessary is becoming a pervasive misconception. Instead, teams and companies fault the new hire by thinking the new hire just isn’t self-sufficient if they need to be onboarded.

 

But how could someone (even a very seasoned software engineer) possibly review hundreds, thousands, or possibly millions of lines of code on their own? And be expected to know the nuances and decisions that went into writing all of it? Not to mention those notorious monkey patches that lead to bugs that only veterans on the team are aware of!

 

In today’s Build Tip, we’re going to explore why onboarding new software engineers on your team is important, and provide you with some techniques for doing it.

 

To help us out, I’ve invited Chris Jobst, who is a senior software engineer at Pivotal Labs.

 

As you listen to the episode you’ll learn the following:

 

  • How to design a first-day experience for your new hire
  • Why making setup a cinch is a good thing and doesn’t mean you are spoon-feeding your new hire
  • What to expect in terms of results from your new hire at the end of the first day and the first week
  • The benefits your team and company will experience when you invest in onboarding new hires

Wondering what to do if you have more than one hire? Well, stay tuned, because in next week’s Build Tip we’re going to be sharing some best practices for ramping up more than one new hire at a time!

Why You Need To Invest In Onboarding A New Software Engineer And Not Expect Them To Ship Code On Their First Day Transcript

Poornima Vijayashanker:        Hey Ronan, congratulations.

 

Ronan Dunlop:              Oh yeah, we just hired five engineers.

 

Poornima Vijayashanker:        Yeah, that's awesome. Are you going to start onboarding them soon?

 

Ronan Dunlop:              Onboard them?

 

Poornima Vijayashanker:        You know, walk them through the architecture, maybe do some peer programming.

 

Ronan Dunlop:              I don't have time for that. That's why I hired five engineers.

 

Poornima Vijayashanker:        So you're just going to let them sink or swim?

 

Ronan Dunlop:              How else does one know if they're good or not?

 

Poornima Vijayashanker:        Oh boy. I think we're going to need to cover the importance of onboarding in today's *Build* Tip.

 

Why Onboard Your New Software Engineers

                   

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.

                   

While hiring engineers is half the battle, the other half is ramping them up quickly. Today, I'm joined by Chris Jobst, who is a senior software engineer at Pivotal Labs. Thanks for joining us today Chris.

 

Chris Jobst:        Thank you so much for having me Poornima.

 

Poornima Vijayashanker:        Yeah. So Chris, a lot of people would say if you hire an engineer and they're not productive on the first day shipping code, they were probably a bad hire. What do you think?

 

Chris Jobst:        Unfortunately, that's a really common misconception.

 

Software Engineer Onboarding Checklist For Managers

 

Poornima Vijayashanker:        Yeah, what should a typical first day look like?

 

Chris Jobst:        Well my first tip would be to have them meet the team and really make them feel part of that team.

 

Poornima Vijayashanker:        Then what's the next thing you should do?

 

Chris Jobst:        Well start off by talking about the product.

 

Poornima Vijayashanker:        Yeah.

 

Chris Jobst:        What are they building? Who are they building it for?

 

Poornima Vijayashanker:        Got it. After that what would you do?

 

Chris Jobst:        Well then maybe dive into the code a bit. Talk about the architecture.

 

Poornima Vijayashanker:        Nice and what should you do as your talking about the architecture, because some people could have really big code bases?

 

Chris Jobst:        Absolutely. I like to start at a really high level and then dive down bit by bit.

 

Poornima Vijayashanker:        OK.

 

Chris Jobst:        You don't want to overwhelm them on the first day.

 

How To Train Software Engineers

 

Poornima Vijayashanker:        It's great that you mention architecture review. Again, some contrarians might think, "Well they should just set themselves up and dive into the code base. Don't make it too easy, we want them to sink or swim." What do you think?

 

Chris Jobst:        I think the easier that it could be to set them up, the better they're going to be set up for success at the company.

 

Poornima Vijayashanker:        Yeah, why do you think we should make set up a cinch?

 

Chris Jobst:        Well if you really do want to get them involved in the product and the code, then make it easy for them to do that.

 

Poornima Vijayashanker:        Yeah, so getting them ramped up and being able to download the code. Not have to install a whole bunch of jazz and this and that.

 

Chris Jobst:        Have a setup script.

 

Poornima Vijayashanker:        Yeah.

 

Chris Jobst:        We have a few different ways of doing that for the computers that we use and it makes it so much easier.

 

Examples Of Onboarding Newly HIred Software Engineers

 

Poornima Vijayashanker:        What's an example that you guys use?

 

Chris Jobst:        We'll start with a base image and then we just have a workstation script that literally just installs a bunch of software.

 

Poornima Vijayashanker:        What are the expectations for the new hire at the end of the first day? I know you mentioned they should meet the team, we should do an architecture review and make set-up a cinch, but what can somebody expect at the end?

 

Chris Jobst:        I think that it's really important that they feel part of the team, but also that they feel connected to the user base and have empathy for the user.

 

Poornima Vijayashanker:        Yeah, so getting a sense of who the user is and walking them through some use cases. Sharing some new testimonials.

 

Chris Jobst:        Absolutely.

 

Poornima Vijayashanker:        Usually it's an engineering lead driving the process like Ronan Dunlop, so I'm assuming they should maybe do some check-ins, either during that first day or during that first week? What's the benefit of doing a check-in?

 

Benefit To Onboarding Newly Hired Software Engineer

 

Chris Jobst:        Absolutely. You want to make them feel part of the team and when they feel part of the team, they're going to stay at the company longer.

 

Poornima Vijayashanker:        Yeah, that's a clear benefit to having a good onboarding process.

 

Chris Jobst:        Definitely.

 

Poornima Vijayashanker:        Well thank you so much Chris, these tips have been very helpful and I know they're going to help our audience as they onboard their new hires.

 

Chris Jobst:        Glad to be here. Thanks for having me.

 

Poornima Vijayashanker:        Sure. That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more *Build* tips like today's and 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.

Apr 18, 2018

We began this month with a Build episode where we exposed all the aftershocks of using current product management methodologies to estimate user stories. Then in last week’s episode, we dove into Hiten Shah’s new EAT approach which boils down to doing hourly estimates.

 

Don’t worry if you thought Hiten was crazy, you aren’t alone!

 

We received a lot of questions, concerns, and objections, so in today’s episode we’re going to dive into the top 3 we heard again and again:

 

Objection #1: My team is still healing from our previous approach.

 

“My team adopted agile five years ago and experienced a number of problems that you talked about in the first episode. So, six months ago we took the plunge and decided on no estimates and, of course you can imagine, we're still recovering from it. The wounds are raw. So, how am I going to get my team to try something new especially since this is going to be another investment in terms of time?" — Product Manager from Palo Alto

 

Objection #2: This won’t for our customers who want quick fixes!

 

“I hate to play the blame game, but a big source of our problems is our customers. Many want quick fixes, so we end up at their mercy and boy, do they hate eating their vegetables. How do I get them to come around?" — New Product Manager from NYC

 

Objection #3: My team is eager to adopt a new process but how will this help them follow through?

 

"Hiten and Poornima, thanks again for this series. Unlike some of your other audience members, I have the opposite problem. My teammates are eager to adopt a new process, but when they hit a snag they are quick to punt and just do whatever they think they need to do to get the job done. What is the one thing you would advise them to have them stick through when implementing the process and practice of hourly estimates?" — Team Lead from Tulsa

 

Do any of these sound familiar?

 

Listen to the episode to hear Hiten's response to each!

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

 

Check out these additional resources on estimating stories for your product:

 

## Why Hourly Estimates For User Stories And Technical Tasks May Seem Crazy But You Need To Do Them Anyway Transcript

 

Poornima Vijayashanker:    Hiten, last week we instigated our audience by telling them your EAT approach on how they're going to get rid of their old methods and instead embrace doing hourly estimates. A lot of them have written in with their questions, their concerns, one even said you're totally crazy. I hope you're ready to deal with this pushback and address our audience's concerns.

 

Hiten Shah:         Yeah, it's not the first time I've been called crazy. It's because I just want everyone to do better. I've heard everything from “there's no way I'm going to be able to get my team to do this, there's no way I can use this approach,” all the way to, “the approach I'm using today, whatever it is, works just fine.” Yet, those same people say they can't ship on time. Also, “we just can't estimate accurately, we've tried it before, and it's impossible.” I've heard everything.

 

Poornima Vijayashanker:    Awesome. I hope you're ready. Let's just dive right into it.

 

Hiten Shah:         Let's do it.

 

Poornima Vijayashanker:  Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.

 

Hourly Engineering Estimates Is Crazy

                  

Over the last couple episodes, we've been talking about estimates, and you'll recall in the last episode we unveiled the EAT method and talked about how this is all about hourly estimates. I'm sure, for those of you out there, you were thinking, "This is crazy, people will never adopt this on my team." In today's episode, we're going to address a number of these concerns. To help us out, I have invited back Hiten Shah who is the founder of multiple products, and his most recent project is called Product Habits.

                  

Hiten, we put out your EAT approach, your EAT method, and we got a lot of feedback. I want to start by throwing some questions out there from our audience and, hopefully, you'll be able to answer them.

 

Hiten Shah:         Rock and roll.

 

Adopting A New Product Management Process Is A Big Investment For A Modern Software Team

 

Poornima Vijayashanker:    Awesome. Here's the first question, this is from a product manager and they wrote in saying, "Hiten, my team adopted agile five years ago and experienced a number of problems that you talked about in the first episode. So, six months ago we took the plunge and decided on no estimates and, of course you can imagine, we're still recovering from it. The wounds are raw. So, how am I going to get my team to try something new especially since this is going to be another investment in terms of time?" What are your thoughts?

 

Hiten Shah:         Every time you do a process improvement and it involves product people and engineers, they do like process; if they don't then they're probably working at a really early stage startup and spending a lot of time just probably working 18 hours a day just coding and things like that. That's a whole different story, but in this case it sounds like a larger organization to some extent and a bigger team. In those teams, the best advice I have is don't think it's going to take time. I'm not saying you rush into anything or anything like that, but you can start with the E part of the EAT method and really focus in on understanding how to have your team as engineers and the product team learn to explore and learn to really figure out what the communication differences are between the teams. That technical research outline really helps you do that.

                  

If you were to implement one piece, start at the top and start with creating that technical outline on the next project you do. This isn't a whole big process improvement, system changes, and take everybody and regroup them, and all this stuff—

 

Explore: Before You Do Product Estimates Do Your Technical Research

 

Poornima Vijayashanker:    Call in change management.

 

Hiten Shah:         Yeah, none of that. No, we don't like that. I don't like that. Anything I suggest wouldn't fall in line with that. Can you just start with starting with the explore aspect of it? Then, playing it out on the next initiative you're going to do, however small or large you think it is? You'll already start seeing improvements.

                  

Again, seen that happen, heard this objection. Part of it is because of exactly what the person was saying, "I've done this before. It didn't work. The thing we went to is still causing us all these problems, hence why we started with the problems and most of the states people are in." I kept hearing that over and over again. The simple solution is start with this one document and create, what I call, a technical research outline, and use that to communicate with engineers.

                  

The two main components—again just to repeat this—are the evidence, the reasoning, the customer feedback, anything you have there as to why you're building it so that your engineers and rest of the product team can get close to the customer. My favorite part still is the open questions because you're going to have questions about what you're building that might've never previously been answered in your process. Just that and then having communications while engineering solves this problem, but don't think it's going to take forever.

 

Customers Want Quick Fixes

 

Poornima Vijayashanker:    The next question is, "Hiten, I hate to play the blame game, but a big source of our problems is our customers. Many want quick fixes, so we end up at their mercy and boy, do they hate eating their vegetables. How do I get them to come around?"

 

Hiten Shah:         The good news is you're not asking the customers to eat any vegetable. You want to create that dessert for them, if you want to put it that way, but what you're looking to do is get your team to eat their vegetables. What I would suggest is that you take away this idea that you're ruled by your customers in terms of you have to do what they say and instead start taking a bunch of the items that they're giving you and start going through the whole EAT method process and getting actual estimates because then you'll actually be aligned with them. What they want to see is that you're improving the product based on what their needs are. What you want to do want to do is improve the product based on their needs.

 

Tell Your Customers What You Can And Can’t Deliver On

                  

Just by applying the method itself on a high level and starting to go through the process with your team, you can go all the way to the explore aspect and the adjust aspect and you don't have to get to task yet as long as you can have an idea of comparing one thing they want versus another. Then, you can apply the idea that, "Well, we now have an idea that this thing we can do for them is going to take a week, this other thing is going to take a few days," which is probably a process you're not going through right now. Then, you can pick based on that.

                  

Usually, I pick the thing that's going to happen quickest most of the time just to get all those knocked out and keep customers happy. Over time, you would create a balance of both types of things.

 

Poornima Vijayashanker:    I'm sensing from this audience person that they probably have some customers that expect things done right away. Maybe like in the next day, week, or month, they have some deadline in their head that they want the team to meet.

 

You’re Probably Not Delivering A Product Fast Enough For Customer Right Now

 

Hiten Shah:         This whole process you can add criteria, such as “our goal is to release this by this date,” and then the discussions happen. The whole idea of the process is that you can start setting certain criteria and, to me, what I've done before is put that as an open question. This is the most important thing customers want and we'd like to deliver it within, whatever the criteria is. Then, you get to have the discussions with engineering.

                  

Here's the funny thing: even though a customer might have demanded it that fast, that doesn't mean today you're delivering it fast enough for them anyway. This is the most common thing. It's like if you have a faulty process or a process that's not delivering it; it's a circular kind of logic. For me, it's being deliberate and actually getting the estimates will help you get to a place where you can deliver something at the speed that your customers want it. Usually, the customers want the communication and they want accuracy just like you want more than they actually care that it's going to be delivered when they want it. If you tell them, "Hey, we can't do it in a day, but we guarantee it'll be done in three," and you get it done in two or you get it done in three they're happy.

 

How To Get Your Team To Follow Through On Providing Hourly Estimates For User Stories

 

Poornima Vijayashanker:    Last question for you, "Hiten and Poornima, thanks again for this series. Unlike some of your other audience members, I have the opposite problem. My teammates are eager to adopt a new process, but when they hit a snag they are quick to punt and just do whatever they think they need to do to get the job done. What is the one thing you would advise them to have them stick through when implementing the process and practice of hourly estimates?"

 

Hiten Shah:         This is great. It's great to have a team that's motivated to try new things. The best thing you can do for a team like that is give them the outlet to communicate at every step about how the process is working because then you can remind them that we're convicted, we need a better process. We're convicted that we want hourly engineering estimates on things, and so we are going to keep doing this process until it works. Thus we're going to include feedback from you, the people who are doing it into the process, and we're going to make improvements over time.

                  

A technical research outline is created, let's say, and then the engineers work on it, and before you move on to the next step of the EAT method of adjusting, you would take a quick five minutes and let everyone give feedback on the outline itself. Was it effective? Did we miss anything? Are there things that we could've done better? Questions like that.

 

Collect Feedback From Your Engineering Team

                  

I think, for me, if you're running a team, your job is to get feedback from them. Even with any kind of process that you want to change or improve, you want to sit there and say, "OK, how can I make sure that the team is aligned on it?" This is what I would call an alignment tool across the board, so that you're getting their inputs as well, and they don't have this fear or this reason to fall back to old practices that screw up the whole process.

 

Poornima Vijayashanker:    That is the discipline, the getting the feedback and doing the adaptations as you go through.

 

Hiten Shah:         You can't improve without feedback.

 

Poornima Vijayashanker:    Yeah, got it. Thank you so much for taking the time to address a number of these concerns and objections that our audience has, Hiten. Any final words for our audience?

 

Hiten Shah:         Yeah, absolutely. I'm super happy that all of you have watched this. This specific subject was the most controversial subject I've written about, ever in my life. I write about these things on my newsletter, Product Habits, you can sign up at producthabits.com, and I'll be talking more about things like this that are there to help you out all in emails though, no videos, so thank you for having me on video.

 

Poornima Vijayashanker:    You're welcome. We'll be sure to share the link to Product Habits with our audience.

 

Hiten Shah:         Thank you.

 

Poornima Vijayashanker:    That's it for this series and today's episode of *Build*. Be sure to share it with your teammates, your boss, and be sure to subscribe to our YouTube channel to receive the next episode of *Build*. Ciao for now.

                  

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

 

Apr 10, 2018

I don’t know about you but I HATE kale… That stupid leafy green vegetable with the ANDI score of 1000. It’s really hard to chew, and any time I see it on a menu, I skip it! But I get there are a lot of kale converts who go around saying, “Eat your veggies, especially kale!”

 

OK, I know what you’re thinking, “What does this have to do with building software products and product estimates?”

 

Everything.

 

Just like we have to buckle down and eat our veggies (including kale) to stay healthy, there are a number of things we need to do in order to have accurate estimates that will ensure shipping a product consistently.

 

In the last episode of Build, we mentioned how a number of the current approach fall short. If you were left wondering what to do next, don’t fret, because in, today’s episode, Hiten Shah is back. He’ll be introducing a new approach to coming up with product estimates, and it’s coincidentally called the EAT method.

 

As you watch the episode you’ll learn:

 

  • How to perform each step of the EAT method — Explore, Adjust, and Task
  • What you CANNOT do with this approach
  • How this approach reduces ambiguity, which is the #1 cause of delays and scope creep

OK I know what you’re thinking… “Ugh not another approach!” OR, “This is never gonna fly at my company!”

 

Well that’s why after you’ve watched the episode, we want you to let us know what your concerns are tweet to us: @poornima @hnshah. We’ll be addressing a number of them in next week’s episode!

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

Check out these additional resources on estimating stories for your product:

 

 

## What We Need To Do To Produce An "Accurate" Ship Date For Our Product

 

Poornima Vijayashanker:        In the last episode of *Build*, we explored a number of approaches to estimating work, and shared some of the shortfalls when it comes to over-, under-, or just not estimating altogether. If you missed the episode, I've included a link to it below. In today's episode, we're going to suggest an altered approach to estimating that you can adopt and adapt for your team, so stay tuned.

                   

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayshanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now one of the most elusive processes is coming up with estimates for a project or for a task. You'll remember in the last episode, we shared some of the shortfalls of the current approaches. In today's episode, we're going to suggest an alternate approach that you can adopt and adapt to fit your team and your product's needs.

                   

To help us out in today's episode, Hiten Shah is back. You'll recall he has built a number of products. His most recent project is called Product Habits. Thanks for joining us again, Hiten.

 

Hiten Shah:         Happy to be here.

 

Poornima Vijayashanker:        Yeah, so let's go ahead and dive right in. I know we talked about a number of approaches last time, but I'm curious to hear what's your approach for estimates?

 

Estimating User Stories Is Like Eating Your Veggies

 

Hiten Shah:         Well first, I have to say it's like eating your veggies.

 

Poornima Vijayashanker:        OK.

 

Hiten Shah:         With veggies, everyone knows they should eat them.

 

Poornima Vijayashanker:        Right.

 

Hiten Shah:         Many of us are not very good at eating them. We all know the reasons why. It's for health reasons and to prevent certain diseases and things like that. To me, the idea of getting accurate estimates is exactly like that. Nobody really wants to do it, but everyone knows they need to.

 

Poornima Vijayashanker:        Well some of us need to buckle down and eat our veggies.

 

What You CANNOT Do With Hiten Shah’s EAT Method

 

Hiten Shah:         Yeah, of course, but first let me talk about what you can't do with this approach that I'm going to share because what you can't do sometimes is more important than what you can do.

 

Poornima Vijayashanker:        Sure.

 

Hiten Shah:         What typically happens is that you have no estimates, or you have agile with points, or you have some kind of waterfall process, or you have some kind of build, measure, learn, lean startup process going on. If you're not actually doing accurate estimates, you end up running into all these issues. My method will make it so that you don't have to run into these issues. The issues are more issues of what I would call interpersonal communications between team members and teams. They involve things like, believe it or not I've seen this, engineers getting yelled at for not doing their job, so to speak, which would be actually creating the software.

                   

Another example would be we end up sort of like scapegoating and saying that it's this person's fault, or that person's fault, or this team's fault. You can't do that with your engineers if you take this approach. I think partially most importantly of all, if you're actually able to be deliberate and take the approach I'm going to share, you're just going to make it so that you don't have this lack of clarity across the board. I think that's the most important thing. When there's a level of ambiguity on a team about what's going to happen, when it's going to happen, all that kind of stuff, it leads to all these problems of culture, leadership, management. So you're actually preventing a ton of problems if you can do this method.

 

Poornima Vijayashanker:        OK, so what's the approach?

 

EAT (Explore, Adjust, and Task) Method For Providing Hourly Estimates

 

Hiten Shah:         Yeah, so the approach is called the EAT method. The whole idea behind it is to do this three step process. It's an acronym for each of the three steps. The first step is explore, second step is adjust, and third step is task. The thing is, the whole goal behind it, is to get 100% accurate estimates. That means that you're down to 15 minute blocks, or hourly blocks, of estimates from engineers.

 

Poornima Vijayashanker:        Wow, so people who normally can't estimate are suddenly going to be able to give you an hourly estimate of how long something is going to take?

 

Hiten Shah:         Yeah, it's like magic.

 

Poornima Vijayashanker:        Yeah, it sounds like that.

 

Hiten Shah:         Like eating your veggies over your lifetime right, and being a healthy person.

 

Poornima Vijayashanker:        Yeah, I think you're going to have a dive in a little deeper.

 

Explore: Do Technical Research To Uncover What It’s Going To Take To Build A Software Product

 

Hiten Shah:         OK, sure. The first step is explore. In that step, there's one sort of piece of that step that's most important. What I named it is technical research. The reason for that is product people are used to doing user research, they're used to doing customer research, and so research is a word that they're used to, and it's something that the nonengineers start. What that involves is creating essentially a technical research outline. There's many different ways you can do it, but a high level of it is you're explaining exactly what you want to build, and you're also including the reasons you want to build it. Majority of time, depending on your organization, the reason you want to build something should be because there's a customer need, customer paying, or a business problem you're trying to solve, or a combination of both. Then from there you're actually going all the way down to if you have mock-ups, if you have any kind of sketches, you're putting it together.

                   

Then my favorite part of it is when at the bottom you would write this whole idea, or this section, called open questions. These are questions you might have. You can already kind of figure out, you might have already figured out some of the things that might be tough or not tough. Then what you're doing is you're not just keeping that to yourself, you're not just keeping that on your team with your close folks who helped you write it, you're actually providing that to your engineers before they build anything, and before they even think too much about the problem ideally. That's their opportunity to evaluate it. So, that's the first step.

 

Poornima Vijayashanker:        OK.

 

Adjust: List Out Open Questions That Need To Be Answered

 

Hiten Shah:         Then the second step, which is sort of the adjust period, involves after they've taken a look at it, made comments, often times they add their own open questions because they have questions for you too, and so it's just a way to get this communication very deliberate instead of making it all happen in conversations that are either not recorded or just not setup in a way where people can look back at it. From the commenting and the open questions, you're able to adjust what you're going to build. This is the critical piece because if that middle piece of adjusting doesn't happen, that's where estimates completely fall down and that's where you run into all the problems we mentioned earlier in the previous episode about scope creep, and padding. All these things are a result of actually not communicating, and not adjusting what you want to build based on what the engineers tell you is going to be difficult, hard, easy hopefully.

                   

A lot of times even the most seasoned product person and the most seasoned engineers don't generally have an idea of what's easy or hard, what's going to hypothetically take a long time or not, without actually diving into the details. This gets everyone on the same page about that. After that process, sometimes it takes multiple back and forth to get a really good document that outlines a technical research, ideally anyone on the engineering team that could work on this is able to take that and start tasking it. Actually it's engineering tasks in sort of your task management tool, or whatever the tool engineers are using, Pivotal Tracker for example. Then instead of putting points, that's the time when engineers are able to put in minutes and hours. I like 15-minute chunks is what I've found to be most valuable for my teams as part of this process.

 

Iterate As You Go Along To Avoid Misconceptions And Miscommunications

                   

This is one of the things that's more of like what we would call a process improvement. When you do process improvement, it takes iterations to get it right. But what I've noticed is when the teams are deliberate and the product people really bought in to sort of wanting to do better and same with the engineers, this process completely reduces all that ambiguity and misconceptions, and miscommunications that happen when people are just assuming things about what to build and how long things are going to take. By then, the engineers are very comfortable providing very detailed estimate on tasks.

 

Poornima Vijayashanker:        This is pretty novel, and I know that if I'm hearing this for the first time, I sure as heck am going to be opposed to it because I'm thinking I've got to get my whole team to buy in, there's new things I've got to do, all this technical research. I'm not sure I'm going to adopt this in the next week or even month. I think I'm going to have to slowly unveil it. I think our audience is going to have a lot of concerns for the two of us, but I think we should just stop right here.

 

Hiten Shah:         Yeah, I have good news. I've heard it all before, so I'd love to hear it from them.

 

Tell Us Your Concerns Or Objections To EAT Method

 

Poornima Vijayashanker:        Awesome. Well, Hiten and I now want to know what are your concerns with the EAT approach and doing estimates in this 15-minute interval with overall hourly estimates. Let us know what they are in the comments below. That's it for this week's episode. Be sure to subscribe at our YouTube channel to receive next week's episode, where we're going to dive into these concerns and hopefully address a lot of the objections that you're going to get from your teammates and your boss. Ciao for now.

                   

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

Apr 3, 2018

What’s probably the MOST popular and frustrating question you’ve come across when building a product: “How long do you think it will take to do task X?”

 

It’s frustrating on so many levels…

 

First, we need to produce an “accurate” estimate. If it’s off, there goes our ship date!

 

Next, we need to give a response that seems “realistic”, i.e. is going to meet the expectations or deadlines set by someone else.

 

Third, we need to be a fortune teller and anticipate things that come up in the course of completing task X.

 

Finally, we have to do it the moment we’re asked because we’re expected to know how long any task will take.

 

I don’t know about you, but despite building and launching a number of software products over the past 14 years, I still struggle with estimating how long a task will take to complete.

 

There are a number of approaches and methodologies that have sprung up over the years such as Waterfall, Agile and Lean whose goal is to provide a framework that helps engineers, designers, and product managers to estimate how long something will take to build and ship. However, as you’ve probably experienced, each one of these misses the mark.

 

In today’s episode we’ll dive into the aftershocks you may experience when it comes to following one of these approaches and providing product estimates.

 

Next week we’ll tackle an alternate approach that may seem too good to be true…

 

To help us out, I’ve invited Hiten Shah, who is the founder of a number of software products such as Crazy Egg, Kissmetrics, and his most recent project is called Product Habits.

 

As you listen to the episode you’ll learn the following:

 

  • Why we suck at estimating even if we’ve been doing it for a while
  • Why we’re surprised each time our product estimates miss the mark
  • What happens if we decide to “pad” our estimates
  • What happens when we get rid of estimating altogether
  • Why a task we think a task is 80% complete but really it’s more like 50% complete

Check out these additional resources on estimating stories for your product:

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## Why It’s Hard to Provide Accurate Product Estimates Under Most Popular Product Management Methodologies Transcript

 

Poornima Vijayashanker:        Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. One of the most elusive processes has to be estimating how long a project or a task is going to take. And no matter how many times we do it, we somehow just always miss the mark because things come up. Well, in today's episode, we're going to share some of the aftershocks you may experience despite what approach you take when it comes to estimating. In a future episode, we'll dive into an alternate approach in how your team can adopt and adapt it to fit your needs.

                   

To help us out in this episode, I've invited Hiten Shah, who is a founder of many products. His most recent project is called Product Habits. Thanks for joining us today, Hiten.

 

Hiten Shah:           Thanks for having me. Happy to be here.

 

What Happens When We Don’t Accurately Estimate Stories Or Tasks

 

Poornima Vijayashanker:        Yeah. You and I have been building products for a number of years. We've built a lot of different ones. And I know myself being an engineer and a product owner, no matter how many years I put in, I just constantly miss the mark no matter what. I either end up underestimating or overestimating. Let's dive right in and talk about what are some of the problems that happen when we don't accurately estimate.

 

Hiten Shah:           Yeah. I think, when we're building products, we don't generally think about how long it's going to take to build them even though we pretend we do. We end up creating a road map with a bunch of timelines and we don't actually talk amongst the team, because, usually, a product can't be built by a single person. If it could have been built by a single person, then you don't have to worry about it as much because that single person has all the answers. One thing that ends up happening is you end up having surprises that come up that you didn't think of. You're thinking about using a certain technology, let's say such as Twilio or SendGrid or an API and the engineer has never used it before. They get in the weeds of it and they realize it's going to take longer than they think. And then your estimate is blown up and you're off. That's a very common problem.

 

What Causes Scope Creep In Product Management

                   

There's a few others, too. One other one that I've seen people hit continuously is this idea of scope creep. We're both product people. You happen to be an engineer. I happen to be more a marketer. But we love product and building them and teaching other people how to do it, too. One of the aspects of that is we might still be learning and doing research as the product is being built, and we all of a sudden have this great idea we want to add. We go in and kind of blow up the whole process and expect that the timeline is not going to change or don't even think about the timeline and say, "Hey, we're going to build this new thing on top of the thing we're doing." Or, "Can you add this little tweak?" And not realizing how disruptive that is to the process of building the product itself.

 

What Happens When Communication On A Modern Software Team Breaks Down

                   

Another thing that's very common is that if you aren't communicating very well with your team, especially the engineers when you decide that you're going to build something, what ends up happening is the best thing that they can do if you haven't spent enough time communicating early and often is they end up padding. They end up actually adding a whole day—or worse yet—a week or months to a rough estimate. We call it a rough estimate because it's rough.

                   

Those are some of the more kind of common problems that come up when you're building something and trying to get estimates and actually think you have the right great estimates, which is the most common thing. And then all of a sudden all these things happen that you are probably are not conscious to about what kind of problems they cause in terms of being able to ship something on time.

 

Poornima Vijayashanker:        Right. I think two other things I'm curious to hear your take on are large tasks. How do you actually divide them up and then the follow through? You think you're 80% way there and then you discover actually you just finished 50%.

 

What Causes Scope Creep? Large Tasks That Aren’t Broken Down.

 

Hiten Shah:           Yeah. I see companies creating, even in my own companies, so much work that is not actually broken down enough. You might think that it's easy to add a button somewhere, so you say, "OK. This is a button." You think it's a small task. Maybe you're not the engineer, because often times you're the product person, or even if you are the engineer. Then the engineer, whether you decided to do it as an engineer or the product person, you get into the task and all of a sudden you're like, "I have to add the button." There's all these other things that need to change whether it's the user interface, or you're missing a certain component, or what that button does is more complicated than you thought. What ends up happening is this seemingly small task is actually a large task. It's usually because you haven't thought through all the things that you need to think through when you add something like that. And I'm talking about a button. Imagine a whole feature. Right? And considering that to be a small task when it really turns into a large one. I think the most common thing I see is that these things you consider small are actually large.

 

What Causes Scope Creep? Thinking That Tasks Are ‘Simple’ Or ‘Small’

                   

Another common thing is not realizing that what you're asking for is actually a large task. Right. Like adding a messaging feature or things like that. Even a lot of times, I've had emails come in to me from people who are customers saying, "You can send me SMS as notifications. It will take one hour using Twilio, another two hours through your database and you're done."

 

Poornima Vijayashanker:        Great. Come on down and write it for us.

 

Hiten Shah:           You want to do it for me? I'll hold you to the three hours, because it's never as long as people say it is.

 

Poornima Vijayashanker:        Yeah. There's a lot of different approaches we also like to take when it does come to estimating. Even though we know all these problems, we still continue to take an approach. Right? Let's dive into the approaches.

 

Well-Intentioned Product Methodologies: Waterfall, Agile, and Lean Startup

 

Hiten Shah:           Yeah. I think one of the most common approaches that is very still operated by in a lot companies is what we call waterfall, which is one task happens after another task, after another task. A lot of times people are waiting on these things. This is actually the reason another process was invented called agile, which I know both of us are familiar with. Where you're essentially—the way I would describe it is you're trying to do things much more efficiently by basically having more regular meetings and having, I guess, smaller batches of work. What ends up happening there is you create this sort of system that works almost on a weekly basis at best. It means that you have a cadence of following up on all the tasks, we call it agile because you're supposed to be more agile with it and it's more nimble than waterfall and that's completely true, but you lose a lot in the process. Those are the two common ways that I'm most familiar with.

                   

Then there's a third way, which I think is more inspired by things like *Lean Startup*, which again I like to say that we both probably grew up with that so to speak, around us. That's where you are even more hyper—I would call that more hyper agile than anything else, where you're adding in the component of much more customer feedback in the process, because agile wasn't necessarily invented at a time when customer feedback was a popular thing.

 

Poornima Vijayashanker:        Right. What are some of the painful after effects of using agile?

 

How To Estimate Stories In Agile

 

Hiten Shah:           What ends up happening with agile—one of my favorites, and there's a lot of tools out there that facilitate this—is the idea of adding points to an agile process. What you end up doing is you're officiating time. You're saying that something that would take one to three hours is like one point. Or something that would take three to six hours is two points or three points. And they have all these things like Fibonacci sequences. There's a lot of fanciness around points, when you're really trying to understand time not points. The reason that points exist is because—and not that I think this is necessarily bad, it's better than other methods—but some engineers decided that they wanted a metric that wasn't time.

 

Poornima Vijayashanker:        Right.

 

Hiten Shah:           They literally said, "It can't be time, because we cannot estimate."

 

Poornima Vijayashanker:        Because they basically didn't want somebody to know that something was going to take only 15 minutes or five hours.

 

Hiten Shah:           Exactly. Your minimum there is an hour at best. Often times it's much more. The thing is every team that I've seen implement agile with points in different ways. Their whole buckets around the number of points something takes is all different. What ends up happening is that engineers now feel great because they have a velocity score. And they can talk about how many more points they're doing every week or how many points they're doing every week as a total. And that's really hiding what I would call the truth, which is how long did something actually take.

 

Poornima Vijayashanker:        Yeah. I know one of the alternatives is to just get rid of estimates all together, but you've probably experienced what that's like. Talk about what results when you get rid of estimates.

 

What Happens When You Get Rid of Estimating Stories

 

Hiten Shah:           Sure. If you get tired of agile for whatever reason—and usually this happens because somebody that's a non-engineer is really not into it, because they don't understand what a point is even though it has timings and stuff. Then estimates are completely removed, which means points are removed and then there's just tasks. Then you run into some of the problems from earlier. Is it a small task? Is it a big task ? What it really boils down to...if you have no ability to understand how long something’s going to take or even how many points, let's say, then you end up not knowing how to prioritize what you work on. If there's just 10 tasks and all of a sudden the engineer's working on one and then you ask the engineer, "Oh. How are you doing?" They're like, "Oh, it's going to take another week." Well, if I had known that task you took was going to take another week or two weeks or whatever, I probably would have told you to work on something different because our customers are waiting for things. Right.

                   

And that tends to be one of the bigger problems that happens, which is this communication breakdown because nothing is estimated, whether it's points or hours or whatever way people want to do it. And you end up having a massive communication issue and then you have these fiefdoms that get created. You have engineering not against, but against product, against sales, against marketing. And everyone's just waiting for product, everyone's just waiting for things to ship so you can make customers happy.

 

What Happens When You Pad Your Estimates

 

Poornima Vijayashanker:        Right. One of the alternatives to both these is to create a buffer. Let's pad the system so that as an engineer I don't look bad and as a product person you feel like, oh, OK, there's some wiggle room. But we know that that has its shortfalls. Let's talk about those.

 

Hiten Shah:           Yeah. Of course. I think padding is probably one of the worst practices, and you might as well have no estimate or no points or anything like that, because you're essentially saying that whatever estimate I give you, I don't know. I don't know. I'm going to pad it. Then you get in this padding mentality and then you still end up with the same problem that you actually didn't have a real estimate, and things are such a moving target that you failed to ship, you failed to actually do proper planning. You end up having a business where you're actually not getting the product you need in your customers’ hands fast enough so you can actually grow the business. I think padding leads to a whole different set of issues, because what ends up happening in the worst way I can say to you—and I've already said it in pretty aggressive ways—is that everyone's lying to everyone else. That doesn't help with prioritization or getting anything done either.

 

Poornima Vijayashanker:        Well, thank you for taking the time today to share the shortfalls of these three approaches. I can't wait til next time when you unveil your approach for estimates.

 

Hiten Shah:           Yeah. Can't help but share solutions with problems.

 

Poornima Vijayashanker:        Thank you.

 

How Do You Estimate Stories And Tasks?

                   

Now, Hiten and I want to know, have you tried one of these three approaches and how have they fell short for you? Let us know in the comments below. And that's it for this week's episode. Be sure to subscribe to our YouTube channel to receive the next episode where Hiten is going to dive into his approach for doing estimates. Ciao for now.

                   

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

Mar 12, 2018

We’re probably all aware of the famous proverb: “The road to hell is paved with good intentions.”

 

I think it’s very apropos when it comes to diversity and inclusion efforts. Too many of us think that having a diversity and inclusion initiative within our company will produce the change we want to see in the world.

 

Yes, it’s a necessary step, but sadly many initiatives and programs have failed to get off the ground and make a mark.

 

Why?

 

The first culprit is stopping at intentions and not really thinking through what is needed in terms of budget, resources, and timing.

 

The second culprit is not being realistic about expectations. Really asking the question what do you expect to see at the end of a year from a program and is that achievable?

 

Just like we build a business case around running an experience when it comes to our product, process, or policies, the same rigor needs to be applied to diversity and inclusion initiatives.

 

In today’s Build episode, Melinda Epler and Wayne Sutton, who are the founders of Change Catalyst and Tech Inclusion are back.

 

We’re going to talk about best practices and what to look for if you are interested in starting a program at your company or participating in one outside.

 

So if you’re thinking about starting an employee resource group or another program, or want to know how you can improve an existing program, you’ll want to watch this episode to learn:

 

  • Why it’s important to start with a business case — just like you would for any product, process or policy change in a company
  • Why you can’t expect immediate results, but it’s OK to celebrate incremental progress
  • What to do when people within your organization say no to your proposal
  • The microchanges you can into practice daily as you lead and work with teams

Build is produced as a partnership between Femgineer (http://femgineer.com/) and Pivotal Tracker (https://www.pivotaltracker.com/). San Francisco video production by StartMotionMEDIA (http://www.startmotionmedia.com/design/).

-- 

## Diversity and Inclusion: Why You Need To Rethink Your Approach to Diversity And Inclusion Transcript

 

Poornima Vijayashanker:        In the last episode of *Build*, we talked about how diversity and inclusion initiatives are impacting tech, and how to navigate conversations with teammates and peers. If you missed that episode, I've included a link to it below. In today's episode, we're going to dive a little bit deeper and talk about some of the best practices that you can use to kickstart a diversity and inclusion effort at your company, or if you want to go and contribute somewhere else, what to look out for, so stay tuned.

 

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.

 

We're continuing our conversation with Melinda Epler and Wayne Sutton, who are the founders of Change Catalyst and Tech Inclusion. In today's episode, we're going to dive a little bit deeper into some of the best practices that you can use to kickstart a diversity and inclusion effort in your organization, as well as get others to help you out. Wayne and Melinda, thanks for coming back on the show.

 

Melinda Epler:      Absolutely.

 

How To Measure Success For Diversity And Inclusion Initiatives

 

Poornima Vijayashanker:        Before we jump into the best practices, I want to just remind our viewers and our listeners out there how can we measure success before we start to pursue any sort of tech practice?

 

Melinda Epler:      It gets to our number one—the most important thing to start with is measuring where you are now, really benchmarking where you are now in terms of diversity and inclusion. That means doing—if it hasn't been done already—looking at the demographics from race, ethnicity, gender, sexual orientation, veterans, people with disabilities, people all across diverse backgrounds, and then also looking at engagement, and inclusion, and really measuring those as well. There are some surveys out there that you can take internally in a company to really gauge where you are. Before you start, you need to know where you are.

 

Poornima Vijayashanker:        Oh, yeah. Of course.

 

Melinda Epler:      That ranges from obviously looking at the demographics, but also looking at how do people feel? Do they belong? Are they supported? Are they able to really thrive in the company? Are they allowed to rise in the company? Are they supported in growing as a leader in the company? All those things you want to know before you really dive in to programs.

 

Under-Resourced Diversity And Inclusion Programs Are Rampant

 

Poornima Vijayashanker:        Yeah. Now, I know one issue that I run into, and you've probably experienced the same, I think we touched upon this on the last episode, is people come with a lot of great intentions, and a lot of times when you come into these internal groups though, they haven't really thought beyond those intentions. When I ask them questions like, "Who's going to be working with me?" or, "What are the meetings going to look like on the calendar? Is there a budget?" Just the basic logistics, it's like, "Oh, I guess there's some more work to be done," right? Because they haven't thought through what's budget, what's a roll out, what sort of opposition. How can we get around that initially, and what's the homework you would recommend after doing what you said about the benchmarking?

 

Melinda Epler:      Yeah, I think you need...if you're going to start an employee resource group, an ERG, or an affinity group, or something like that in your company, you need to know what are your objectives? What are your goals? What does it look like at the end of the year? What have you accomplished at the end of the year, and how do you design a program that's really going to get to those outcomes, because we see that as well. We see a lot of affinity groups, and it's important to find a safe space for people to get together, and then the next step is how do we go further? How do we do more? How do we start to develop each other as leaders? How do we grow as an organization? How do we help the company change its processes and systems? How do we get to the next level?

 

Poornima Vijayashanker:        Yeah.

 

How To Set Expectations Around Diversity And Inclusion Efforts

 

Wayne Sutton:       Yeah. I believe, also, in setting realistic expectations around what the goals and outcomes could be. Often people come to us like, well, they put resources towards this, they made this type of investment, they hired this person, they did this event, and they expected magic to happen. They expected the doors open where all the other underrepresented categories is gonna come apply to the company. They expect their brand to change. They expect some heat from the press to take off. It's like, "No, you did one thing."

 

Poornima Vijayashanker:        Right.

 

Wayne Sutton:       It's like you send one tweet, you don't expect the world to follow you, right?

 

Poornima Vijayashanker:        Yeah.

 

Wayne Sutton:       There's certain expectations around diversity and inclusion, as well.

 

Poornima Vijayashanker:        Yeah. I think a lot of the product analogies apply here, as well. Like you said, you don't do one marketing campaign hoping that you're gonna 10x your revenue, so why would it be any different with a lot of these efforts?

 

Wayne Sutton:       Exactly.

 

Melinda Epler:      Yeah, and also you need to use agile design, as well, like really think. If it's not working, change it. If something is not effective, do something different.

 

Poornima Vijayashanker:        Yeah. Let's get onto the first best practice that you would recommend to our audience out there who wants to kickstart an effort.

 

Connect Diversity And Inclusion Programs To A Business Case

 

Wayne Sutton:       Yeah. I'd probably say the first best practice is one where we need to identify who our core audience is, right?

 

Poornima Vijayashanker:        OK.

 

Wayne Sutton:       If you are someone in HR, or is in a role of heading diversity inclusion, or even in product, it's like Melinda articulated, you do need a measure, right? You need to start with see where we are. See what our numbers look like. Or, it could be, "Let's talk with executive leadership about how creating inclusive culture, having a focus on diversity and inclusion is connected to our core values and our business goals."

 

Poornima Vijayashanker:        Yeah, that's great.

 

Wayne Sutton:       Let's start right there.

 

Poornima Vijayashanker:        Yep.

 

Wayne Sutton:       Right? Not “let's just run with it, or we're gonna do diversity and inclusion,” because in a day what we've seen, and what has been happening is people say they're working on diversity and inclusion, they put resources behind it, it's not connected to the business goals, and they haven't set the benchmarks around measuring success.

 

Poornima Vijayashanker:        Right.

 

Why Diversity And Inclusion Programs Fail

 

Wayne Sutton:       It's like end of year, what do you have to show for it, or at the end of a program, what do you have to show for it?

 

Poornima Vijayashanker:        Yeah, and there's a huge disconnect, and then people feel like, "Oh, nothing's changing."

 

Wayne Sutton:       Exactly.

 

Poornima Vijayashanker:        "All these programs are useless. Let's just go back to the way things were." Yeah, yeah.

 

Wayne Sutton:       Yeah, exactly.

 

Poornima Vijayashanker:        I like that you mentioned tying it back to business goals, so do you have an example or a case study you can share of either a company that you worked with that was really good at doing this, or even took a first step?

 

Wayne Sutton:       We have several companies that we worked with, but it goes back to what we were saying earlier. It's like the reason why we pause is because there's not a single company we can point to to say that it's doing it well.

 

Poornima Vijayashanker:        Sure.

 

Wayne Sutton:       In doing this work what Melinda and I have learned is that there's also this opportunity of shaming.

 

Poornima Vijayashanker:        Yeah.

 

Wayne Sutton:       Right? We can say we work with Asana, right? We work with Reddit, also. We work B Corp. That's just in some of the consulting training or workshops. We also worked with Capital One. We did a workshop for their network of startups on how to create inclusive cultures from the start with. That was about 20 startups from the size of five to 200, and we could name...there's some well-known name companies in that area, as well.

                   

At the same time, we can say that some of the impact at those companies, we can give an example saying that we worked with them, they completed X, but that's not necessarily an endorsement that those companies have it all figured out.

 

Poornima Vijayashanker:        OK.

 

Wayne Sutton:       It's almost I'd like to say a disclaimer on that. We're not saying that, "Oh, here's an example that Asana's doing, or Reddit is doing, and everybody should copy it."

 

Poornima Vijayashanker:        Right.

 

Wayne Sutton:       That's not saying that they have everything figured out, not saying that they don't have everything figured out.

 

Poornima Vijayashanker:        OK.

 

Wayne Sutton:       It's just the state of the narrative around this industry, and around the conversation about diversity and inclusion. It gets emotional fast.

 

Why Immediate Results For Diversity And Inclusion Efforts Are Unlikely

 

Poornima Vijayashanker:        OK, so maybe a best practice is to not expect immediate results, but to say, "OK, you did one thing. Let's see if that's replicable, and then maybe in five or ten months, years, whatever your benchmark for time is, then take a look back."

 

Wayne Sutton:       Yes, yeah.

 

Poornima Vijayashanker:        Right, so don't call it an early success until you've really seen a number of dots lining up.

 

Wayne Sutton:       Yeah, but we have—

 

Melinda Epler:      Yeah. You can celebrate incremental successes, but it's not fundamentally shifting yet.

 

Poornima Vijayashanker:        OK. OK. Do you have—

 

Wayne Sutton:       But one example is we did work with Asana around their recruitment process. Melinda and I, we held a workshop training on mapping out the entire recruitment flow, and identified areas where they can make some improvement on sourcing differently, and how they can do some of their screening and their in-person interviews better, and they implemented some of those changes, and we're also communicating with their head diversity officer around how did that affect their goals around increasing their numbers around diverse employees or underrepresented employees.

                   

That is one example, but was that a success?

 

Define What Success Looks Like For Your Company

 

Poornima Vijayashanker:        Right.

 

Wayne Sutton:       We know change was made. We know that there was a learning window created. We know that some process was changed, and people grew from that session, but they're still measuring numbers, and there's also these other quantified elements that goes into play when you're talking about success, so yeah. It could've made success from us working with them to help change culture, mindset, and the process, but for the company in itself it is yet to determine in these other variables. Well, if the goal is to hire us to do that to help them increase those numbers, well, what other factors went into play around them increasing their numbers that's outside of our control, and that's where this work we do, we've been doing it now for a long time, and we feel like people need to broaden their mindset, or understand the impact of measuring success on diversity and inclusion. Success could be one thing, or success could be 1% or 2%.

 

Poornima Vijayashanker:        Right. What's another best practice, then, if we're thinking a little bit more broader?

 

Melinda Epler:      Yeah, I'm thinking a lot of people come to us who aren't necessarily in a position to go to leadership, or they've gone to leadership and leadership has said, "No." What do you do there?

 

Poornima Vijayashanker:        Right.

 

Melinda Epler:      Do you just give up, or do you think about other things that you can do outside of that, and I think one of the big things that you can do regardless is lead with empathy, and whether that's leading teams, that's leading products, that's just being a leader in your life and modeling inclusion and empathy, it starts with listening, and really understanding people for who they are and what they bring to the conversation, understanding the perspectives that people bring, and the unique issues that they're dealing with in their work life. It's also listening to your customers. Really, if you don't have a diverse team, you can't change that, listen to your customers, go out and learn from diverse people who are using your product.

                  

If you are leading a team, you can change the way you're leading you team. You can change who you bring on in your team, you can change how inclusive that team is. You can change a lot of things about your team, and really make a difference.

 

Poornima Vijayashanker:        So there's a lot of those micro changes that you can implement, like we were talking about in the last episode, on a daily, weekly, monthly basis, that are eventually gonna add up. Like you said, start with your team, your customers, your leadership, and then go from there, rather than always wanting to enact change top-down.

 

Wayne Sutton:       Yeah.

 

Melinda Epler:      Right, exactly. Exactly. There are a lot of things that underrepresented...that you can do as an ally, as well. There are a lot of really amazing things that you can do that make a big difference in somebody's life.

 

How To Be An Ally For Diversity And Inclusion

 

Poornima Vijayashanker:        Let's talk about what an ally is first.

 

Melinda Epler:      Yeah, so an ally can really be anyone. It can be you, it can be me, it can be Wayne. Pretty much anybody can be an ally to someone who has less privilege, or someone who has equal privilege, quite frankly, and really looking at the little things you can do to help support others. If you're in a position of greater power or leadership you can bring others up with you that are underrepresented. You can disrupt little biases and microaggressions that come to play in daily meetings. For example, you see somebody who's consistently, their ideas are being shot down, or taken over, or they're never able to get a word out, then you can do something to disrupt that.

                   

You can do something to disrupt...I mean, if you see harassment or something like that, there's definitely something you can do about it. It's really hard for an underrepresented person to come out against their own suppression, and so there are lots of things that allies can do, little things that can make a big difference in somebody's life. There's also mentorship, and sponsorship. Mentoring somebody who is underrepresented and really helping them grow their career, giving them advice about how to take the next step and become a leader. Sponsorship is more around, again, that if you're in a position of power, really helping sponsor somebody else to be there, as well.

                   It also could be, as an ally, maybe you're a part of a dominant group being asked to speak on a panel, and it's the same group of people. It's all white men, or it's all white women on a panel. Part of ally-ship is actually taking a step back and allowing somebody else to speak, and allowing other perspectives.

 

Poornima Vijayashanker:        Yeah. Take a break for a while.

 

Melinda Epler:      Yeah.

 

Poornima Vijayashanker:        Rest your voice. Let someone else have a turn.

 

Why It’s Important To Be Proactive When It Comes To Diversity And Inclusion

 

Wayne Sutton:       When I think about the tech industry, and this conversation around diversity and inclusion, and everything that is bundled up in that, there's been a constant theme that most tech companies and individuals have been reactive instead of proactive, and that is disheartening. It's like, "Let's wait for something bad to happen," someone to leave and write a leaving article, a sexual harassment situation, or some shaming to happen online, then let's talk about diversity and inclusion. I would say that if there's an individual on the inside of an organization, and they're working in tech, and they want to create change, don't wait.

                   

Don't wait until something negative happened before looking at creating change. That could be, yes, talk with an executive, talk with a manager, talk with the CEO. Set up a meeting, track it, let them know that, "I'm taking note that I had this conversation."

 

Poornima Vijayashanker:        Right.

 

Wayne Sutton:       Look at the values of the company and speak up. That's kind of more like, "Hey, go straight to the top. Go to the manager," but it also could be just in meetings, right? Just in meetings say, it could be me saying, "I don't feel like my voice, my opinion was heard," or are you thinking about a program or a product and saying, "Well, are you thinking about black women, are you thinking about LGBTQ community, are you thinking about vets? Are we really looking at a targeted customer base from a global and inclusive scale, or a mindset?"

 

Melinda Epler:      And also accessibility, really looking at accessibility from the beginning rather than a reaction to, "Oh, wait. It didn't work. We have to do that now."

 

Poornima Vijayashanker:        People are dropping off, yeah. Why is that?

 

Wayne Sutton:       If people want to create change, and they want to implement a diversity and inclusion strategy, or just get started, just speak up. Speak up, and there's tons of articles, I mean tons of research. We have a blog, we have plenty of resources online, and some of it is finding the allies Melinda was articulating, and knowing that you're not alone, and speak up.

 

Melinda Epler:      Yeah, and take some of those daily steps like taking your vitamins every day, eating your veggies.

 

How You Can Get Involved With Change Catalyst

 

Poornima Vijayashanker:        Let's end with this note of how can our audience get involved with you two and your company?

 

Melinda Epler:      Yeah, a few different ways. One thing is as an organization focused on diversity and inclusion, we need funding. We always do, and so if you have the ability in your company to support us, we have sponsorship. We also can do training and consulting with your company, as well. That's one. Another is we always need volunteers, and we cannot do this work without volunteers. They're amazing. They are part of our team, and they really help make our events, in particular, happen, so volunteer. What are some others?

 

Wayne Sutton:       Yeah. What I say to people who want to get involved is just if you're working on diversity and inclusion, be successful, or often have a conversation with other underrepresented individuals and saying that if you're working in tech, don't forget to open the door for someone else.

 

Poornima Vijayashanker:        Yeah.

 

Wayne Sutton:       The tech industry, we know the numbers. We also know the numbers of our growing global population, how diverse it is, and if you can get in the door, we can do the best of our ability to help consult, train organizations to create inclusive culture, but if you get in the door and you need help, we're here to help.

 

Poornima Vijayashanker:        Yeah.

 

Melinda Epler:      Yeah, and I just want to end with, I firmly believe that if we change tech, we can change the world, because tech is so much a part of the world, and it's increasingly so. Almost every company is becoming a tech company, and we have the power to really make a difference, whether it's in your startup, whether it's in your team, whether it's in your company, whether it's in tech as a whole, the entire industry. If you can affect change in any one of those areas, even if it's you becoming a successful entrepreneur, that in itself, as an underrepresented entrepreneur, that can make a big difference.

                   

You have the power to create change. Do it.

 

Poornima Vijayashanker:        Well, thank you so much for ending on that inspiring note, and to all of you audience out there, thank you for tuning in today. Be sure to share this episode with your teammates and your boss, and be sure to subscribe to our YouTube channel to receive more great episodes like this one. Ciao for now.

                   

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.


Mar 5, 2018

I’m sure you’re aware of the talk and debate around the topic of diversity and inclusion. Maybe it’s left you feeling frustrated, tired, or downright apathetic…

 

I get it.

 

Much of the emotional rollercoaster stems from the challenges of navigating conversations with your teammates and peers on top of your day-to-day responsibilities.

 

Plus you’re probably wondering: Are these programs actually working?

 

You know how much I love busting myths! So in today’s Build episode, we’re going to talk about the issues specific to tech and provide you with some strategies for navigating those tricky conversations with your teammates and your peers. We’ll also dive into what isn’t working and why.

 

If you're curious about starting a diversity and inclusion initiative at your company or participating in another organization, then keep an eye out for the next episode where we'll do a deeper dive into a number of best practices.

 

To help us out I’ve invited Melinda Epler and Wayne Sutton, who are the founders of Change Catalyst and Tech Inclusion.

 

As you listen to this episode, you’ll learn the following:

 

  • Why we may shy away from talking about diversity and inclusion
  • How shaming people and companies doesn’t help the cause
  • Why awareness isn’t enough — how to shift to being more process oriented
  • Why it’s hard to take action individually and how to get support
  • How to know if diversity and inclusion are worth it

 

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

 

## Diversity and Inclusion: How To Navigate Conversations About Diversity And Inclusion in Tech Transcript

 

Poornima Vijayashanker:           There's been a lot of talk and debate around the topic of diversity and inclusion. And regardless of what side you are on, in today's episode, we're going to talk about the issues pertaining to tech, as well as how to navigate conversations with your teammates and peers. So stay tuned.

 

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.

 

Now, as you can imagine, there are a lot of myths and misconceptions around diversity and inclusion. Conversations can be really hard to navigate. And that's why in today's episode, we're going to talk about the issues that pertain specifically to tech and help you navigate those conversations with teammates and peers. And if you're curious about starting a diversity and inclusion initiative at your company or participating in another organization, then stick around for the next episode where we'll do a deeper dive into those practices.

 

In today's episode, I invited Melinda Epler and Wayne Sutton, who are the founders of Change Catalyst and Tech Inclusion. Thanks you guys for joining us today.

 

Melinda Epler:            Thanks. Thanks for having us.

 

Wayne Sutton:              Thanks for having us.

 

What does diversity and inclusion mean?

 

Poornima Vijayashanker:           Yeah. So, let's start by talking about what exactly is diversity and inclusion?

 

Melinda Epler:            I'd like to say that diversity is about bringing diverse people to the table and inclusion is about inviting them to speak, encouraging them to lead, and supporting them in leadership. Diversity is really about the demographics and inclusion is about how people show up, how people thrive, and how people feel that they belong in their culture.

 

Poornima Vijayashanker:           Yeah. And how do you think it pertains to tech?

 

Wayne Sutton:              I like to say diversity includes everything, how it pertains to tech. Tech impacts the world, it impacts everything we do in our daily lives, from the time we wake up to the time we go to sleep. Tech creates wealth. Tech creates innovation. You look at all the products. They got some of the products living on your shelf. We're thinking about the customers. We're thinking about the followers. We're thinking about the equity or the inequity and all the opportunities that is connected to tech. And without diversity, right, you see problems being built by a homogeneous culture. You see solutions not brought to the table because it's being built by one or two mindsets.

 

You see a lot of disparity gaps in terms of access and wealth. So, without diversity, really, the tech industry is not as thriving as it should be or could be. And the impact is having, in a positive and a negative way, is not where it could be as a whole, as well.

 

Why Diversity And Inclusion Are Important

                  

At the same time, if the tech industry were more inclusive, I could imagine more innovative products. I can imagine an industry that is really identifying or being held accountable to its actions as current culture, where we wouldn't have issues that existed in the ‘60s, ‘70s, in terms of not having equal pay, not having women or other representative groups, African Americans in leadership positions, cultural and sexual harassment. If we had inclusion, these negative issues that is in the face of our society right now, in tech, wouldn't exist.

 

Poornima Vijayashanker:           So, let's talk about what drew you to focus on diversity and inclusion, because you both had different backgrounds before you were working on this.

 

Melinda Epler:            Yeah. My background actually started back in cultural anthropology and really looking at how individuals create change in societies, how culture changes. Then, I moved into the documentary filmmaking. I was a documentary filmmaker for about 10 years, became a consultant, and then, actually became an executive at an engineering firm. That experience of being a woman, and the only woman, in leadership in that engineering firm was what made me rethink what needs to change in society. I was not thriving in that culture and it was because it wasn't set up for me, it wasn't set up for my success. And so, I actually left that job as an executive to go into diversity and inclusion. I started Change Catalyst and Tech Inclusion programs, really addressing the inequities in our society. My whole life has been focused on creating social and environmental change.

                  

And I believe, now, that if we don't change leadership, if we don't change who can be a leader and who is leading our countries, who's leading our companies, who's leading our technologies, our stories, then we can't change what's really happening in the world. I am here because I believe that this is the most important thing for me to be working on to create positive social change in the world.

 

Early Attempts To Foster Diversity And Inclusion In Tech

 

Poornima Vijayashanker:           What about yourself, Wayne? Your background is also from a different angle.

 

Wayne Sutton:              Yeah, yeah. I started off doing design, graphic design—I'm showing my age some. Then, got into design UI/UX and computer graphic design. I did IT for about 8 years in North Carolina—Research Triangle Park—then became a tech founder. Had a startup back in 2007 or 8, and didn't realize that in North Carolina that I was one of very few unrepresented tech founders, a black tech founder. And then, experienced the challenges of growing and scaling a company. Then, fast-forward to 2011, the data from CB Insights said that 1% of the tech startups, that raise "angel" or VC are founded by African Americans and Latinos. They actually grouped that data together. So it really was less than 1% Black and Latino that received any angel or venture capital in 2011.

 

By that time, I knew various colleagues across the country that was also working on startups. I was basically like address the problem. What can we create a solution around? Some other colleagues and I, we decided to move to Mountain View and create the very first incubator and accelerator, focused on underrepresented tech founders. That led to a whole other window of opportunity. Moved to Silicon Valley, then moved to San Francisco. And then went through a period where, after that, I realized that the tech industry did not want to talk about diversity and inclusion, did not want to talk about the disparities of access and inequality for founders to receive capital. The tech industry was priding itself on being a meritocracy. It was like: Anyone can create a tech company, anyone can create a product, it doesn't matter.

                   

That may be true.

 

How The “Pattern Of Action” Created A Period Where People Didn’t Talk About Diversity And Inclusion

 

Poornima Vijayashanker:           But it wasn't happening.

 

Wayne Sutton:              No. It was not happening. And the data already showed that everyone was not raising angel capital. It wasn't because of lack of talent. It was not because the products were not as good. It was because what the VC industry would call "a pattern of action."

 

Poornima Vijayashanker:           Right.

 

Wayne Sutton:              And we went through a period where we’re not talking about diversity or inclusion at all. We're not talking about a lack of funding for underrepresented entrepreneurs. And then the tech industry released a diversity report, that was in 2014. And then email—and I want to say the phone, but more the email and Twitter DMs started come in. It was like, "Hey! We need to talk about diversity. I remember you used to talk about it in the day..." And Dan Blenman and I started collaborating. We met and started collaborating on solutions. We got invited to so many roundtables, kind of private conversations, one-on-one meetings around what can we do to fix this diversity problem.

 

Melinda Epler:            Yeah, those were from the White House, to the Small Business Administration, to the FTC, the FCC. And then local tech companies and local conversations as well all kind of talking about that.

 

Wayne Sutton:              That was at the White House during the Obama Administration.

 

Melinda Epler:            Yes, just so we're clear…

 

Why There Isn’t A Single Solution To Improving Diversity And Inclusion

 

Poornima Vijayashanker:           Yes, yes, of course. Well, we know who was in the Administration in 2014. So you already touched upon some of them in your intro, but what were some of the problems specific to tech that you continue to see in this phase and maybe even today?

 

Wayne Sutton:              I would say that the biggest problem is still that happened then that we see today is still the state of denial that there is an issue. There is also the problem that it's going to be one technology solution or you do one thing that's going to fix everything.

                   

And then—

 

Melinda Epler:            One cheap thing.

 

Poornima Vijayashanker:           Yeah.

 

Wayne Sutton:              And then one problem is still thinking that companies and individuals can focus on one demographic or one category. I don't want to say category. But one part of the conversation. And use it saying that it's solving all the problems.

                   

And I would probably say lastly, it's another problem in that I was shocked at how many companies when they started talking about wanting to do work around solutions around diversity and inclusion, they will not even connecting it to their business. Or their customers. Or their direct culture. They were just trying to say, "Hey, we're working on this. Get off our backs! Here's our solution. It's hard." And all those things combined is not really good for the goal we want to achieve.

 

Melinda Epler:            I think there's a few different reasons that this is happening. And this happened in tech differently than in other industries. It started back when Steve Jobs and some of the big, great tech CEOs became "the" story around tech. And the story revolved around that being the kind of...that is the tech founder: the white male CEO is the tech founder.

                   

And when those white male tech founders built their companies, they hired their friends. They just didn't think about it. They hired their friends and their friends hired their friends and the tech companies are still set up for referrals mostly. When you have the same people referring their friends, then you're going to have a homogeneous culture. And so the issue is, now that those companies are so big, it's really hard to create change in them.

 

Poornima Vijayashanker:           Yeah.

 

How Success Patterns Have Bred The Current Culture In Tech

 

Wayne Sutton:              That brings up another good point. Because the industry is manipulated by market trends and success patterns, right? So the VCs while they represent the founders, because they hadn't seen any. Or there hadn't been enough for them to say this is a good model, right? But in the culture of the tech industry, you look at your Microsofts, your Intels, your HPs. That's like one era of American business and society, how they grew and scaled companies.

                   

Then the second wave is the Googles, the Facebooks, the Twitter, the Snaps, the Instagrams, the Salesforce. Those companies basically, like Melinda said, they hired their friends when they started. Larry and Sergei were Stanford grads. And then they got funding from Ron Conway and the network. And there was a lot of luck involved, a lot of sweat, a lot of hard work, they built innovative products, but then because those companies made a lot of money, everybody just replicated that same pattern.

                   

I'm old enough to remember where it didn't matter what school we went to. You can code, you can build, you can design—it mattered. Let's get to work! Let's build something! But then because it became a new norm of like, "Let's copy Google, let's copy Facebook, let's copy other companies." Then that became the standard like, "We must do this." And if we look at that demographic data…

 

How to Measure Diversity And Inclusion In Tech

 

Poornima Vijayashanker:           So, obviously this isn't the first time that people are having this conversation. Like I mentioned in the intro, there have been many, many years that we've been having this. I know even for myself, moving out here in 2004, there were some rumblings, but not a whole lot, to the level it's at today. But obviously people have tried to fix this problem once before, and where have they fallen short? Like, what didn't work?

 

Melinda Epler:            Part of it is not measuring. And that changed in 2014. That was a big shift for everyone, where they really could see these are the diversity...these are the actual demographics of our companies. "Oh! Whoa! Those are really bad! We need to figure out how to solve them."

 

Why Measuring And Building Awareness For Diversity And Inclusion Isn’t Enough

                   

And then, once they said that, they kind of put those numbers out there. It hasn't changed all that much, because the first year was just about measuring. And then starting to hire diversity and inclusion managers and directors, but not putting a lot of money and resources into really...you can't hire one person to change a whole company with very little resources. That's just not possible.

 

So, as those diversity and inclusion managers have gained traction in their own companies, they're starting to get bigger budgets and things are starting to change a little bit faster in the companies. Now that does not discount the fact that people have been working on diversity and inclusion in some of the tech companies for quite some time. One of the issues is that many of the initiatives around diversity and inclusion in the past have focused on employee resource groups, community groups, and really helping support underrepresented people in the companies. And I think, on the other hand, some work has been done on education and awareness building. And this happens in every kind of major culture shift. It happened in the sustainability movement as well. There's an expectation that if you tell somebody there's something wrong, they'll do something about it.

                   

But the problem is, you actually have to help them change their behaviors. And really fundamentally think about how to shift culture. How to shift processes and systems that are ingrained and perpetuating the problem.

 

Why Shaming People And Companies Doesn’t Enact Change

 

Poornima Vijayashanker:           Yeah, talk is cheap.

 

Melinda Epler:            Yeah, and it doesn't really change anything. And the third component is really about shaming. There's also a really deep and disturbing trend around shaming people into changing. That doesn't really change people either! So, there's a new and growing movement and at least an understanding—I wouldn't say movement yet—and understanding that it takes more. It takes a bigger effort to really look at your culture. How do you change your culture? How do you change individual behavior? How do you fundamentally look at your recruiting process? And say, "Oh, wow!" From the very beginning. We need to change the way we're doing things. There are biases in the system, but also there are some mismatched systemic problems in the process.

 

Change Catalyst’s Approach To Helping Companies With Diversity And Inclusion

 

Poornima Vijayashanker:           So let's talk about Change Catalyst and how do you approach this differently?

 

Melinda Epler:            We have a few different things that we do. We have events, our Tech Inclusion events. And when we were talking earlier about having those roundtable discussions back in 2014, we started getting pretty frustrated that those roundtable discussions kept talking about the same things over and over. We had the same conversations over and over again. And they were really problems focused, which is important…

 

Is A Diversity And Inclusion Program Worth It?

 

Poornima Vijayashanker:           What's an example of that?

 

Wayne Sutton:              An example would be the question we get asked over and over again. "Who's doing it well?" And the reason why everybody wanted to know...

 

Poornima Vijayashanker:           Like they're a benchmark.

 

Wayne Sutton:             ...No, no, not that! The reason everybody wanted to know who's...everybody wanted to know what company was having any type of success around diversity and inclusion. Any type of success.

 

Poornima Vijayashanker:           Oh! To see if it was worth it.

 

Wayne Sutton:              They wanted to know if it was worth it, but also wanted to know if they could copy it. They wanted to replicate it. And that was really it. Because everybody wanted one moonshot idea to say, "We're implementing change." That they could say, "We're working on it." And that was a repetitive question across the board.

                   

At times, really, there wasn't a company that had all the answers or all the ideas or...

 

Poornima Vijayashanker:           You guys all suck!

 

Melinda Epler:            Exactly!

 

Poornima Vijayashanker:           Or it's not making an impact.

 

Melinda Epler:            I'd say it's still the case. There's no one company that's doing everything right.

 

Poornima Vijayashanker:           I'd agree!

 

What Diversity And Inclusion Training Looks Like

 

Melinda Epler:            Largely because the diversity and inclusion programs are under resourced. But there are gems. There are some people that are doing some really great programs that we can point to.

 

I think also, in 2014, there was a lot of talk amongst underrepresented people that were feeling disenfranchised. Feeling like the opportunities weren't there for them. Feeling, hearing over and over again that there are barriers, there are barriers, there are barriers. But less about solutions. How do we break down those barriers? What do we do? How do we solve that problem?

 

So that was one. We really wanted to focus on solutions, and that's what we have done. We've designed it to focus on solutions. The second is we really with our Tech Inclusion Programs...it's a systemic problem across the tech industry. So, it starts in education, and then there's huge problems in terms of entrepreneurship. Lack of investing. Lack of investors who are underrepresented. And then also lack of investing in underrepresented founders.

 

And then of course, the workplace. At the time, it was really focused on recruiting. As we talked about, you also have to change the culture. You can't just change recruiting, because you're bringing underrepresented people into a culture that's not creative for them. And they're going to leave! Like I left my position, right?

 

So workplace, and then policymakers as well. Policy and government agencies, and their power and wealth, and ability to create change in the system. And now we also focus on storytelling, like you do as well, to really help raise the underrepresented voices and perspectives, and have more diverse perspectives out there.

 

So for our events, that what we really focus across the tech ecosystem, bringing everybody together to focus on solutions.

 

For our consulting, training, and toolkits, we're also solutions focused. And focused on behavior and culture change, and really going beyond recruiting—recruiting is a part of that, but all the way through creating a culture of belonging.

 

Change Comes From Multiple Sources

 

Wayne Sutton:              Yeah, for us, it's that how change comes is different. We're not a "come in and look at one problem or one sector of the goal you want to accomplish around diversity and inclusion." We want to really discover and look at your entire company from a culture and a systematic perspective to help identify opportunities to create real change.

                   

What we've seen in the past is that a lot of companies contact us after taking unconscious bias training, and saying "We did that, now what? What do we do now? That has had some effectiveness, but we need more." And it's been an opportunity and a challenge aspect is that smaller companies—and even larger companies—they really have to be committed to put their resources in to explore what real change looks like. Whether you implement a new tool to remove names from resumes—that's just one thing. That's just one task you can do to help affect your recruiting process.

                   

But what about when you have your product team, your design team, your engineering team and there's different negative and positive behaviors in that one team dynamic. A software tool is not necessarily going to fix that. One unconscious bias training is not going to fix that. There needs to be a discovery and a real heart-to-heart conversation around employee behavior with accountability. And we come in and have those harder conversations, put together a report, talk with the executive team, and if they have a head of diversity officer, work with that individual to put together some strategies that can create change.

 

Poornima Vijayashanker:           Nice! So what's the impact that you've seen so far through your programs and your offerings?

 

Wayne Sutton:              We see impact across the board. There's impact from the consulting, has been from a company not having any strategy at all from everybody saying like, "Well, we care about this. We want to do something," to now that there is a board level, and executive-level type solution with a plan in place that they can measure and track results over time with some accountability involved, where there's an individual or team saying that, "This is the team that is working on creating inclusive culture." That's been in some of my trainings. A consultant impact.

                   

The other impact we've seen around our conferences and events that we've done now mostly across the globe. We've been overseas. Across the globe, has been everything from gender-neutral bathrooms to new jobs created.

 

How To Navigate Conversations About Diversity and Inclusion

 

Poornima Vijayashanker:           That's a great segue into my next question. I know a lot of people—especially in our audience—care deeply about diversity and inclusion. But they may find it hard to navigate those conversations or to even initiate them with their teams, with their bosses. So how have you kind of facilitated that?

 

Melinda Epler:            We start by asking everyone in the company, at least a broad set of people across the company, what diversity means to them. What inclusion means to them. Start to develop a company-wide definition of diversity and inclusion. And then, literally we talk to people across the company about the ideas that they have, the experiences that they've had, and really develop a strategy that includes all of those voices. I think you have to do that.

                   

So that's what we do at the kind of company-wide level, and including the executives all across the executive teams and the board as well. For an individual wanting to create individual change, who may not be an executive in a company, I think that there are some different resources for understanding the language around diversity and inclusion and there are some courses out there around allyship. And some information around allyship that I think can be really beneficial to really...there are so many different things that you can do.

 

Why It’s Hard To Take Action As An Individual Leading Diversity And Inclusion Initiatives

 

Poornima Vijayashanker:           Before we dive into that, because I want to talk about that in a future episode, maybe we can talk about why it's been hard for them to take action individually.

 

Wayne Sutton:              We have been contacted about a lot of individuals saying that they care about diversity and inclusion and they want to implement change in their company. They need help, right? And ultimately we go back and have a one-on-one call or face-to-face, and we say, “Well what does this conversation allow with the company values? What has been done? Have they discovered what has been done in the past?” And then question if they don't feel confident to have a conversation with their manager or someone, a colleague or someone in an executive role around diversity and inclusion, they need to see if this is a place they want to work. Because it can be a difficult conversation.

                   

I mean, an article just came out today where an individual, he quit a well-known company because his manager or executive said that, "Stop talking about diversity and inclusion!" Right? So this topic is sensitive to a lot of people. They're afraid of it, they don't want to talk about it. It creates a sense of fear and anger and frustration for others. So whenever people come to us and say, "I want to talk about it," a suggestion is approach it with a business case. That’s one. Approach it with an empathy case. Approach it with an idea versus, "Hey, I want to work on diversity and inclusion at my company."

 

That's how we get asked. It's like “diversity and inclusion” is such a big umbrella word. So for your organization...

 

#1 Reason That Keeps People For Taking Action

 

Poornima Vijayashanker:           Loaded

 

Wayne Sutton:              Loaded, right? Well a lot of emotions with a lot of history. So if you are an individual and you say you work in product and you want to work on diversity and inclusion at your SaaS company, right? So a suggestion would be to identify that you're going to talk to your manager. “I want to reach this audience that we haven't been talking with or connecting with. With this lens, how can we make that happen?”

 

That's gonna cost them a product. But from a cultural perspective, it could be "Have we measured?" Or "I noticed that I'm the only female or African American, Latino, LGBT. There are some issues to mean that are not being brought up." Or, "How can we have a dialog about it?"

 

Melinda Epler:            I mean, your question was "What keeps people from taking action?" I think, really. And the #1 thing is fear.

 

Poornima Vijayashanker:           Yeah. Losing their jobs.

 

Melinda Epler:            Losing their jobs, but also just fear of making a mistake. It can be hard to navigate. There are definitely people who are good at shaming, publicly shaming. And that doesn't make it easier to create change and to take action. So I think that inherent in what Wayne is saying is that just take the first step. Take one step. Try something new. Talk to someone. Understand basic things. Understand what their experience is. Listen. Those can be really powerful first steps.

 

Wayne Sutton:              It seems like the tech industry has forgotten that we are humans. We had a conversation as a team talking about...

 

Melinda Epler:            Human first.

 

Wayne Sutton:             ...Human first. Right? And just because I'm different. Just because I'm a black male from the South doesn't mean I can't have an intellectual conversation around topics that are passionate to me. That could be black man, STEM products, that could be how can we look at different demographics or location. Why can't we have a real conversation?

                   

If we can talk about growth. We can talk about APR. We could talk about growth hack and design thinking. Why can't we talk about working together as humans and expanding your mindset, opportunity, and behaviors for all humans? What's the problem?

 

Why People Are Reluctant To Talk About Diversity And Inclusion

 

Poornima Vijayashanker:           So maybe you can touch upon that. What's some of the resistance around the conversations?

 

Wayne Sutton:              It goes back to what Melinda says: Fear! It's fear. But it's also fear because the tech industry traditionally has been a Type A, god-like mentality. Where everybody has all the answers and so if you go to someone and say—talking about diversity and inclusion—you want to have all the answers, so there's it can create a sense of fear. And/or the tech industry we know today, right, is in Silicon Valley, it's in San Francisco, it's in the East Bay some, and the data just in terms of population, in terms of African American in San Francisco is like 6 percent. And if we know the numbers that at Google and at tech roles is average 2 percent within the entire organization. So the culture that these companies traditionally haven't been diverse. So now you want to take an individual, who maybe the one only diverse individual—African American, Latino, women, or Latino or on the team—they want to talk about a cultural topic that is relevant to them, to someone who doesn't have the same experiences, it could be sensing like fear and they don’t have all the answers and not understand why. And that right there creates tension.

 

Melinda Epler:            There are also studies that show that if a company is talking about diversity, then people within the company think it's changing. That is another aspect of this. That's just psychology involved in all of this. When you start talking about diversity, people think that it's changing.

 

Poornima Vijayashanker:           Changing for the better? Or like…

 

Diversity And Inclusion Is Not A Zero Sum Game

 

Melinda Epler:            Changing for the better. People think if you're talking about it, it's changing for the positive. And then there's also on the fear side, though, there's also a fear that if other people rise up, you'll fall down.

 

Poornima Vijayashanker:           A zero-sum game.

 

Melinda Epler:            Exactly. But it's not. This tech industry is growing rapidly. There aren't enough people to fill all the tech jobs. That's absolutely not the case. So we just need to change that perception

 

Poornima Vijayashanker:           So, in the next episode we're going to talk about best practices, but before we wrap up this one, I want to just address some of the objections that our audience may come across when trying to broach the topic. They might have somebody say, "Oh, we're not going to talk about it all, it's not a priority. Like ship product." Or, "Hey, we had lovely little meetup the other day, with some great female engineers. What's the problem? We're making incremental progress." Or, "Hey, we've got to move really fast and whatever you do, how do I know it's going to be a 10x impact?" Right?

                   

And that can be overwhelming for the person on the receiving end. So how do we deal with some of those objections?

 

Wayne Sutton:              Yeah.

 

First Step Is To Measure Your Diversity And Inclusion Efforts

 

Melinda Epler:            I think one of the things people in tech react really well to is data. So the first thing is measure. And find out that information. Find out the demographics of the company. Find out—if you can—the engagement metrics as well, because you can start to look at engagement metrics as it relates to race and gender and ethnicity. And that can...and people with disabilities. And you can really see something is not right.

 

And once you look at the data, then you can say, "Oh, wait! We have a really high turnover rate among women. That's a big..."

 

Poornima Vijayashanker:           Well, everyone's making babies!

 

Melinda Epler:            That's a problem! There are lots of data that shows...

 

Poornima Vijayashanker:           I know...

 

Melinda Epler:            An important part of society. But that is only one. Most of the women who leave tech just so we’re absolutely clear, most of the women that leave tech go to other industries and become leaders in those industries.

 

Poornima Vijayashanker:           So we're missing out on opportunities.

 

Melinda Epler:            We're missing out on opportunities. The cost of turnover is high in a company. You don't want to lose people. That's a huge cost.

 

Poornima Vijayashanker:           So that's just employment. What about with the product itself? Because you had been touching upon some of that.

 

Wayne Sutton:              Yeah, I want to say that for individuals who want to create change or they've experienced some—they're in a culture they want to make improvements in, you start with the data like Melinda articulated. But it's also starting documenting examples, right? Like we worked with one company where the CEO had heard some stories but it was coming second and third hand.

 

Poornima Vijayashanker:            Yeah, that's a challenge.

 

Document And Show Proof Around The Need For Diversity And Inclusion Efforts

 

Wayne Sutton:              So if you're an individual, you work on your product team, your engineering team, or you could be a product manager. And you constantly see these examples, these situations happening. Take note that this happened on this day. This was the experience. And therefore you are able to have proof. The opportunity to create change may come under the window or umbrella of diversity and inclusion, but it could be just how can we conduct an inclusive meeting? Just a better meeting? How could we make sure all the voices are heard?

                 

If you've got a product team, like seven guys, three women, and the women hardly ever speak up or talk, you have a communication and culture problem where the women either don't feel empowered or the men are being assholes. Or both, right?

                   

And so, it's like that is culture. So the change you want to make may not say…”I want to create diversity and inclusion strategies.” Or, “I want to increase #1 my product team.” Or, “I want to make sure the voices are heard.” Or, “I want to talk about how we can conduct a better meeting that benefits the company, and everyone.”

 

Poornima Vijayashanker:           So start small. And that makes a big difference compounded over time.

 

Wayne Sutton:              But track it! Because you've got to have real examples that's relative to the change you want to make.

 

Melinda Epler:            Yeah, it affects product design in a huge way. And I don't think we talk about it enough. That if you want to grow your customer base, and if that customer base is diverse, your designers and developers need to reflect that customer base. If you're designing for the wrong customer base, you're not going to have a success. And it has huge implications—I mean some really terrible ones out there. Even when the airbags were designed, for example, they were designed by men. And in the first rollout, several women died, children died, because they didn't test it out on women and children. That's just a really basic example.

                   

Then we see that in the tech industry a lot now, where especially when AI is being developed and things come out on Google search where black people are mislabeled. That is a really dreadful outcome of not having diverse people design your programs.

 

Diversity And Inclusion Doesn’t Just Impact A Single Group Or Criteria

 

Wayne Sutton:              I'll probably say here another problem is that—or opportunity—is that when people are talking about diversity and inclusion. You got to remember that if you're going to focus on inclusion, look at it from the perspective of everyone. Right? Think about diversity is beyond just a color of someone's skin.

                   

We were talking earlier about people who are hidden, invisible disabilities. Think about accessibility. Think about age. Think about class. You have people with different heritage.

 

Melinda Epler:            Veterans.

 

Wayne Sutton:              Veterans. It's not just black and white. It's not just gender. It's literally everyone. But the solution that may pertain to a company can be one thing—and that's OK if you're going to focus on, "OK, we're going to focus on STEM youth, kids' pipeline." That's OK.

                   

But identify, communicate that this is what we're doing as part of a solution, but not "the" solution. Or, “We're going to focus on college students.” That's OK. That's good. We need to do that. But identify and be clear and authentic about where your solution is around college students affects your business and your culture.

                   

Understand that if you're a person in that culture, say my company's all, "We've got a diversity and inclusion plan. We focus on college students." Yay! Great! But if most of your employees want to focus on a different demographic, want to do something around veterans, then as a team, as a company, depending on what size, you've got to understand why. OK, there's an opportunity and a need to focus on these areas as well.

 

Poornima Vijayashanker:           Well, thank you both for joining us today. And now for all of you out there in the audience, let us know in the comments below this video if your organization has put in place any diversity and inclusion initiatives. And what's been the impact?

                   

And be sure to subscribe to our YouTube channel to receive the next episode, where we'll dive a little bit deeper and share some of the best practices if you're thinking about putting in place a diversity and inclusion initiative at your organization, or want to join another one.

                   

Ciao for now!

                   

This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

Feb 21, 2018

In the last two episodes of Build we tackled why accessibility needs to be prioritized in product design and the three key tips that are critical and will make a big impact on your product's adoption.

This week we’re going to answer two questions that inspired this series from one of our audience members: Jane. We chose these two because we figured they might also be on your mind!

Jane wrote:

Poornima,

Thanks for tackling a wide variety of topics when it comes to building software products. One area that I'm curious about is accessibility.

As a user experience designer, I know accessibility is important, but I've struggled when it comes to balancing out accessibility across devices and also making mobile apps interactive and fun without compromising on accessibility.

How should I think about web versus mobile and balancing out fun and engaging interactions with accessibility in mobile apps?

Sincerely,
Jane
                    

Jane thank you for writing in!

Laura Allen who is the Accessibility Program Manager at Google for Chrome and the Chrome operating system is back and together we are going to be answering Jane’s questions in today’s episode.

As you listen to today’s episode you’ll learn:

  • What are the similarities and differences when it comes to designing for accessibility on web versus mobile devices

  • How to balance balance out fun and engaging interactions versus accessibility on mobile devices

  • The various types of accessibility testing: manual versus automated and tradeoffs associated with both 

Here are links to the resources Laura mentions in the video:

--

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

--

## How To Balance Accessibility And Interactivity Across Devices Transcript

Poornima Vijayashanker:        In the previous two episodes of *Build*, we talked about the importance of accessibility and we shared three critical strategies that will help make a big impact when it comes to building and designing products. If you missed either of those episodes, I've included links to them below. In today's final episode on accessibility, we're going to talk about what accessibility means across devices for both web as well as mobile. Stay tuned.

                   

Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, I invite innovators, and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech.

                   

We're continuing our conversation on accessibility with Laura Allen, who is the accessibility program manager at Google for Chrome and the Chrome operating system. Thanks again for joining us, Laura.

 

Laura Allen:        My pleasure. Thank you.

 

Poornima Vijayashanker:        One of the inspirations for this series on accessibility came from our audience member Jane, so I'm going to start off today's episode by reading the question that Jane posed. Jane wrote, "Poornima, thanks for tackling a wide variety of topics when it comes to building software products. One area that I'm curious about is accessibility. As a user experience designer, I know accessibility is important, but I've struggled when it comes to balancing out accessibility across devices and also making mobile apps interactive and fun without compromising on accessibility. How should I go about thinking about web versus mobile and balancing out fun and engaging interactions with accessibility in mobile apps? Sincerely, Jane."

                   

Jane, if you're tuning in to this episode, thank you for writing in. Laura, why don't we start by answering Jane's question to begin with. How do we balance out web versus mobile?

 

Laura Allen:        It's a really great question. When you think about it, a lot of these concepts that we were talking about in previous episodes are actually going to stand true no matter what platform you're actually designing for. Think back to the web content accessibility guidelines, WCAG. They talk about perceivable, operable, understandable, and robust, and those sorts of concepts and principles that go within each of those categories. Just taking one example, color contrast. Color contrast, having really solid contrast between text and its background, that's important no matter what device you're on. It's going to be the same sort of truth for if you're on a mobile phone or if you're on a desktop computer. A lot of these concepts are going to just span across platforms and be really relevant for you to consider.

                   

One thing that's obviously a little bit different on mobile is that it's clearly more touch oriented for most users. Things like touch targets and the size of your touch targets, that's important to consider. Some people might not have as precise motion or control as they're using their phone or tablet, but honestly, the lines are getting a little bit blurry anyway. Think about all the different devices that are out there now, like laptop computers that also have touch screens or convert and are then used in tablet mode. As designers, we're starting to think about, "How do we just make an app itself accessible on all these different platforms, or a site itself?"

 

Poornima Vijayashanker:        Let's tackle Jane's second question on how do we balance out fun and engaging interactions versus accessibility.

 

Laura Allen:        Yeah. That's another really great question. I think something that we should keep in mind when developing for mobile is sometimes we just rely a little bit too heavily on this idea of gestures and touch-based interfaces. I understand why, of course. It's typically being used by using touch. Some users aren't able to actually use touch to operate a phone. There's something called switch access, for example, which basically allows you to pair a one-button, or two-button, or multiple-button switch and control a phone just using those external buttons. That's just one example. Some people might be only using voice to control a device. Some people might be navigating with a screen reader, so as something flashes on the screen, they're not able to actually perceive that and then catch it in time to actually take action. Thinking about what are these things that we're assuming our users can do here, and then offering alternative ways to actually operate.

                   

For example, if you have an app that you're building where you have cards that you need to swipe away to take action, a swipe can work for some people, but for others, maybe that's not going to be possible. How do we think about things like, "OK. Can we add a hidden close button here so that a screen reader could actually access that and somebody could just simply double tap to activate?" Lots of different things like that. Just, again, removing assumptions about how our users are interacting and then just building to cater to different groups.

 

Poornima Vijayashanker:        I think your answers are going to be very helpful for Jane and the rest of our audience. Any final words of wisdom that you'd like to share when it comes to accessibility?

 

Laura Allen:        Sure, yeah, a couple things. First, just thinking again about mobile versus desktop and web and what not, I think it's also really helpful when designing for mobile to be thinking about the platform-specific guidelines. This is like guidelines for more so just the interaction models for that platform. I know there's the Android developers resources and site. iOS has the iOS human interface guidelines. These things obviously go well beyond just the concepts of accessibility, but they're really important to keep in mind because if you think about it. One example of what would be discussed is focus management. When you first open up an app, where is focus meant to go? What is the default? As you think about these concepts that are kind of illustrated through guidelines for each of these platforms, it's really helpful to keep that consistent so that when a user who happens to be using assistive technology interacts with this app, they get a similar experience to what they're used to. It's a similar model for them, and therefore it's an easier ramp-up curve to actually get introduced to your design. That would be one suggestion.

                   

Another thing to consider, which we haven't really discussed at this point: We talked a lot about auditing and integrating accessibility into your processes, and a lot of what we've talked about so far has been manual testing and the importance of really diving in, trying out the keyboard-only experience, or trying out a screen reader. Absolutely, I think that is so critical. I think honestly...I often get asked about manual versus automated testing, like what can we put in place to run automated tests. There are some great things to do, so there are automated tools, like, for example, there's a tool, there's an Android app called the Android Accessibility Scanner. It's free. It helps to run an audit of your app's accessibility and show you the results for things.

 

Poornima Vijayashanker:        Oh, great.

 

Laura Allen:        Yeah. For things like missing labels on a button or color contrast, things like that, which I would imagine to be kind of low-hanging fruit that you look at and hopefully fix rather quickly. There are similar things on the web and desktop. Lighthouse is a great tool, which integrates with the Chrome Developer Tools. There are lots of other types of tools out there that you can leverage to do some automated testing and audits, but in my opinion, automated can only go so far. That's where you use it to kind of see a baseline, track progress over time and your results, but manual is really critical. Again, whether it's you going through or having assistive technology users go through and give you feedback, that's where you're going to capture that more human interface experience. You're going to understand what is the usability of this product, whether on mobile or on desktop. It's just really critical to find that right balance of manual versus automated testing.

 

Poornima Vijayashanker:        This has been wonderful, Laura, and we'll be sure to include all the resources you mentioned below so that our audience can make sure to get access to them.

 

Laura Allen:        Great. Thank you so much for having me.

 

Poornima Vijayashanker:        Yeah, yeah. You're welcome. This has been great.

                   

That's it for this week's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more episodes like this, and be sure to share this with your friends, your teammates, and your boss. A thank you 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.

                  

1 2 3 4 Next »