Just when you thought you had a handle on your job... it’s time to lead a team! Time to be responsible for others. Their career growth, emotional well-being at work, and job satisfaction.   You’re excited by the new opportunity and want to grow into this role, but it feels like you are starting from scratch. You felt highly competent in your last role. Now it feels like there is a steep learning curve ahead of you, and you may or may not have mentors or role models to help.   If you’re already in a leadership role, maybe you chose it or were promoted into it based on previous performance. But you may or may not have a lot of experience leading a team through a number of contexts such as tight deadlines, conflict situations, peacetime, and re-orgs!   As a result, in the first few months of your transition, you might have struggled to feel like you’re making progress. Overrun by meetings and constant context switching has left you feeling unaccomplished at the end of your workday. You wonder if you're using your time wisely.   You might be left asking yourself, “Am I doing this right?” And, “Should I go back to being an individual contributor?”   I’m here to tell you that all these doubts are normal.   It might not seem normal because no one took the time to map out what a day in the life of a leader would look like. Or maybe they did but only shared the glamorous parts ;)   Well, it’s normal to have doubts, and it does get better!   In this month’s Build episode, we’re going to tackle the topic of being a first-time leader, and to help us out I’ve invited Lara Hogan, who is a coach and trainer for managers and leaders in tech. She is currently the Co-Founder of Wherewithall a consulting and advising company dedicated to helping tech startups and non-profits grow and execute with ease. She was previously, a VP of Engineering at Kickstarter and a Director of Engineering at Etsy.   Lara has a new book coming out called Resilient Management, and in the Build episode, she’ll be sharing insights from it.     Here are the highlights with approximate timestamps:  @5:00: Why Lara chose to focus on helping new leaders and managers hone two skills: human growth and resiliency @7:30: How every team (old and new) goes through four stages of development: forming, storming, norming, and performing, and what you as a leader can do in each stage to support your teammates @10:00: The six core needs we all need at work, and why even missing one might have caused you to feel emotions like unappreciated, distant or detached, or underwhelmed @14:40: Why Lara no longer suggests using a README to help your teammates get to know you, and what to do instead, especially when it comes to setting expectations @16:30: Know what you are optimizing for—instead of fixating on a management style or philosophy @18:00: How to spot areas of friction and handle them! @20:00: Why many first-time leaders default to mentoring (aka advice giving) and need to switch to coaching (guide teammates to discovering solutions) @24:20: Do highly functional teams even exist? @24:45: How to handle delivering bad news because as leaders that is one of the things we often have to do  Want a copy of Lara’s new book Resilient Management?  Leave a review for Build on iTunes, then hit reply to this email to let me know you left a review, and I’ll share an e-book copy of Lara’s book with you! (Limited to the first 5 people who respond.)   Here are some additional resources Lara mentions in the episode for you to check out:    Core Needs: BICEPS by Paloma Medina  Four Stage of Group Development by Bruce Tuckman  -- Build is produced by Femgineer (http://femgineer.com/).

Just when you thought you had a handle on your job... it’s time to lead a team! Time to be responsible for others. Their career growth, emotional well-being at work, and job satisfaction. You’re excited by the new opportunity and want to grow into this role, but it feels like you are starting from scratch. You felt highly competent in your last role. Now it feels like there is a steep learning curve ahead of you, and you may or may not have mentors or role models to help. If you’re already in a leadership role, maybe you chose it or were promoted into it based on previous performance. But you may or may not have a lot of experience leading a team through a number of contexts such as tight deadlines, conflict situations, peacetime, and re-orgs! As a result, in the first few months of your transition, you might have struggled to feel like you’re making progress. Overrun by meetings and constant context switching has left you feeling unaccomplished at the end of your workday. You wonder if you're using your time wisely. You might be left asking yourself, “Am I doing this right?” And, “Should I go back to being an individual contributor?” I’m here to tell you that all these doubts are normal. It might not seem normal because no one took the time to map out what a day in the life of a leader would look like. Or maybe they did but only shared the glamorous parts ;) Well, it’s normal to have doubts, and it does get better! In this month’s Build episode, we’re going to tackle the topic of being a first-time leader, and to help us out I’ve invited <a href="https://larahogan.me/" rel="nofollow" target="_blank">Lara Hogan</a>, who is a coach and trainer for managers and leaders in tech. She is currently the Co-Founder of Wherewithall a consulting and advising company dedicated to helping tech startups and non-profits grow and execute with ease. She was previously, a VP of Engineering at Kickstarter and a Director of Engineering at Etsy. Lara has a new book coming out called <a href="https://resilient-management.com/" rel="nofollow" target="_blank">Resilient Management</a>, and in the Build episode, she’ll be sharing insights from it. Here are the highlights with approximate timestamps: <ul> <li>@5:00: Why Lara chose to focus on helping new leaders and managers hone two skills: human growth and resiliency</li> <li>@7:30: How every team (old and new) goes through four stages of development: forming, storming, norming, and performing, and what you as a leader can do in each stage to support your teammates</li> <li>@10:00: The six core needs we all need at work, and why even missing one might have caused you to feel emotions like unappreciated, distant or detached, or underwhelmed</li> <li>@14:40: Why Lara no longer suggests using a README to help your teammates get to know you, and what to do instead, especially when it comes to setting expectations</li> <li>@16:30: Know what you are optimizing for—instead of fixating on a management style or philosophy</li> <li>@18:00: How to spot areas of friction and handle them!</li> <li>@20:00: Why many first-time leaders default to mentoring (aka advice giving) and need to switch to coaching (guide teammates to discovering solutions)</li> <li>@24:20: Do highly functional teams even exist?</li> <li>@24:45: How to handle delivering bad news because as leaders that is one of the things we often have to do</li> </ul> Want a copy of Lara’s new book Resilient Management? <a href="https://podcasts.apple.com/us/podcast/build/id1032969327?mt=2" rel="nofollow" target="_blank"> Leave a review for Build on iTunes</a>, then hit reply to this email to let me know you left a review, and I’ll share an e-book copy of Lara’s book with you! (Limited to the first 5 people who respond.) Here are some additional resources Lara mentions in the episode for you to check out: <ul> <li><a href="https://www.palomamedina.com/biceps/" rel="nofollow" target="_blank">Core Needs: BICEPS</a> by Paloma Medina</li> <li><a href="https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development" rel="nofollow" target="_blank"> Four Stage of Group Development</a> by Bruce Tuckman</li> </ul> -- Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>).

Episode 92: Resilient Management: Building & Managing Highly Functional Teams

We’re living in an era where there is more than one path to gaining freedom and flexibility, though often it takes some trial and error to achieve it. Gregg Goldner is an example of someone who was tired of missing out on important life events and wanted more freedom and flexibility in his career. In the last episode of Build, Gregg shared his journey going from being a school teacher to a software developer. He chose to be a freelance software developer because he valued honing his craft. This choice meant he’d had to find work and clients who valued his talents. If you’ve haven’t had a chance to check out the episode yet, you can watch it here or listen to it here.  Another approach to gaining more freedom and flexibility is to be your own boss and start your own company. In the beginning, you may choose to do most of the work yourself, but there will come a point in time when you will need to hire someone because you’ve hit the limits of your expertise, or how much work you can realistically do.  While hiring help may seem like a panacea it comes with its own set of challenges. Add in limited time and budget to find a quality hire, and the challenges grow.  I’ll admit that it’s taken me more than a decade to find people I enjoy working with, can rely on, and learn from. I won’t claim that I know how to hire the perfect people every time—frankly, they don’t exist. What I've learned over the years is how to come up with the key criteria needed to source talented individuals, suss them out, and help them grow over time. I've tested and tweaked the strategies when hiring people in startups and growth stage companies.  In today's Build, I'll be sharing these strategies with you. The episode is taken from a live online group coaching call I hosted last year with first-time founders who were hiring technical talent, but the strategies also apply to hiring managers who are looking to fill non-technical roles. Even if you aren’t the person making a hiring decision, it’s a valuable episode to learn how you may be evaluated in the future!  As you watch the episode today, you’ll learn the following:   The pre-work you need to do before you start recruiting   How to source candidates through your network as well as online and offline channels   How to evaluate a candidate's work history, projects, and references   How to vet people who are reliable, can communicate clearly, and will produce high- quality work   The difference between vetting a freelancer and a firm—as well as how to avoid the ‘gotcha’ moments!    Want more help recruiting, onboarding, and retaining talent?  Check out our previous episodes on  what to expect from new software engineering hires,  how to onboard new software engineers quickly, and  how to keep newly hired software engineers motivated. If you're looking to hire product managers, you'll find the following episodes on hiring product managers,  interviewing them, and  training and retaining them helpful. Finally, if you’re looking for UX designers, tune in to our episode on  sourcing, vetting, hiring and working with UX designers. -- Build is produced by Femgineer (http://femgineer.com/).

We’re living in an era where there is more than one path to gaining freedom and flexibility, though often it takes some trial and error to achieve it. Gregg Goldner is an example of someone who was tired of missing out on important life events and wanted more freedom and flexibility in his career. In the last episode of Build, Gregg shared his journey going from being a school teacher to a software developer. He chose to be a freelance software developer because he valued honing his craft. This choice meant he’d had to find work and clients who valued his talents. If you’ve haven’t had a chance to check out the episode yet, <a href="https://youtu.be/Yv2syb3Dm3k" rel="noopener nofollow" target="_blank">you can watch it here</a> or <a href="https://itunes.apple.com/us/podcast/build/id1032969327?mt=2" rel="noopener nofollow" target="_blank">listen to it here</a>. Another approach to gaining more freedom and flexibility is to be your own boss and start your own company. In the beginning, you may choose to do most of the work yourself, but there will come a point in time when you will need to hire someone because you’ve hit the limits of your expertise, or how much work you can realistically do. While hiring help may seem like a panacea it comes with its own set of challenges. Add in limited time and budget to find a quality hire, and the challenges grow. I’ll admit that it’s taken me more than a decade to find people I enjoy working with, can rely on, and learn from. I won’t claim that I know how to hire the perfect people every time—frankly, they don’t exist. What I've learned over the years is how to come up with the key criteria needed to source talented individuals, suss them out, and help them grow over time. I've tested and tweaked the strategies when hiring people in startups and growth stage companies. In today's Build, I'll be sharing these strategies with you. The episode is taken from a live online group coaching call I hosted last year with first-time founders who were hiring technical talent, but the strategies also apply to hiring managers who are looking to fill non-technical roles. Even if you aren’t the person making a hiring decision, it’s a valuable episode to learn how you may be evaluated in the future! As you watch the episode today, you’ll learn the following: <ul> <li> The pre-work you need to do before you start recruiting </li> <li> How to source candidates through your network as well as online and offline channels </li> <li> How to evaluate a candidate's work history, projects, and references </li> <li> How to vet people who are reliable, can communicate clearly, and will produce high- quality work </li> <li> The difference between vetting a freelancer and a firm—as well as how to avoid the ‘gotcha’ moments! </li> </ul> Want more help recruiting, onboarding, and retaining talent? Check out our previous episodes on <a href="https://www.youtube.com/watch?v=cOd9TxrgaGM&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=28" rel="nofollow" target="_blank"> what to expect from new software engineering hires</a>, <a href="https://www.youtube.com/watch?v=xS8vBzzL0WI&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=27" rel="nofollow" target="_blank"> how to onboard new software engineers quickly</a>, and <a href="https://www.youtube.com/watch?v=6zagT_JQly8&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=26" rel="nofollow" target="_blank"> how to keep newly hired software engineers motivated</a>. If you're looking to hire product managers, you'll find the following episodes on <a href="https://www.youtube.com/watch?v=QVcsOh0Yfbs&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=18" rel="nofollow" target="_blank">hiring product managers</a>, <a href="https://www.youtube.com/watch?v=yGAjT7z3F0s&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=17" rel="nofollow" target="_blank"> interviewing them</a>, and <a href="https://www.youtube.com/watch?v=CVlYE2lzof8&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=16" rel="nofollow" target="_blank"> training and retaining them</a> helpful. Finally, if you’re looking for UX designers, tune in to our episode on <a href="https://www.youtube.com/watch?v=bPx0EtLeDKs&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=5" rel="nofollow" target="_blank"> sourcing, vetting, hiring and working with UX designers</a>. -- Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>).

Episode 91: Hiring Technical Talent: What To Look Out For When Hiring Your First Employee

When I was in my early 20s and someone told me to prioritize freedom and flexibility, I’d cringe and think, “Yes but how?”   Over the past fifteen years, I’ve asked this question to people I’ve met. Through trial and error, I’ve learned to incorporate or tweak parts of their how to fit my needs. As a result, I’ve learned there is more than one how, and to be wary of those who claim there is only one!   One approach we explored earlier this year was building a Company of One. Paul Jarvis and I explored how he went from being a freelancer and providing a service to scaling his business to create products. In the Build episode, we shared some of the common themes. If you missed the episode,  you can check it out here.   This month, I want to rewind and explore the first part, becoming a freelancer.   Becoming a freelancer is one approach to gaining more freedom and flexibility. And while it’s easy to glamorize being your own boss, it can take time (many years) to get a business off the ground.   You have to figure out how to market yourself, manage clients, price your service, and still have enough hours left in the day to do the work!   All of these tasks can leave you feeling overwhelmed. To help you think about the transition, gain some perspective, and most importantly, work through the overwhelm, I’ve invited Gregg Goldner, who is a freelance developer and President of Two Sun Traders, LLC to share his experience.   Whether you are a freelancer, want to be one, or are just curious, I’d highly recommend tuning into this week’s episode to learn the following from Gregg:    Why Gregg wanted more flexibility in his life and chose to transition from being a music teacher to a software developer How he made the transition to becoming a software developer The skills he learned from having been a school teacher and how they applied to software The experience that led Gregg to choose to be freelancer instead of a startup founder How he initially priced himself, then changed his pricing over time The importance of honing your craft How he interviews clients and picks projects    I loved this quote from Gregg because it showcases how you need to focus as a freelancer:   “Putting on every single hat and then realizing I don’t like half those hats. Wouldn’t it be great if I didn’t have to do those things? What are my strengths and weaknesses, and how can I find people who have different strengths and weaknesses?” — Gregg Goldner, President of Two Sun Traders, LLC   In the episode, Gregg mentions a number of resources, here are links to them:     The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering by Frederick P. Brooks Jr.  Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin  Refactoring: Improving the Design of Existing Code by Martin Fowler  Code Complete by Steve McConnell iOS Development Tutorials by Ray Wenderlich A weekly video series on Swift programming A hands-on guide to learning Swift Subscription learning platforms Packt and Lynda.com    If you’ve been following Build for a while, you may recall I did an episode with Jessica Hische who is a letter, illustrator, and type designer a few years ago on a similar topic: How To Prepare To Strike Out On Your Own And Pursue Your Creative Calling. Listen to the episode here. I always find it helpful to revisit a topic and compare notes, plus some people’s voice resonates more than others, so I’d highly recommend you check out that episode too! -- Build is produced by Femgineer. 

When I was in my early 20s and someone told me to prioritize freedom and flexibility, I’d cringe and think, “Yes but how?” Over the past fifteen years, I’ve asked this question to people I’ve met. Through trial and error, I’ve learned to incorporate or tweak parts of their how to fit my needs. As a result, I’ve learned there is more than one how, and to be wary of those who claim there is only one! One approach we explored earlier this year was building a <a href="https://ofone.co/" rel="nofollow" target="_blank">Company of One</a>. Paul Jarvis and I explored how he went from being a freelancer and providing a service to scaling his business to create products. In the Build episode, we shared some of the common themes. If you missed the episode, <a href="https://femgineer.com/2019/01/company-one-staying-small-can-great-business-strategy/" rel="nofollow" target="_blank"> you can check it out here</a>. This month, I want to rewind and explore the first part, becoming a freelancer. Becoming a freelancer is one approach to gaining more freedom and flexibility. And while it’s easy to glamorize being your own boss, it can take time (many years) to get a business off the ground. You have to figure out how to market yourself, manage clients, price your service, and still have enough hours left in the day to do the work! All of these tasks can leave you feeling overwhelmed. To help you think about the transition, gain some perspective, and most importantly, work through the overwhelm, I’ve invited Gregg Goldner, who is a freelance developer and President of Two Sun Traders, LLC to share his experience. Whether you are a freelancer, want to be one, or are just curious, I’d highly recommend tuning into this week’s episode to learn the following from Gregg: <ul> <li>Why Gregg wanted more flexibility in his life and chose to transition from being a music teacher to a software developer</li> <li>How he made the transition to becoming a software developer</li> <li>The skills he learned from having been a school teacher and how they applied to software</li> <li>The experience that led Gregg to choose to be freelancer instead of a startup founder</li> <li>How he initially priced himself, then changed his pricing over time</li> <li>The importance of honing your craft</li> <li>How he interviews clients and picks projects</li> </ul> I loved this quote from Gregg because it showcases how you need to focus as a freelancer: “Putting on every single hat and then realizing I don’t like half those hats. Wouldn’t it be great if I didn’t have to do those things? What are my strengths and weaknesses, and how can I find people who have different strengths and weaknesses?” — Gregg Goldner, President of Two Sun Traders, LLC In the episode, Gregg mentions a number of resources, here are links to them: <ul> <li><a href="https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=sr_1_fkmrnull_1?keywords=The+Mythical+Man-Month%2C+Anniversary+Edition%3A+Essays+On+Software+Engineering+by+Frederick+P.+Brooks+Jr.&amp;qid=1556627629&amp;s=gateway&amp;sr=8-1-fkmrnull" rel="nofollow" target="_blank"> The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering by Frederick P. Brooks Jr.</a></li> <li><a href="https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_2?keywords=clean+code&amp;qid=1556627657&amp;s=gateway&amp;sr=8-2" rel="nofollow" target="_blank"> Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin</a></li> <li><a href="https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599/ref=sr_1_fkmr0_1?keywords=Refactoring%3A+Improving+the+Design+of+Existing+Code+by+Martin+Fowler+Code+Complete+by+Steve+McConnell&amp;qid=1556627684&amp;s=gateway&amp;sr=8-1-fkmr0" rel="nofollow" target="_blank"> Refactoring: Improving the Design of Existing Code by Martin Fowler</a></li> <li><a href="https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?keywords=Code+Complete+by+Steve+McConnell&amp;qid=1556627732&amp;s=gateway&amp;sr=8-1" rel="nofollow" target="_blank"> Code Complete by Steve McConnell</a></li> <li><a href="https://www.raywenderlich.com" rel="nofollow" target="_blank">iOS Development Tutorials by Ray Wenderlich</a></li> <li><a href="https://www.objc.io" rel="nofollow" target="_blank">A weekly video series on Swift programming</a></li> <li><a href="https://www.hackingwithswift.com" rel="nofollow" target="_blank">A hands-on guide to learning Swift</a></li> <li>Subscription learning platforms <a href="https://subscription.packtpub.com/" rel="nofollow" target="_blank">Packt</a> and <a href="https://www.lynda.com/" rel="nofollow" target="_blank">Lynda.com</a></li> </ul> If you’ve been following Build for a while, you may recall I did an episode with Jessica Hische who is a letter, illustrator, and type designer a few years ago on a similar topic: How To Prepare To Strike Out On Your Own And Pursue Your Creative Calling. <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_Ep17.mp3" rel="noopener nofollow" target="_blank">Listen to the episode here.</a> I always find it helpful to revisit a topic and compare notes, plus some people’s voice resonates more than others, so I’d highly recommend you check out that episode too! -- Build is produced by <a href="http://femgineer.com/" rel="noopener nofollow" target="_blank">Femgineer</a>.

Episode 90: How To Get Started As A Freelance Software Developer

I am the self-appointed family travel agent. Though if you ask my partner and the rest of my family members they’d agree that I am the best person for the job.   Why?   Because over the years I have become adept at making sure I don’t overlook the details when planning a vacation—you know where the devil hides! And who wants the devil to turn up on their vacation?!   Unless of course, it’s a blue devil ;) #marchmadness #goduke   I take the time to read through ALL the descriptions and fine print, talk to customer support agents to find out if there are any additional fees, and make sure that family members who have accessibility needs like my 10-month-old baby and 82-year-old grandma will be taken care of.   Once I’ve done all this planning, I know I have truly earned my vacation ;)   Despite all my effort, there have been times when things didn’t turn out as planned. Like the time I booked a home in India only to find out that the address was incorrect. The host mixed the street name with the city name. We would have had to drive 3 hours after 24+ hours of travel, but I called customer support and they resolved the issue for us quickly.   It was a positive customer support experience: responsive, seamless, and efficient. As a result, I continued using that service to book my travel, knowing that if something screwy happened I could count on them next time.   But there are other companies whose customer support agents place me on hold—for more than a few minutes. When the agent returns, they tell me that I’ve reached the wrong department. Then they transfer me to the “correct” department. Once the transfer is complete, I have to repeat what I told the first support person to the second support person, all the while hoping that they can help me resolve the issue. They can’t. When I look at how much time I’ve spent, and the exorbitant fee or unreconcilable charge, I am frustrated and vow to never do business with them again!   I know I’m not alone.   No one likes being at the receiving end of a bad customer support experience. It’s easy to place blame on customer support, but it’s not their fault because the problem originated somewhere else—when the product or service’s feature was being created.   Someone designed the experience in a way that wasn’t particularly customer friendly, and then it became a challenge to change the experience because of the silos that formed in the company between teams: sales, marketing, product, engineering, and customer support.   At the start of a company, teams are usually flat and highly collaborative, but over time, silos start to form, slowing things down, making it hard to innovate, and distancing teams from their customers.   Is it even possible to slow or stop them from forming? And to enable everyone across teams a chance to interact with customers?   Well in today’s episode of Build we’re going to answer these questions and more, We’ll show how silos form of overtime, some best practices for keeping silos at bay, and what to do once they have formed to break them down.   To help us out I’ve invited Nichole Elizabeth DeMeré who is a B2B SaaS Consultant with 20+ years of experience in online marketing, and a champion for customer success.   As you tune into today’s episode you’ll learn the following from Nichole Elizabeth:    Why everyone on a team including software developers and engineers should have a chance to interact with customers, not just people who are on the customer support, sales, and marketing teams How to empower teams to break down silos, and a framework for evaluating experiments and features that factor in constraints When to automate and when to interact with customers How silos form over time, how to avoid them, and what to do once they’ve formed Why when building B2B products it’s important to focus on making your customers successful not happy Why you need to rethink off-boarding customers and make it easy for them to leave    “When everyone on the team is aware of the voice of the customer, everyone is super excited about what is going on (with the product).   If you really want to stand out right now it isn’t pricing, it’s team alignment and customer experience.” — Nichole Elizabeth DeMeré   In the episode, Nichole Elizabeth mentions a number of resources, here are links to them:    Net promoter score (NPS)  How Transparency In SaaS Offboarding Reduces Churn by Shayla Price Customer obsession course with Lara Weaver SaaS Growth Playbook with Trevor Hatfield Appcues Segment.io Wootric  -- Build is produced by Femgineer (http://femgineer.com/).

I am the self-appointed family travel agent. Though if you ask my partner and the rest of my family members they’d agree that I am the best person for the job. Why? Because over the years I have become adept at making sure I don’t overlook the details when planning a vacation—you know where the devil hides! And who wants the devil to turn up on their vacation?! Unless of course, it’s a blue devil ;) #marchmadness #goduke I take the time to read through ALL the descriptions and fine print, talk to customer support agents to find out if there are any additional fees, and make sure that family members who have accessibility needs like my 10-month-old baby and 82-year-old grandma will be taken care of. Once I’ve done all this planning, I know I have truly earned my vacation ;) Despite all my effort, there have been times when things didn’t turn out as planned. Like the time I booked a home in India only to find out that the address was incorrect. The host mixed the street name with the city name. We would have had to drive 3 hours after 24+ hours of travel, but I called customer support and they resolved the issue for us quickly. It was a positive customer support experience: responsive, seamless, and efficient. As a result, I continued using that service to book my travel, knowing that if something screwy happened I could count on them next time. But there are other companies whose customer support agents place me on hold—for more than a few minutes. When the agent returns, they tell me that I’ve reached the wrong department. Then they transfer me to the “correct” department. Once the transfer is complete, I have to repeat what I told the first support person to the second support person, all the while hoping that they can help me resolve the issue. They can’t. When I look at how much time I’ve spent, and the exorbitant fee or unreconcilable charge, I am frustrated and vow to never do business with them again! I know I’m not alone. No one likes being at the receiving end of a bad customer support experience. It’s easy to place blame on customer support, but it’s not their fault because the problem originated somewhere else—when the product or service’s feature was being created. Someone designed the experience in a way that wasn’t particularly customer friendly, and then it became a challenge to change the experience because of the silos that formed in the company between teams: sales, marketing, product, engineering, and customer support. At the start of a company, teams are usually flat and highly collaborative, but over time, silos start to form, slowing things down, making it hard to innovate, and distancing teams from their customers. Is it even possible to slow or stop them from forming? And to enable everyone across teams a chance to interact with customers? Well in today’s episode of Build we’re going to answer these questions and more, We’ll show how silos form of overtime, some best practices for keeping silos at bay, and what to do once they have formed to break them down. To help us out I’ve invited <a href="https://nicholeelizabethdemere.com/" rel="nofollow" target="_blank">Nichole Elizabeth DeMeré</a> who is a B2B SaaS Consultant with 20+ years of experience in online marketing, and a champion for customer success. As you tune into today’s episode you’ll learn the following from Nichole Elizabeth: <ul> <li>Why everyone on a team including software developers and engineers should have a chance to interact with customers, not just people who are on the customer support, sales, and marketing teams</li> <li>How to empower teams to break down silos, and a framework for evaluating experiments and features that factor in constraints</li> <li>When to automate and when to interact with customers</li> <li>How silos form over time, how to avoid them, and what to do once they’ve formed</li> <li>Why when building B2B products it’s important to focus on making your customers successful not happy</li> <li>Why you need to rethink off-boarding customers and make it easy for them to leave</li> </ul> “When everyone on the team is aware of the voice of the customer, everyone is super excited about what is going on (with the product). If you really want to stand out right now it isn’t pricing, it’s team alignment and customer experience.” — Nichole Elizabeth DeMeré In the episode, Nichole Elizabeth mentions a number of resources, here are links to them: <ul> <li><a href="https://en.wikipedia.org/wiki/Net_Promoter" rel="nofollow" target="_blank">Net promoter score (NPS)</a></li> <li><a href="https://nicholeelizabethdemere.com/how-transparency-in-saas-offboarding-reduces-churn/" rel="nofollow" target="_blank"> How Transparency In SaaS Offboarding Reduces Churn by Shayla Price</a></li> <li><a href="http://www.purposebeyondproduct.com/" rel="nofollow" target="_blank">Customer obsession course with Lara Weaver</a></li> <li><a href="https://www.saasgrowthplaybook.com/" rel="nofollow" target="_blank">SaaS Growth Playbook with Trevor Hatfield</a></li> <li><a href="https://www.appcues.com/" rel="nofollow" target="_blank">Appcues</a></li> <li><a href="https://segment.com/" rel="nofollow" target="_blank">Segment.io</a></li> <li><a href="https://www.wootric.com/" rel="nofollow" target="_blank">Wootric</a></li> </ul> -- Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>).

Episode 89: Why Everyone Working On A Product Needs To Be Aware Of The Voice Of The Customer

We began this month exploring the theme of career transitions. In the first Build episode for this month, we talked about why even if we want to transition in our careers, we don’t and get stuck in a role. If you missed the last episode of Build you can check it out here. If you were wondering how to get unstuck, then today’s episode is for you! We’re continuing our conversation with Amy Sun who is a partner at Sequoia Capital, a venture capital firm. Amy began her career as a product manager, transitioned to a product manager and most recently became a venture capitalist. Having gone through a number of transitions herself, she’s learned to navigate them in a number of contexts. Even if you aren’t going through a transition yourself, it’s a valuable episode to tune into, because as a teammate, hiring manager, or leader you may find yourself working with someone who is going through it, and you’ll be equipped to help them out! As you tune into today’s episode you’ll learn:   How to avoid being typecast into a role and be your own advocate   How to figure out what companies are looking for within a role   How long it can really take to go through a transition and how to keep your motivation up   Why short trial periods can be helpful, and how to set expectations and criteria for grading performance   How to get feedback and build awareness to improve   How to transition between companies versus across roles within a company   How to fill in skills gaps, build trust with peers, and present to leaders   “The opportunity won’t just present itself one today. Believe that you want it. And then tell people you want it. Sometimes you’ll get push back. Even if you do, you have to continue to fight for it, if you believe that’s the path that you want to go down.” — Amy Sun, Partner at Sequoia Capital __   Build is produced by Femgineer (http://femgineer.com/).

We began this month exploring the theme of career transitions. In the first Build episode for this month, we talked about why even if we want to transition in our careers, we don’t and get stuck in a role. If you missed the last episode of Build <a href="http://traffic.libsyn.com/femgineertv/Build_TV_-_Episode_50_-_Amy_Sun_-_Career_Transitions-Segment_2-REV2.mp3" rel="noopener nofollow" target="_blank">you can check it out here</a>. If you were wondering how to get unstuck, then today’s episode is for you! We’re continuing our conversation with Amy Sun who is a partner at Sequoia Capital, a venture capital firm. Amy began her career as a product manager, transitioned to a product manager and most recently became a venture capitalist. Having gone through a number of transitions herself, she’s learned to navigate them in a number of contexts. Even if you aren’t going through a transition yourself, it’s a valuable episode to tune into, because as a teammate, hiring manager, or leader you may find yourself working with someone who is going through it, and you’ll be equipped to help them out! As you tune into today’s episode you’ll learn: <ul> <li> How to avoid being typecast into a role and be your own advocate </li> <li> How to figure out what companies are looking for within a role </li> <li> How long it can really take to go through a transition and how to keep your motivation up </li> <li> Why short trial periods can be helpful, and how to set expectations and criteria for grading performance </li> <li> How to get feedback and build awareness to improve </li> <li> How to transition between companies versus across roles within a company </li> <li> How to fill in skills gaps, build trust with peers, and present to leaders </li> </ul> “The opportunity won’t just present itself one today. Believe that you want it. And then tell people you want it. Sometimes you’ll get push back. Even if you do, you have to continue to fight for it, if you believe that’s the path that you want to go down.” — Amy Sun, Partner at Sequoia Capital __ Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>).

Episode 88: What To Do When An Opportunity Won't Present Itself

Career transitions are tough for all of us. Leveling-up or transitioning into a new role or field is challenging because we have to prove that we can do the job, especially when our resume doesn’t reflect relevant or exact experience recruiters or hiring managers are looking for.   The countless rejections may cause us to want to stay in our current role and hope that someone will acknowledge our skills, talents, and efforts.   However, we cannot build a career on hope alone!   In today’s episode of Build, we’re going to share what holds people back from advocating for themselves successfully, and in the next episode, we’ll dig into ways you can make the transition happen.   To help us out, I’ve invited Amy Sun who is a partner at Sequoia Capital, a venture capital firm. In case you’re curious, Amy’s firm Sequoia Capital has been investing in companies since 1972. They have invested in 250+ companies, and some notable ones are Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp.   Last year at Grace Hopper, Sequoia Capital was the sponsor for a workshop I was co-teaching with Karen Catlin, which gave me the opportunity to meet Amy. After the workshop, Amy and I had the chance to chat, and I learned about her exciting background and thought it would be wonderful to share it with you.   What surprised me was that Amy didn’t start her career with the intention of becoming a venture capitalist; her first real job was as a snowboarding instructor!   After graduating from college, she began her career in tech as a product marketer, then eventually became a growth marketer and product manager.   As you tune into today’s episode, here’s what you’ll learn from Amy:    How to deal with the inner critic inside each of us who worries about: “What people are going to think” and get your foot in the door in spite of it How to suss out if you are missing experience How to handle roles that are and aren’t clearly defined or vary between companies The value of shadowing people and doing your homework How happenstance and luck play into transitions    “If you think about your career as the sum of all the knowledge you have—it’s not like you’re throwing away all the experience you’ve had in the past to start from scratch. Having a diverse set makes you more uniquely qualified for certain roles. So rather than holding yourself back by thinking: ‘Oh I don’t want to start from the ground (zero), and all my experience before is useless,’ think about it as compounding upon each other.” — Amy Sun, Partner at Sequoia Capital -- Build is produced by Femgineer (http://femgineer.com/).

Career transitions are tough for all of us. Leveling-up or transitioning into a new role or field is challenging because we have to prove that we can do the job, especially when our resume doesn’t reflect relevant or exact experience recruiters or hiring managers are looking for. The countless rejections may cause us to want to stay in our current role and hope that someone will acknowledge our skills, talents, and efforts. However, we cannot build a career on hope alone! In today’s episode of Build, we’re going to share what holds people back from advocating for themselves successfully, and in the next episode, we’ll dig into ways you can make the transition happen. To help us out, I’ve invited Amy Sun who is a partner at Sequoia Capital, a venture capital firm. In case you’re curious, Amy’s firm Sequoia Capital has been investing in companies since 1972. They have invested in 250+ companies, and some notable ones are Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram, Yahoo! and WhatsApp. Last year at Grace Hopper, Sequoia Capital was the sponsor for a workshop I was co-teaching with Karen Catlin, which gave me the opportunity to meet Amy. After the workshop, Amy and I had the chance to chat, and I learned about her exciting background and thought it would be wonderful to share it with you. What surprised me was that Amy didn’t start her career with the intention of becoming a venture capitalist; her first real job was as a snowboarding instructor! After graduating from college, she began her career in tech as a product marketer, then eventually became a growth marketer and product manager. As you tune into today’s episode, here’s what you’ll learn from Amy: <ul> <li>How to deal with the inner critic inside each of us who worries about: “What people are going to think” and get your foot in the door in spite of it</li> <li>How to suss out if you are missing experience</li> <li>How to handle roles that are and aren’t clearly defined or vary between companies</li> <li>The value of shadowing people and doing your homework</li> <li>How happenstance and luck play into transitions</li> </ul> “If you think about your career as the sum of all the knowledge you have—it’s not like you’re throwing away all the experience you’ve had in the past to start from scratch. Having a diverse set makes you more uniquely qualified for certain roles. So rather than holding yourself back by thinking: ‘Oh I don’t want to start from the ground (zero), and all my experience before is useless,’ think about it as compounding upon each other.” — Amy Sun, Partner at Sequoia Capital -- Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>).

Episode 87: How To Stop Holding Ourselves Back And Explore An Opportunity To Change Careers

 In the last episode of Build, Sarah Doody, who is a UX designer and entrepreneur, and I debunked many myths and misconceptions around UX (user experience) design, as well as the benefits to having a UX designer on your product team. In today’s episode, we’re going to switch gears and talk about what UX designers can do to stand out, and then share how companies can go about sourcing, vetting, and hiring a UX designer. Finally, we'll talk about how they can work with software engineers and product managers. I always learn a ton from Sarah, and I found this episode to be really insightful because aside from being a UX design herself, Sarah has reviewed the portfolios of 700+ UX designers!  So whether you are a UX designer yourself, or looking to work with one, I’d consider this a must watch Build episode. Here’s what you’ll learn from Sarah:  How to find and reach out to UX designers 3 Things UX Designers can do to stand out What UX designers can do if a past project hasn’t yet launched or there was no clear result How software engineers and product managers can work effectively with a UX designer How UX designers can avoid being overwhelmed by projects that aren’t related to the product  Here are links to the resources Sarah mentioned in the show and some additional resources to check out:  Design Value Index https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm Slack / Facebook Groups Related To UX Designer Hangout: https://www.designerhangout.co/ With Candles (for junior designers): withcandles.slack.com User Defenders: https://community.userdefenders.com/ UX Careers Tribe: http://www.facebook.com/groups/uxportfoliotribe (this is my group) Design X: https://designx.community/slack/ Mixed Methods: https://www.mixed-methods.org/community1/ UX Career Resources From Sarah UX Portfolio Formula (use code BUILDSHOW for 50% off): http://bit.ly/2t05Ztu Free UX Portfolio Blueprint: http://bit.ly/2t04yvp UX Careers &amp; Job Interview Playlist:  https://www.youtube.com/watch?v=H2_D298hAH0&amp;list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1  -- Build is produced by Femgineer (http://femgineer.com/). -- Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/

<a href="http://traffic.libsyn.com/femgineertv/Episode_48_-_UX-UI_-_Segment_1CCC.mp3" rel="nofollow" target="_blank"> In the last episode of Build</a>, Sarah Doody, who is a UX designer and entrepreneur, and I debunked many myths and misconceptions around UX (user experience) design, as well as the benefits to having a UX designer on your product team. In today’s episode, we’re going to switch gears and talk about what UX designers can do to stand out, and then share how companies can go about sourcing, vetting, and hiring a UX designer. Finally, we'll talk about how they can work with software engineers and product managers. I always learn a ton from Sarah, and I found this episode to be really insightful because aside from being a UX design herself, Sarah has reviewed the portfolios of 700+ UX designers!  So whether you are a UX designer yourself, or looking to work with one, I’d consider this a must watch Build episode. Here’s what you’ll learn from Sarah: <ul> <li>How to find and reach out to UX designers</li> <li>3 Things UX Designers can do to stand out</li> <li>What UX designers can do if a past project hasn’t yet launched or there was no clear result</li> <li>How software engineers and product managers can work effectively with a UX designer</li> <li>How UX designers can avoid being overwhelmed by projects that aren’t related to the product</li> </ul> Here are links to the resources Sarah mentioned in the show and some additional resources to check out: <ul> <li>Design Value Index <a href="https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm" rel="nofollow" target="_blank">https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm</a></li> <li>Slack / Facebook Groups Related To UX Designer Hangout: <a href="https://www.designerhangout.co/" rel="nofollow" target="_blank">https://www.designerhangout.co/</a> With Candles (for junior designers): <a href="http://withcandles.slack.com" rel="nofollow" target="_blank">withcandles.slack.com</a> User Defenders: <a href="https://community.userdefenders.com/" rel="nofollow" target="_blank">https://community.userdefenders.com/</a> UX Careers Tribe: <a href="http://www.facebook.com/groups/uxportfoliotribe" rel="nofollow" target="_blank">http://www.facebook.com/groups/uxportfoliotribe</a> (this is my group) Design X: https://designx.community/slack/ Mixed Methods: <a href="https://www.mixed-methods.org/community1/" rel="nofollow" target="_blank">https://www.mixed-methods.org/community1/</a></li> <li>UX Career Resources From Sarah UX Portfolio Formula (use code BUILDSHOW for 50% off): <a href="http://bit.ly/2t05Ztu" rel="nofollow" target="_blank">http://bit.ly/2t05Ztu</a> Free UX Portfolio Blueprint: <a href="http://bit.ly/2t04yvp" rel="nofollow" target="_blank">http://bit.ly/2t04yvp</a> UX Careers &amp; Job Interview Playlist: <a href="https://www.youtube.com/watch?v=H2_D298hAH0&amp;list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1" rel="nofollow" target="_blank"> https://www.youtube.com/watch?v=H2_D298hAH0&amp;list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1</a></li> </ul> -- Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>). -- Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: <a href="https://femgineer.com/confident-communicator-course/" rel="nofollow" target="_blank">https://femgineer.com/confident-communicator-course/</a>

Episode 86: How To Source, Vet, Hire, and Work With UX Designers

Happy February! It’s a brand new month, which means new Build episodes. If you’re new to Build or maybe missed episodes here and there, know that I’ve previously covered a number of topics related to design like design sprints, product debt, product redesign, accessibility, being a freelance designer, creative confidence, the rise of the design executive office, designing with empathy, and the art vs science of ux design. It turns out all those episodes weren’t enough, and there’s still a lot to cover! So this month we’re going back to the theme of design, and start by covering why it’s important to work with a user experience (UX) designer. Given the significant shift to designing user-friendly interfaces, it might feel like I am preaching to the choir. However, some companies still struggle to justify the work of a UX designer. Plus, given how young the field is, it’s continually evolving, and people are always writing in and requesting I cover design :) People still aren’t sure how a UX designer adds value, how to go about hiring and vetting them, and how they can work with software engineers and product managers effectively. Just like how software engineering has become more specialized over the years, design has faced a similar change. However, people still grapple to understand the nuances between a graphic, visual, and UX designer. In today’s episode, we’ll dive into the different types of designers out there. Then talk about some of the myths around user experience design. In next week’s episode, we’ll talk about what UX designers can do to stand out, how companies can go about hiring and vetting them, and how they can work effectively with software engineers and product managers. To help us out, I’ve invited Sarah Doody who is a UX designer and entrepreneur (formerly based in NYC). You’ll learn the following from Sarah:  Benefits of having a UX designer on your team from the beginning How to think of user research as an investment How to co-design and how it helps handle pushback and the handoff period How design-minded companies outperformed S&amp;P 500 for ten years  Here are links to the resources Sarah mentioned in the show and some additional resources to check out:  Design Value Index https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm Slack / Facebook Groups Related To UX Designer Hangout: https://www.designerhangout.co/ With Candles (for junior designers): withcandles.slack.com User Defenders: https://community.userdefenders.com/ UX Careers Tribe: http://www.facebook.com/groups/uxportfoliotribe (this is my group) Design X: https://designx.community/slack/ Mixed Methods: https://www.mixed-methods.org/community1/ UX Career Resources From Sarah UX Portfolio Formula (use code BUILDSHOW for 50% off): http://bit.ly/2t05Ztu Free UX Portfolio Blueprint: http://bit.ly/2t04yvp UX Careers &amp; Job Interview Playlist: https://www.youtube.com/watch?v=H2_D298hAH0&amp;list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1  -- Build is produced by Femgineer (http://femgineer.com/). -- Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/

Happy February! It’s a brand new month, which means new Build episodes. If you’re new to Build or maybe missed episodes here and there, know that I’ve previously covered a number of topics related to design like <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_EP34_-_Segment_1_mixdown.mp3" rel="noopener nofollow" target="_blank">design sprints</a>, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_-_Tip_Leslie_Yang-2_mixdown.mp3" rel="noopener nofollow" target="_blank">product debt</a>, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_-_Tip_Leslie_Yang-1_mixdown.mp3" rel="noopener nofollow" target="_blank">product redesign</a>, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_EP36_-_Laura_Allen_-_Segment_1_mixdown.mp3" rel="noopener nofollow" target="_blank">accessibility</a>, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_Ep17.mp3" rel="nofollow" target="_blank">being a freelance designer</a>, <a href="http://femgineertv.libsyn.com/episode-16-how-practicing-creative-confidence-can-help-you-embrace-risk" rel="noopener nofollow" target="_blank">creative confidence</a>, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_Ep13.mp3" rel="noopener nofollow" target="_blank">the rise of the design executive office</a>, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_Ep4.mp3" rel="noopener nofollow" target="_blank">designing with empathy</a>, and <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_Ep7.mp3" rel="noopener nofollow" target="_blank">the art vs science of ux design</a>. It turns out all those episodes weren’t enough, and there’s still a lot to cover! So this month we’re going back to the theme of design, and start by covering why it’s important to work with a user experience (UX) designer. Given the significant shift to designing user-friendly interfaces, it might feel like I am preaching to the choir. However, some companies still struggle to justify the work of a UX designer. Plus, given how young the field is, it’s continually evolving, and people are always writing in and requesting I cover design :) People still aren’t sure how a UX designer adds value, how to go about hiring and vetting them, and how they can work with software engineers and product managers effectively. Just like how software engineering has become more specialized over the years, design has faced a similar change. However, people still grapple to understand the nuances between a graphic, visual, and UX designer. In today’s episode, we’ll dive into the different types of designers out there. Then talk about some of the myths around user experience design. In next week’s episode, we’ll talk about what UX designers can do to stand out, how companies can go about hiring and vetting them, and how they can work effectively with software engineers and product managers. To help us out, I’ve invited Sarah Doody who is a UX designer and entrepreneur (formerly based in NYC). You’ll learn the following from Sarah: <ul> <li>Benefits of having a UX designer on your team from the beginning</li> <li>How to think of user research as an investment</li> <li>How to co-design and how it helps handle pushback and the handoff period</li> <li>How design-minded companies outperformed S&amp;P 500 for ten years</li> </ul> Here are links to the resources Sarah mentioned in the show and some additional resources to check out: <ul> <li>Design Value Index <a href="https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm" rel="nofollow" target="_blank">https://www.dmi.org/page/DesignValue/The-Value-of-Design-.htm</a></li> <li>Slack / Facebook Groups Related To UX Designer Hangout: <a href="https://www.designerhangout.co/" rel="nofollow" target="_blank">https://www.designerhangout.co/</a> With Candles (for junior designers): <a href="http://withcandles.slack.com" rel="nofollow" target="_blank">withcandles.slack.com</a> User Defenders: <a href="https://community.userdefenders.com/" rel="nofollow" target="_blank">https://community.userdefenders.com/</a> UX Careers Tribe: <a href="http://www.facebook.com/groups/uxportfoliotribe" rel="nofollow" target="_blank">http://www.facebook.com/groups/uxportfoliotribe</a> (this is my group) Design X: https://designx.community/slack/ Mixed Methods: <a href="https://www.mixed-methods.org/community1/" rel="nofollow" target="_blank">https://www.mixed-methods.org/community1/</a></li> <li>UX Career Resources From Sarah UX Portfolio Formula (use code BUILDSHOW for 50% off): <a href="http://bit.ly/2t05Ztu" rel="nofollow" target="_blank">http://bit.ly/2t05Ztu</a> Free UX Portfolio Blueprint: <a href="http://bit.ly/2t04yvp" rel="nofollow" target="_blank">http://bit.ly/2t04yvp</a> UX Careers &amp; Job Interview Playlist: <a href="https://www.youtube.com/watch?v=H2_D298hAH0&amp;list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1" rel="nofollow" target="_blank">https://www.youtube.com/watch?v=H2_D298hAH0&amp;list=PL73Nci5CBE-7OFGFhYawlJh9bYZd-a-b1</a></li> </ul> -- Build is produced by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>). -- Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: <a href="https://femgineer.com/confident-communicator-course/" rel="nofollow" target="_blank">https://femgineer.com/confident-communicator-course/</a>

Episode 85: Top 3 Reasons Your Team Needs A UX Designer From The Beginning

Do you ever feel like you’re caught between making personal concessions and compromises in order to advance professionally?   I felt this way less than six months ago.   I was getting ready to transition from maternity leave back to work. Part of my transition plan was to initially work part-time so that I’d have time to rest and take care of my little one.  Running my own business would give me the freedom and flexibility I needed to do this.   However, during my maternity leave, I became overly concerned with providing for my little one. As I transitioned back to work, I decided I need to think about taking on more clients.   A dear friend of mine had advised me to create a document with non-negotiables so that I wouldn’t be tempted to make concessions and compromises for things I needed from a client.   But I was concerned about how clients would perceive my non-negotiables.   In today’s episode of Build, I’m going to share how I went through this transition last year.   Once you’ve listened the episode, I’d like to know what was the last career transition that was spurred by a life event for you? How did you manage to pull through without compromising on what you needed? Feel free to tweet your response to @poornima. -- Build is brought to you by Femgineer (http://femgineer.com/). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/ --  Enjoyed this episode and want to support the show? To become a patron of the show visit: https://www.patreon.com/build -- ## Easy to Set Non-Negotiables But Hard To Stick To Them Transcript   Career transitions are tough. Especially when they are spurred by life events.   They can feel endless, overwhelming, and cause us to shortchange ourselves by making concessions and compromises on what we need.   In today’s Build episode I’m going to share a recent transition I went through and how I managed to get through.   So stay tuned!   Welcome to Build. The show that debunks a number of myths and misconceptions related to building products, companies and your career in tech.   I’m your host Poornima Vijayashanker.   I had previously mentioned that I’d be experimenting with the format of Build, so today’s show is a solo show with just me.   I’m curious to hear your take on it. As always, feel free to leave a comment below. I don’t always have time to respond but I’m always listening, reading, and learning from audience members like you ;)   Last year, in the midst of my maternity leave I started to worry, more so than I usually do, and specifically about money.   I had previously written some blog posts about how I had gone through a round of interviews at companies, and ultimately decided that running my own business was going to provide me the most flexibility and freedom.   Somehow all the logic had seeped out of my postpartum brain and been replaced with a need to provide for my newly born child.   Despite being a good saver, and being a part of a dual income household, staring at my medical bill for the delivery made me worry about all the unexpected expenses that would start creeping up.   I’m a strong believer that I tight budget isn’t enough. You also have to make money.   So I thought about all the things I could do. I could answer all the emails that were piling up from recruiters or I could start working on the course I wanted to offer in the fall.   But this was 6 weeks into my maternity leave, I was having a really hard time summoning the energy to do something new.   Not to mention having the time to do it.   I’d need time and energy to either prepare for interviews or market a new course. Plus I’d have to persuade others that I was credible.   I re-read my own advice, and realized I needed to find a way to cash in on credibility that I had already built up without compromising on my non-negotiables.   That meant instead of proving myself to someone new, I needed to go back to working with people who knew I was credible.   I called up a client that I had worked for back in 2014 and 2015 to see if they needed help. They did and they didn’t need it until I was done with my maternity leave. So the timing was on my side.   There were just two catches: I need to commute up to SF and they had reduced their contractor rates.   Both of these directly conflicted with 2 of my non-negotiables, which were working commuting only two days a week and my rate.   I decided I wasn’t going to budge on how I priced myself, and told my client to check if there was more budget.   I reminded my client that I was reliable, and they remembered the quality of work that I had done.   I was also fortunate to have others vouch for me.   I put the ball in my client’s court and waited patiently for their response.   My client came back and asked me if I would accept working 2 days at the rate that fit into their budget.   I happily agree to the terms because it was exactly what I needed as I transitioned back to work.   What I re-learned is that you can go back to a client or company, especially if you have built up credibility there, and it helps to have more than one person vouch for you.   Finally, I re-learned the importance of having set non-negotiables.   As I was negotiating on the phone call, I made sure to pull them up and have them stare right at me!   Now, if you’re willing to share, I’d like to know what was the last career transition that was spurred by a life event for you? How did you manage to pull through without compromising on what you needed? Please let me know in the comments below!   That’s it for this episode of Build. Feel free to share it with your teammates, your friends, and whomever you think might be going through a tough transition.   And subscribe to our YouTube channel to receive more episodes.   Ciao for now!

Do you ever feel like you’re caught between making personal concessions and compromises in order to advance professionally? I felt this way less than six months ago. I was getting ready to transition from maternity leave back to work. Part of my transition plan was to initially work part-time so that I’d have time to rest and take care of my little one. <a href="https://hackernoon.com/you-cant-prepare-for-parenthood-but-you-can-prioritize-parental-leave-50d7b6495d7f" rel="nofollow" target="_blank"> Running my own business would give me the freedom and flexibility I needed to do this.</a> However, during my maternity leave, I became overly concerned with providing for my little one. As I transitioned back to work, I decided I need to think about taking on more clients. A dear friend of mine had advised me to create a document with non-negotiables so that I wouldn’t be tempted to make concessions and compromises for things I needed from a client. But I was concerned about how clients would perceive my non-negotiables. In today’s episode of Build, I’m going to share how I went through this transition last year. Once you’ve listened the episode, I’d like to know what was the last career transition that was spurred by a life event for you? How did you manage to pull through without compromising on what you needed? Feel free to tweet your response to <a href="https://twitter.com/poornima" rel="nofollow" target="_blank">@poornima</a>. -- Build is brought to you by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: <a href="https://femgineer.com/confident-communicator-course/" rel="nofollow" target="_blank">https://femgineer.com/confident-communicator-course/</a> --  Enjoyed this episode and want to support the show? To become a patron of the show visit: <a href="https://www.patreon.com/build" rel="nofollow" target="_blank">https://www.patreon.com/build</a> -- ## Easy to Set Non-Negotiables But Hard To Stick To Them Transcript Career transitions are tough. Especially when they are spurred by life events. They can feel endless, overwhelming, and cause us to shortchange ourselves by making concessions and compromises on what we need. In today’s Build episode I’m going to share a recent transition I went through and how I managed to get through. So stay tuned! Welcome to Build. The show that debunks a number of myths and misconceptions related to building products, companies and your career in tech. I’m your host Poornima Vijayashanker. I had previously mentioned that I’d be experimenting with the format of Build, so today’s show is a solo show with just me. I’m curious to hear your take on it. As always, feel free to leave a comment below. I don’t always have time to respond but I’m always listening, reading, and learning from audience members like you ;) Last year, in the midst of my maternity leave I started to worry, more so than I usually do, and specifically about money. I had previously written some blog posts about how I had gone through a round of interviews at companies, and ultimately decided that running my own business was going to provide me the most flexibility and freedom. Somehow all the logic had seeped out of my postpartum brain and been replaced with a need to provide for my newly born child. Despite being a good saver, and being a part of a dual income household, staring at my medical bill for the delivery made me worry about all the unexpected expenses that would start creeping up. I’m a strong believer that I tight budget isn’t enough. You also have to make money. So I thought about all the things I could do. I could answer all the emails that were piling up from recruiters or I could start working on the course I wanted to offer in the fall. But this was 6 weeks into my maternity leave, I was having a really hard time summoning the energy to do something new. Not to mention having the time to do it. I’d need time and energy to either prepare for interviews or market a new course. Plus I’d have to persuade others that I was credible. I re-read my own advice, and realized I needed to find a way to cash in on credibility that I had already built up without compromising on my non-negotiables. That meant instead of proving myself to someone new, I needed to go back to working with people who knew I was credible. I called up a client that I had worked for back in 2014 and 2015 to see if they needed help. They did and they didn’t need it until I was done with my maternity leave. So the timing was on my side. There were just two catches: I need to commute up to SF and they had reduced their contractor rates. Both of these directly conflicted with 2 of my non-negotiables, which were working commuting only two days a week and my rate. I decided I wasn’t going to budge on how I priced myself, and told my client to check if there was more budget. I reminded my client that I was reliable, and they remembered the quality of work that I had done. I was also fortunate to have others vouch for me. I put the ball in my client’s court and waited patiently for their response. My client came back and asked me if I would accept working 2 days at the rate that fit into their budget. I happily agree to the terms because it was exactly what I needed as I transitioned back to work. What I re-learned is that you can go back to a client or company, especially if you have built up credibility there, and it helps to have more than one person vouch for you. Finally, I re-learned the importance of having set non-negotiables. As I was negotiating on the phone call, I made sure to pull them up and have them stare right at me! Now, if you’re willing to share, I’d like to know what was the last career transition that was spurred by a life event for you? How did you manage to pull through without compromising on what you needed? Please let me know in the comments below! That’s it for this episode of Build. Feel free to share it with your teammates, your friends, and whomever you think might be going through a tough transition. And subscribe to our YouTube channel to receive more episodes. Ciao for now!

Episode 84: Easy to Set Non-Negotiables But Hard To Stick To Them

 In the last episode of Build, Paul Jarvis who is the author of Company of One and I, challenged the commonly held myth that that you need to you need to keep growing and scaling your company, otherwise you’re not innovating and you’ll soon start to stagnate.   We also debunked myths related to it such as falling prey to a big competitor and needing to be a leader who cannot fail.   The big takeaway was to question growth for growth’s sake.   The episode might also have brought up a number of questions for you like, “What about me? I work in a BIG company! Does that mean I’m not innovative? Do I need to run a one-person business? Do I have to be ant-growth?”   Absolutely not!   The Company of One doesn’t mean to be prescriptive or claim that there is only one way of doing business. Rather it’s building awareness for what is changing, and how those changes could help you. For example, if you are looking for more flexibility and freedom, you could work remotely or you could build a lifestyle business.   And if you’re still wondering, “How Poornima and Paul? How do I do these things?”  Well, tune into today’s episode. In it, we share some of Paul’s proven best practices.   As you tune in to this episode you’ll learn the following from Paul:    Why studies of companies often deviate from best practices, and what really happens when companies grow too quickly Why Paul killed off profitable products and lines of business The “gotcha” moments Paul went through as he was building his company—how they have served as proof for his best practices How you can apply the Company of One mindset to a big company    “A company of one isn’t just a one-person business. It’s not anti-growth or anti-revenue. It’s just a business that questions whether growth is right for founders, employees, and customers, and for the long term success of the business.” — Paul Jarvis   Want  to receive a copy of Paul’s upcoming book Company of One?   If you become a patron of Build on Patreon at the Silver or Gold tiers, I’ll make sure you receive an e-book copy of Paul’s book as well books from other authors I feature on the show. And if you’re one of those who loves a signed copy of a hardcover, then consider being a Platinum Patron. To become a patron visit Build’s Patreon page here.   -- Build is brought to you by Femgineer (http://femgineer.com/). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/ --  Enjoyed this episode and want to support the show? To become a patron of the show visit: https://www.patreon.com/build

<a href="http://traffic.libsyn.com/femgineertv/Episode_47_-_Paul_Jarvis_-_Segment_1.mp3" rel="nofollow" target="_blank"> In the last episode of Build,</a> Paul Jarvis who is the author of <a href="https://ofone.co/" rel="nofollow" target="_blank">Company of One</a> and I, challenged the commonly held myth that that you need to you need to keep growing and scaling your company, otherwise you’re not innovating and you’ll soon start to stagnate. We also debunked myths related to it such as falling prey to a big competitor and needing to be a leader who cannot fail. The big takeaway was to question growth for growth’s sake. The episode might also have brought up a number of questions for you like, “What about me? I work in a BIG company! Does that mean I’m not innovative? Do I need to run a one-person business? Do I have to be ant-growth?” Absolutely not! The Company of One doesn’t mean to be prescriptive or claim that there is only one way of doing business. Rather it’s building awareness for what is changing, and how those changes could help you. For example, if you are looking for more flexibility and freedom, you could work remotely or you could build a lifestyle business. And if you’re still wondering, “How Poornima and Paul? How do I do these things?”  Well, tune into today’s episode. In it, we share some of Paul’s proven best practices. As you tune in to this episode you’ll learn the following from Paul: <ul> <li>Why studies of companies often deviate from best practices, and what really happens when companies grow too quickly</li> <li>Why Paul killed off profitable products and lines of business</li> <li>The “gotcha” moments Paul went through as he was building his company—how they have served as proof for his best practices</li> <li>How you can apply the Company of One mindset to a big company</li> </ul> “A company of one isn’t just a one-person business. It’s not anti-growth or anti-revenue. It’s just a business that questions whether growth is right for founders, employees, and customers, and for the long term success of the business.” — Paul Jarvis Want  to receive a copy of Paul’s upcoming book <a href="https://ofone.co/" rel="nofollow" target="_blank">Company of One</a>? If you become a patron of Build on Patreon at the Silver or Gold tiers, I’ll make sure you receive an e-book copy of Paul’s book as well books from other authors I feature on the show. And if you’re one of those who loves a signed copy of a hardcover, then consider being a Platinum Patron. <a href="https://www.patreon.com/build" rel="nofollow" target="_blank">To become a patron visit Build’s Patreon page here.</a> -- Build is brought to you by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: <a href="https://femgineer.com/confident-communicator-course/" rel="nofollow" target="_blank">https://femgineer.com/confident-communicator-course/</a> --  Enjoyed this episode and want to support the show? To become a patron of the show visit: <a href="https://www.patreon.com/build" rel="nofollow" target="_blank">https://www.patreon.com/build</a>

Episode 83: Why Staying Small Can Be A Great Business Strategy

Build is a weekly podcast brought to you by Pivotal Tracker hosted by Poornima Vijayashanker, the founder of Femgineer. In this show, Poornima hosts innovators in tech and together they debunk myths and misconceptions related to building tech products and companies.

Poornima and her guests do a phenomenal job of simplifying complex ideas surrounding technology and software in a structured, entertaining way.

Highly recommend listening and subscribing to Build if you want the knowledge AND mindset to level up and better understand future applications of this evolving field!

Awesome show, highly recommend!

Love the work Poornima does, every interview is insipiring and informative ! :)

Awesome Advice

Build is a weekly podcast brought to you by Pivotal Tracker hosted by Poornima Vijayashanker, the founder of Femgineer. In this show, Poornima hosts innovators in tech and together they debunk myths and misconceptions related to building tech products and companies.

Build

Episode 59: Why You Need To Rethink Your Approach to Diversity And Inclusion

Episode 74: How To Interview Product Managers

Episode 75: How To Train and Retain Top Product Managers

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&amp;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!

Episode 78: Why Build A Brand New Product Instead Of Rebuilding Or Redesigning One

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.

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: <ul> <li>How product management has evolved over the years</li> <li>Why you need to think about the type of product manager you are looking for (hint: there is more than one persona!)</li> <li>How to communicate the key criteria you are looking for in a candidate</li> <li>How to build a pipeline of candidates</li> <li>How to train recruiters to help screen candidates</li> <li>How to stop hiring out of desperation</li> <li>Why it’s actually helpful to give candidates a quick no</li> </ul> -- Build is produced as a partnership between <a href="http://femgineer.com/" rel="nofollow" target="_blank">Femgineer</a> and <a href="http://pivotaltracker.com/" rel="nofollow" target="_blank">Pivotal Tracker</a>. San Francisco video production by <a href="http://www.startmotionmedia.com/" rel="nofollow" target="_blank">StartMotionMEDIA</a>. -- ## 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.

Episode 73: How To Hire Product Managers

In the last Build episode, we talked shared  two ground rules you need to set for yourself to get through a software project successfully. But we know that managing our own anxieties is only half the battle to keeping the project on course, the other is navigating new ideas or unanticipated challenges.   Many of our teammates have ideas and solutions that can help. They are eager to have their ideas heard, so they speak up. While others are shy and worried about speaking up. But their insights and ideas can save the project!   As the project lead you know it’s important to hear your teammates out to uncover challenges early on and prevent them from derailing your progress. But how do you encourage and instill confidence in the introverted ones, and is there ever a point where you can stop entertaining new ideas and start building? -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. --  ##Project Management: How to Respond to New Ideas in the Middle of a Software Project Transcript                   Poornima: In the last episode, we addressed a number of anxieties that come up when you're managing your first high-stakes project. If you missed the episode, the link to it is below this video.  Today we're gonna tackle how do you handle getting blindsided by your teammates when there are new ideas or challenges on a project you're working on. So stay tuned to find out more.  Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, I host innovators, and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech.  We'll continue our conversation about managing your first high-stakes project with Jen Leech, who is the VP of Engineering at Truss, which is a software consultancy. Thanks again for joining us, Jen.   Jen Leech: Sure, absolutely.   How to respond to brand new ideas that may cause you to miss your software project’s deadline   Poornima: So, Jen, based on our conversation last week, I know you're awesome at listening to people, incorporating their feedback, and putting a plan into action, but there comes that time usually in the middle or towards the end of the project where somebody's got a brand-new idea and you are worried about the deadline and making progress. Do you have any rules or mantras for how to handle this situation?   Jen Leech: Yeah. In general, I love it when people bring new ideas to the table. That's what I want. That means that they're engaged, they're thinking creatively, that they feel some investment in the project. I wanna encourage that as much as possible.  If the idea that they're bringing to the table is a simple one, it's great. It's pretty easy to think about, pretty easy to reason about, and you can go with it or not go with it and move forward. The complexity comes in when the idea they're bringing to the table is something that is a much larger idea, or it has implications beyond the implementation of that idea itself. In those cases, I don't always know what the results would be of implementing that idea. As someone who's experienced leading projects, I may have an intuition for it. I may be wrong, following along from my last episode.   How to teach teammates to think through their ideas and the impact it will have on a software project  But the thing that I do in that situation is I ask the person who's presenting the idea to take their idea and follow it through to its ultimate conclusion. So that means asking them to say, "OK, so..." Using the example from our last episode, of a microservices architecture, I say, "Well, we have problems A, B, and C, and D in the system. And I think that a microservices architecture is gonna solve it." And then, as a project lead, I can say to them, "OK, well so let's say that we move forward with that. What are the implications for the project? Does it mean that we're gonna have more service support? Does it mean that we are going to have to have a different team structure? Does it mean that we are going to have new work in our backlog that wasn't there already? What is that work?"  And then ask them to think through their problem. In the case of microservices architecture, that might go something like, "Well, that means that we have to make sure that these units that we're turning into microservices are independently deployable, they're independently testable, that they have a well-defined interface, that that interface is versioned, that we have someone who is keeping track of what all of the requirements are from consumers of the interface." So you might need to have a product manager. The list of potential implication gets bigger and bigger, and then all of a sudden you need an entire team to manage this one component.  And then, we can look at that and say, "If this does solve the things that you're saying it solves, it's the cost of potentially increasing our headcount by x. Justify that benefit. Or are there other ways we can get the same benefit?"  Essentially asking the person to walk through all of the implications from the leadership perspective.   When it makes sense to adopt a new idea in the middle of a software project   Poornima: From their idea that they're putting out there.   Jen Leech: Correct. Think about what that really means for the company as a whole. Then it facilitates them realizing assumptions that they have made or costs that they have envisaged, and when you get to the end of it, either you're on the same page and you say, "That was a great idea, we should totally do that." Or you're on the same page and you say, "We should not do this." And you've gotten there together. So that means that the person who's brought these ideas to the table both feels like their idea has really been heard, and if it was an idea that you should not move forward with, they've convinced themselves. Then you can both move forward with whatever you agree is the right course of action.   How to instill confidence in teammates who are shy or reluctant to share their ideas   Poornima: I think some people would be up to that challenge, they may even think through their idea, but you've got a lot of people who are, just say, eager beavers. They may be new to the team, maybe they don't know this whole process or policies and just kind of blurt out in a meeting, like, "I've got an idea." Is that an appropriate time to say, "That's fantastic you have an idea, here's how we operate. We do X, Y, and Z. So let's have you walk through the implications, etc.?"   Jen Leech: That's a really good question. Sometimes a meeting is the right time to walk through that—depends on the meeting.   Poornima: Sure.   Jen Leech: A lot of times it's not. And in those cases then I'll usually say, "Oh, Kimmy, let's take that offline. Can we talk about that later?" And talk about it independently. However, through failure I have discovered that when bringing new people onto the team, they often need a little bit of intro. In this particular project that I was describing from last year, there were some new people that came into the team, stepped into these processes, started presenting new ideas, and then all of a sudden were blindsided when people started really probing into their ideas, and they weren't expecting it.  So then I had to take a step back and then I realized that I haven't given them the appropriate context. And I sat them down and I said, "Hey, I realize I didn't explain this, but in this team you should expect that we're gonna really thoroughly look at new ideas that are brought to the table, and we're gonna investigate them."   Poornima: I'd imagine it takes a lot of confidence even to just put an idea out there, so having it be shot down is going to impact people.   Jen Leech: Yeah, absolutely. What I started doing is I started having onboarding conversations, essentially, with new people who came onto the team to explain that we investigate ideas that are brought to the table really thoroughly, and that we do that with everyone. And it's not any particular person, there's not good, there's no bad, we just wanna understand what this idea means.  The particular person who I was talking to in this case hadn't yet seen somebody else go through the same process. Later on as we went through the process of exploring new ideas then it became more normalized. But I began having onboarding conversations with new people on the team to help them understand that we really investigate ideas really deeply, and that that's normal, and it's not to be taken personally.   When do you stop entertaining new ideas, building a consensus, and get to work on your software project   Poornima: So it's great that people are proposing ideas and that you're investigating them, but you remember from last time, we told our audience we would tackle this question. There's gotta be a point where you stop investigating, you've gotta stop consensus building or talking about the ideas, start making decisions and put a plan in place. So let's pick up that question.   Jen Leech: It depends on the problem but there are a few different approaches that you can use. One approach that I enjoy using is that of framing whatever question that we're looking at in terms of a hypothesis. And saying, "Well, right now we think we're trying to solve problem X." And then when you really target the problem you're trying to solve, it's easier to hone in on the specifics of does this solve that problem. Then, either it does or doesn't, then you can move on to the next thing.  When you're dealing with something more complex, let's say you're dealing with a system that is sufficiently complex such that you can't really say for sure what the result is gonna be, and furthermore, maybe you're trying to solve problems A, B, C, D, E, and F. Then there are a couple approaches I use in that circumstance. One is to say, "Let's build a quick and dirty prototype. Let's try it. Give it a limited amount of time, and see what happens." So you build out something very quickly. Ideally, you could do it in under a day, but it depends on what it is. And hopefully you've got your tools in place so you can do that. Maybe a week, but time box it.  At the end of it you then bring it back to the table and say, "Does it look to us like it's gonna be solving these problems? And what did we learn from the process?"   Poornima: So constraining the problem will hopefully constrain the conversation, and then creating a time box around when something is due will also create those constraints so that you stop that consensus building and get down to work.   Jen Leech: Yeah. And finding every piece of work you do, in terms of here are the problems we think we're trying to solve, here are the solutions we think might work, and make everything an experiment, a discovery of new information. And the discovery, at the end of the day, might be does this work for our customers.  As you frame it in terms of exploration and discovery, then it becomes natural to not have to have 100% solution. Because what you're doing is finding out.   Poornima: It's fantastic that you're making this a discovery and that you wanna get out there and explore more, but there's always that time where we think we've done a lot and still something comes up. Maybe even a customer says, "You didn't think through this enough." Or somebody on your team brings it up. What do you do in those moments?   Why it’s OK to constrain the problem space in your software project   Jen Leech: Right. I think of this as the curve ball question. You think that you have the right hypothesis, you think you have a good solution, and then all of a sudden something comes up that you didn't expect and you find that maybe what you've put together does not satisfy a certain circumstance or certain constraints.  In that circumstance, I think of it as having a new problem to solve. And when you have a new problem to solve the first question that I ask is, "How can I learn more about this problem? Who is on the team that knows about this? Who is in the organization that knows about this?" Maybe there's somebody in the finance department that can answer a question that we have. Who in the community can we talk to about this?  It's interesting because I find that taking a problem and expanding it beyond the scope of the team is something that I don't see nearly as often as I would expect, considering the fact that you have, clearly, a limited amount of information within the team.   Poornima: Limited brains.   Jen Leech: Limited brains, limited experience. And so it would seem completely natural to open questions up to a larger audience. And yet, it's easy for people to stay in their own little group and not necessarily bring in outside opinions.  This tactic is all about seeking new information. One example of this is when building this system that I was building last year. Some of the people who are gonna be using the system were data scientists. Some of them were experts on the data that we were processing.  Whenever a new component or a new feature came to the table as something that we needed to come up with a new design for, the first thing we would do is have kind of like a brainstorming session, but really more like an information gathering session where we would bring in everyone from the company, who might potentially have a real interest in the result or be a potential user of the product, and say all of the problems that they've ever had in this area that they want solutions to.  As an example, we were designing validations on data and we needed to understand a validation system existed before at this company. What did we like about that? What did we not like about it? And we had people who were not engineers, but who had to understand the correct use of the data, come to the room and tell us what their problems were.  This is a lot like user research. And then that led to a collection of problems that we eventually may have realized existed, but hadn't really framed as the problem that we were trying to solve here. And it dramatically impacted the design that we came up with.   Poornima: Let's do another example for our audience kind of playing that out.   Jen Leech: Another really, really good example is that we were using a tool for building the system that wasn't an open-source tool that had been built by Airbnb. It turned out that we had some questions about the right usage pattern, the right deployment pattern, some questions about how they manage the flow of data between nodes. And, coincidentally, it turns out that Airbnb was in the next building over.   Poornima: Oh, great. That's a great building by the way.   Jen Leech: Yeah, lucky. We contacted the maintainer of the co-depository and asked him if he would be willing to come and talk with us. And he said sure. So he came over and had an hour long conversation about how Airbnb uses the tool and various critiques and pluses and minuses of using it one way or another. And at the end of the conversation we had a much better idea of what things we were doing with it were good and we should keep on doing, and which things we needed to change. And it was about an hour of time for a huge improvement.   Poornima: I feel like this also helps you from causing more bugs because you know how to use the tool, or going through that drama of, "I don't know how this works."   Jen Leech: It saves you an immense amount of time to just ask the right questions to people who know things.   Poornima: That's fantastic. Thank you again for sharing these rules with us, Jen.   Jen Leech: Absolutely.

In the last Build episode, we talked shared <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_EP32_-_Segment_1_mixdown.mp3" rel="nofollow" target="_blank"> two ground rules</a> you need to set for yourself to get through a software project successfully. But we know that managing our own anxieties is only half the battle to keeping the project on course, the other is navigating new ideas or unanticipated challenges. Many of our teammates have ideas and solutions that can help. They are eager to have their ideas heard, so they speak up. While others are shy and worried about speaking up. But their insights and ideas can save the project! As the project lead you know it’s important to hear your teammates out to uncover challenges early on and prevent them from derailing your progress. But how do you encourage and instill confidence in the introverted ones, and is there ever a point where you can stop entertaining new ideas and start building? -- Build is produced as a partnership between <a href="http://femgineer.com/" rel="nofollow" target="_blank">Femgineer</a> and <a href="http://pivotaltracker.com/" rel="nofollow" target="_blank">Pivotal Tracker</a>. San Francisco video production by <a href="http://www.startmotionmedia.com/" rel="nofollow" target="_blank">StartMotionMEDIA</a>. --  ##Project Management: How to Respond to New Ideas in the Middle of a Software Project Transcript                 Poornima: In the last episode, we addressed a number of anxieties that come up when you're managing your first high-stakes project. If you missed the episode, the link to it is below this video. Today we're gonna tackle how do you handle getting blindsided by your teammates when there are new ideas or challenges on a project you're working on. So stay tuned to find out more. Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, I host innovators, and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech. We'll continue our conversation about managing your first high-stakes project with Jen Leech, who is the VP of Engineering at Truss, which is a software consultancy. Thanks again for joining us, Jen. Jen Leech: Sure, absolutely. How to respond to brand new ideas that may cause you to miss your software project’s deadline Poornima: So, Jen, based on our conversation last week, I know you're awesome at listening to people, incorporating their feedback, and putting a plan into action, but there comes that time usually in the middle or towards the end of the project where somebody's got a brand-new idea and you are worried about the deadline and making progress. Do you have any rules or mantras for how to handle this situation? Jen Leech: Yeah. In general, I love it when people bring new ideas to the table. That's what I want. That means that they're engaged, they're thinking creatively, that they feel some investment in the project. I wanna encourage that as much as possible. If the idea that they're bringing to the table is a simple one, it's great. It's pretty easy to think about, pretty easy to reason about, and you can go with it or not go with it and move forward. The complexity comes in when the idea they're bringing to the table is something that is a much larger idea, or it has implications beyond the implementation of that idea itself. In those cases, I don't always know what the results would be of implementing that idea. As someone who's experienced leading projects, I may have an intuition for it. I may be wrong, following along from my last episode. How to teach teammates to think through their ideas and the impact it will have on a software project But the thing that I do in that situation is I ask the person who's presenting the idea to take their idea and follow it through to its ultimate conclusion. So that means asking them to say, "OK, so..." Using the example from our last episode, of a microservices architecture, I say, "Well, we have problems A, B, and C, and D in the system. And I think that a microservices architecture is gonna solve it." And then, as a project lead, I can say to them, "OK, well so let's say that we move forward with that. What are the implications for the project? Does it mean that we're gonna have more service support? Does it mean that we are going to have to have a different team structure? Does it mean that we are going to have new work in our backlog that wasn't there already? What is that work?" And then ask them to think through their problem. In the case of microservices architecture, that might go something like, "Well, that means that we have to make sure that these units that we're turning into microservices are independently deployable, they're independently testable, that they have a well-defined interface, that that interface is versioned, that we have someone who is keeping track of what all of the requirements are from consumers of the interface." So you might need to have a product manager. The list of potential implication gets bigger and bigger, and then all of a sudden you need an entire team to manage this one component. And then, we can look at that and say, "If this does solve the things that you're saying it solves, it's the cost of potentially increasing our headcount by x. Justify that benefit. Or are there other ways we can get the same benefit?" Essentially asking the person to walk through all of the implications from the leadership perspective. When it makes sense to adopt a new idea in the middle of a software project Poornima: From their idea that they're putting out there. Jen Leech: Correct. Think about what that really means for the company as a whole. Then it facilitates them realizing assumptions that they have made or costs that they have envisaged, and when you get to the end of it, either you're on the same page and you say, "That was a great idea, we should totally do that." Or you're on the same page and you say, "We should not do this." And you've gotten there together. So that means that the person who's brought these ideas to the table both feels like their idea has really been heard, and if it was an idea that you should not move forward with, they've convinced themselves. Then you can both move forward with whatever you agree is the right course of action. How to instill confidence in teammates who are shy or reluctant to share their ideas Poornima: I think some people would be up to that challenge, they may even think through their idea, but you've got a lot of people who are, just say, eager beavers. They may be new to the team, maybe they don't know this whole process or policies and just kind of blurt out in a meeting, like, "I've got an idea." Is that an appropriate time to say, "That's fantastic you have an idea, here's how we operate. We do X, Y, and Z. So let's have you walk through the implications, etc.?" Jen Leech: That's a really good question. Sometimes a meeting is the right time to walk through that—depends on the meeting. Poornima: Sure. Jen Leech: A lot of times it's not. And in those cases then I'll usually say, "Oh, Kimmy, let's take that offline. Can we talk about that later?" And talk about it independently. However, through failure I have discovered that when bringing new people onto the team, they often need a little bit of intro. In this particular project that I was describing from last year, there were some new people that came into the team, stepped into these processes, started presenting new ideas, and then all of a sudden were blindsided when people started really probing into their ideas, and they weren't expecting it. So then I had to take a step back and then I realized that I haven't given them the appropriate context. And I sat them down and I said, "Hey, I realize I didn't explain this, but in this team you should expect that we're gonna really thoroughly look at new ideas that are brought to the table, and we're gonna investigate them." Poornima: I'd imagine it takes a lot of confidence even to just put an idea out there, so having it be shot down is going to impact people. Jen Leech: Yeah, absolutely. What I started doing is I started having onboarding conversations, essentially, with new people who came onto the team to explain that we investigate ideas that are brought to the table really thoroughly, and that we do that with everyone. And it's not any particular person, there's not good, there's no bad, we just wanna understand what this idea means. The particular person who I was talking to in this case hadn't yet seen somebody else go through the same process. Later on as we went through the process of exploring new ideas then it became more normalized. But I began having onboarding conversations with new people on the team to help them understand that we really investigate ideas really deeply, and that that's normal, and it's not to be taken personally. When do you stop entertaining new ideas, building a consensus, and get to work on your software project Poornima: So it's great that people are proposing ideas and that you're investigating them, but you remember from last time, we told our audience we would tackle this question. There's gotta be a point where you stop investigating, you've gotta stop consensus building or talking about the ideas, start making decisions and put a plan in place. So let's pick up that question. Jen Leech: It depends on the problem but there are a few different approaches that you can use. One approach that I enjoy using is that of framing whatever question that we're looking at in terms of a hypothesis. And saying, "Well, right now we think we're trying to solve problem X." And then when you really target the problem you're trying to solve, it's easier to hone in on the specifics of does this solve that problem. Then, either it does or doesn't, then you can move on to the next thing. When you're dealing with something more complex, let's say you're dealing with a system that is sufficiently complex such that you can't really say for sure what the result is gonna be, and furthermore, maybe you're trying to solve problems A, B, C, D, E, and F. Then there are a couple approaches I use in that circumstance. One is to say, "Let's build a quick and dirty prototype. Let's try it. Give it a limited amount of time, and see what happens." So you build out something very quickly. Ideally, you could do it in under a day, but it depends on what it is. And hopefully you've got your tools in place so you can do that. Maybe a week, but time box it. At the end of it you then bring it back to the table and say, "Does it look to us like it's gonna be solving these problems? And what did we learn from the process?" Poornima: So constraining the problem will hopefully constrain the conversation, and then creating a time box around when something is due will also create those constraints so that you stop that consensus building and get down to work. Jen Leech: Yeah. And finding every piece of work you do, in terms of here are the problems we think we're trying to solve, here are the solutions we think might work, and make everything an experiment, a discovery of new information. And the discovery, at the end of the day, might be does this work for our customers. As you frame it in terms of exploration and discovery, then it becomes natural to not have to have 100% solution. Because what you're doing is finding out. Poornima: It's fantastic that you're making this a discovery and that you wanna get out there and explore more, but there's always that time where we think we've done a lot and still something comes up. Maybe even a customer says, "You didn't think through this enough." Or somebody on your team brings it up. What do you do in those moments? Why it’s OK to constrain the problem space in your software project Jen Leech: Right. I think of this as the curve ball question. You think that you have the right hypothesis, you think you have a good solution, and then all of a sudden something comes up that you didn't expect and you find that maybe what you've put together does not satisfy a certain circumstance or certain constraints. In that circumstance, I think of it as having a new problem to solve. And when you have a new problem to solve the first question that I ask is, "How can I learn more about this problem? Who is on the team that knows about this? Who is in the organization that knows about this?" Maybe there's somebody in the finance department that can answer a question that we have. Who in the community can we talk to about this? It's interesting because I find that taking a problem and expanding it beyond the scope of the team is something that I don't see nearly as often as I would expect, considering the fact that you have, clearly, a limited amount of information within the team. Poornima: Limited brains. Jen Leech: Limited brains, limited experience. And so it would seem completely natural to open questions up to a larger audience. And yet, it's easy for people to stay in their own little group and not necessarily bring in outside opinions. This tactic is all about seeking new information. One example of this is when building this system that I was building last year. Some of the people who are gonna be using the system were data scientists. Some of them were experts on the data that we were processing. Whenever a new component or a new feature came to the table as something that we needed to come up with a new design for, the first thing we would do is have kind of like a brainstorming session, but really more like an information gathering session where we would bring in everyone from the company, who might potentially have a real interest in the result or be a potential user of the product, and say all of the problems that they've ever had in this area that they want solutions to. As an example, we were designing validations on data and we needed to understand a validation system existed before at this company. What did we like about that? What did we not like about it? And we had people who were not engineers, but who had to understand the correct use of the data, come to the room and tell us what their problems were. This is a lot like user research. And then that led to a collection of problems that we eventually may have realized existed, but hadn't really framed as the problem that we were trying to solve here. And it dramatically impacted the design that we came up with. Poornima: Let's do another example for our audience kind of playing that out. Jen Leech: Another really, really good example is that we were using a tool for building the system that wasn't an open-source tool that had been built by Airbnb. It turned out that we had some questions about the right usage pattern, the right deployment pattern, some questions about how they manage the flow of data between nodes. And, coincidentally, it turns out that Airbnb was in the next building over. Poornima: Oh, great. That's a great building by the way. Jen Leech: Yeah, lucky. We contacted the maintainer of the co-depository and asked him if he would be willing to come and talk with us. And he said sure. So he came over and had an hour long conversation about how Airbnb uses the tool and various critiques and pluses and minuses of using it one way or another. And at the end of the conversation we had a much better idea of what things we were doing with it were good and we should keep on doing, and which things we needed to change. And it was about an hour of time for a huge improvement. Poornima: I feel like this also helps you from causing more bugs because you know how to use the tool, or going through that drama of, "I don't know how this works." Jen Leech: It saves you an immense amount of time to just ask the right questions to people who know things. Poornima: That's fantastic. Thank you again for sharing these rules with us, Jen. Jen Leech: Absolutely.

Episode 42: Project Management: How To Respond To New Ideas In The Middle Of A Software Project

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.

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: <ul> <li>How to design a first-day experience for your new hire</li> <li>Why making setup a cinch is a good thing and doesn’t mean you are spoon-feeding your new hire</li> <li>What to expect in terms of results from your new hire at the end of the first day and the first week</li> <li>The benefits your team and company will experience when you invest in onboarding new hires</li> </ul> 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.

Episode 63: Why You Need To Invest In Onboarding A New Software Engineer And Not Expect Them To Ship Code On Their First Day

Episode 48: How a Product Design Sprint Fast Tracks Testing Your Ideas

Episode 49: How To Get Your Teammates To Adopt Product Design Sprints

Episode 58: How To Navigate Conversations About Diversity And Inclusion in Tech

Happy new year! I hope your 2019 is off to a great start :) If you’re curious what I’ve been up to and what I have in store for 2019, I’ll tell you right off the bat, I do not set goals or resolutions at the start of the year. Instead, I review my progress every quarter to see what I want to keep doing, what experiments I want to run, and what I am going to cut or put on the back burner! Taking a broad approach has served me well in running my business, balancing it with the ever-growing demands on my time as a new mom, and most importantly, managing overwhelm. So I won’t be sharing my goals for 2019 or if I’ve resolved to exercise more or less. And I certainly won’t be telling you to do more ;) But I get that there may be other people in your life who are going to be bombarding you with messages around setting resolutions and goals as it relates to your career and personal life. Don’t get me wrong, resolutions and goals serve as great guardrails, but there’s no need to artificially set them at the start of the year. So is it OK to not always be growing personally and in business? Well, if you’ve been tuning into Build for a while, you know I love to bust myths and misconceptions on it, as they relate to building products, companies, and your career in tech. To kick things off for the show’s fifth year, I thought we’d start with one of the biggest myths around building a company: you need to keep growing and scaling, otherwise you’re not innovating and you’ll soon start to stagnate. This is a BIG myth that permeates company culture in tech, but, as it turns out, you don’t always need to grow, and continual growth isn’t always desirable. In today’s Build episode, we’re going to be debunking this myth, and to help us out, I’ve invited Paul Jarvis, writer, entrepreneur, podcaster, designer and online course teacher. Paul is the author of the new book Company of One: Why Staying Small Is The Next  Big Thing For Business. As you tune into today’s episode you’ll learn the following from Paul:  How you went from being a designer to an entrepreneur How he started a service-based business and slowly transitioned to offering products Why he decided to not build a BIG business and the concerns he had around his decision 4 myths around building a big company Why it’s OK to stay small   In next week’s episode, Paul will share some best practices around building a company of one. -- Build is brought to you by Femgineer (http://femgineer.com/). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: https://femgineer.com/confident-communicator-course/ --  Enjoyed this episode and want to support the show? To become a patron of the show visit: https://www.patreon.com/build

Happy new year! I hope your 2019 is off to a great start :) If you’re curious what I’ve been up to and what I have in store for 2019, I’ll tell you right off the bat, I do not set goals or resolutions at the start of the year. Instead, I review my progress every quarter to see what I want to keep doing, what experiments I want to run, and what I am going to cut or put on the back burner! Taking a broad approach has served me well in running my business, balancing it with the ever-growing demands on my time as a new mom, and most importantly, managing overwhelm. So I won’t be sharing my goals for 2019 or if I’ve resolved to exercise more or less. And I certainly won’t be telling you to do more ;) But I get that there may be other people in your life who are going to be bombarding you with messages around setting resolutions and goals as it relates to your career and personal life. Don’t get me wrong, resolutions and goals serve as great guardrails, but there’s no need to artificially set them at the start of the year. So is it OK to not always be growing personally and in business? Well, if you’ve been tuning into Build for a while, you know I love to bust myths and misconceptions on it, as they relate to building products, companies, and your career in tech. To kick things off for the show’s fifth year, I thought we’d start with one of the biggest myths around building a company: you need to keep growing and scaling, otherwise you’re not innovating and you’ll soon start to stagnate. This is a BIG myth that permeates company culture in tech, but, as it turns out, you don’t always need to grow, and continual growth isn’t always desirable. In today’s Build episode, we’re going to be debunking this myth, and to help us out, I’ve invited <a href="https://pjrvs.com/" rel="nofollow" target="_blank">Paul Jarvis</a>, writer, entrepreneur, podcaster, designer and online course teacher. Paul is the author of the new book <a href="https://ofone.co/" rel="nofollow" target="_blank">Company of One: Why Staying Small Is The Next  Big Thing For Business</a>. As you tune into today’s episode you’ll learn the following from Paul: <ul> <li>How you went from being a designer to an entrepreneur</li> <li>How he started a service-based business and slowly transitioned to offering products</li> <li>Why he decided to not build a BIG business and the concerns he had around his decision</li> <li>4 myths around building a big company</li> <li>Why it’s OK to stay small </li> </ul> In next week’s episode, Paul will share some best practices around building a company of one. -- Build is brought to you by Femgineer (<a href="http://femgineer.com/" rel="nofollow" target="_blank">http://femgineer.com/</a>). --  Femgineer's Confident Communicator Course 2019 is coming up! To learn more visit: <a href="https://femgineer.com/confident-communicator-course/" rel="nofollow" target="_blank">https://femgineer.com/confident-communicator-course/</a> --  Enjoyed this episode and want to support the show? To become a patron of the show visit: <a href="https://www.patreon.com/build" rel="nofollow" target="_blank">https://www.patreon.com/build</a>

Episode 82: Why You Don't Always Have To Be Growing And Scaling Your Company

Remote

I don’t know about you, but I cringe at the thought of having to commute. The traffic, road rage, not to mention having to find parking… it was enough to make me throw in the towel 7 years ago!   Since then I have been managing remote teams around the world, and as I continue to scale my team I learn best practices  from companies who have been doing it for longer than I have like Olark.   But, I know there are a lot of people out there who just don’t know if they can do it.   Maybe you’re one of them. You worry if you’ll be productive, able to communicate effectively and fit into the company culture.   One of my employees, Meghan Burgain felt the same way about a year ago. She had a number of reservations having never worked remotely before.   In today’s Build episode, Meghan and I are going to dive into some of these reservations, how you can get over them, and of course the wonderful benefits aside from working in your jammies ;)   You’ll learn:    The tools and processes to use to stay productive and on top of your projects and tasks How to handle working across multiple time zones How to communicate more effectively with your teammates across a number of channels How to train new hires when you can’t sit right next to them How you can cultivate a great company culture across continents     Here’s another great source to check out on managing your day-to-day when remote working, from our friends at Skillcrush.   Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.   Transcript for Remote Working: How To Succeed In Your First Remote Working Position    Poornima Vijayashanker:        Hey, guys. I'm hanging out here in beautiful Bordeaux, France, and taking you behind the scenes this week to show you what remote working is like at Femgineer. If you've been on the fence about taking a remote position, stay tuned for a number of tips in today's *Build* episode.  Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. For the past seven years, I have been managing remote teams around the world for my startup as well as other companies. Today, I'm joined by Meghan Burgain, who is the mother of twins and expat who lives here in Bordeaux, France, and is Femgineer's community manager. For the last year, Meghan has been working remotely and she's going to share some of her favorite tips to help you get over any reservations that you might have when it comes to taking on a remote position. Thanks for joining us, Meghan.   Meghan Burgain: Thanks for being in France, Poornima.   Remote Working Reservations   Poornima Vijayashanker:        I know a year ago when I approached you about remote working, you were on the fence. Let's talk about what some of your reservations were.   Meghan Burgain:     Yeah. My education and a lot of my experiences are in education. I was actually a teacher before I moved here. I was a little concerned about getting up to speed, getting trained at Femgineer. That was one of my concerns was getting trained.  The other one of course was that Bordeaux is nine hours ahead of San Francisco. I knew that there was going to be some difficulty there. Would I have to stay awake at night to get all of the work done or not? Those are my two concerns.   How To Handle Time Zones When Remote Working   Poornima Vijayashanker:        While you got over the hurdle and joined the team, I know there was that first hiccup that you had where you missed a meeting due to the time zone. What did you learn from that experience?   Meghan Burgain:     Time zones are really tricky. I learned that basically communication is paramount, especially when you're working remotely. You need to be explicit, very clear, search for the clarification, ask the questions that you need and really just be polite when you're dealing with people through email. With chat, it can be difficult to maybe misread something so just to be polite and that avoids 90% of the issues.   Poornima Vijayashanker:        Then you eventually got over that and learned a number of things over the last year. Let's start with the first thing that you learned.   Recommended Tools And Processes To Stay Productive As A Remote Worker   Meghan Burgain:     Right. The first thing I learned basically was the importance of the tools that we use. Being that we're not in proximity, we use the tools like Trello and Slack. Trello is great because obviously for communication you can see who's doing what, if it's done or not, but also allows for transparency. You can see the bigger picture: what we're focusing on at Femgineer, what the priorities are, and how that should affect how I prioritize my own tasks as well.   Poornima Vijayashanker:        Now, I know another thing you've learned that is even though we're a remote team we still do weekly check-ins where we sync up. Walk us through how weekly check-ins have benefited you.   Meghan Burgain:     Weekly check-ins are really important. In startup plans, especially, products change, priorities change, and the weekly check-ins really help me, us both I feel, to stay focused and to stay in the same page working towards the same goal.   Training New Remote Hires   Poornima Vijayashanker:        Now, I know the third thing is that you were concerned about training, getting trained, training other people. I know as we've scaled the team, you had to train others. How have you gotten over that hurdle?   Meghan Burgain:     It's funny that that was one of my reservations and that's actually something that I've been doing at Femgineer. Well, I've realized that training someone via Zoom or Slack, it's not that much different than training someone in person and, in some cases, can actually be better because we can record the training and use it in the future which is what we've done a lot. I've also been relying a lot on our handbook.   Poornima Vijayashanker:        What's our handbook?   Meghan Burgain:     Our handbook is basically a recipe book for anything that's recurring at Femgineer so whether it's daily or just a certain time of the year, if it happens more than once, it's in the handbook. It's outlined. There's helpful tips and there are links to any outside resources that we might need.   Remote Working Benefits   Poornima Vijayashanker:        Great. Walk us through what a typical day is like for you.   Meghan Burgain:     A typical day I wake up. We get the girls ready. Send them off to daycare. Then I have the majority my day to do the daily tasks that I need to get done, answer emails that came through to do all of my tasks. Towards the end of the day, when the States wakes up, I'm able to schedule phone calls, have meetings and that sort of thing. It's where I base the first part of my day, I didn't have any of those interruptions. I was able to just do whatever I wanted at my own pace. At the end of the day, I have all the things that I need to interact with people. Then I do my to-do list for the next day and it's off to get the kids.   Poornima Vijayashanker:        Nice. It sounds like you have a lot of flexible hours.   Meghan Burgain:     Oh, yeah. Well, for sure. I have deadlines just like anyone else, but I do have a lot more flexibility with how I get those things done.   Poornima Vijayashanker:        What do you think are the key benefits that you've experienced by remote working?   Meghan Burgain:     You mean besides being able to work anywhere in the world and in my own kitchen and in my own sweatpants?   Poornima Vijayashanker:        Yes. Those are great benefits, by the way.   Meghan Burgain:     I would say that the biggest benefit of working remotely is that I've really been able to find a work-life balance that works well for me. I'm able to not only be there for my kids and my family but to provide for them as well. I think that that's just an invaluable thing. It's a win-win.   Remote Company Culture   Poornima Vijayashanker:        I know for some folks out there they might be on the fence about remote working because of the culture. They might feel like, oh, it's isolated or distant. How have you managed to manage that?   Meghan Burgain:     I could see how it could be lonely. You don't have someone just next to you to talk to or whatever but I haven't felt that way and I think to go back to the weekly check-ins, that that's really one of the reasons is that we do get that face time. Also we have Slack which we can talk to all of our team members. I would say when it comes to the culture and the team feeling, you get what you give. It can be tempting in any working relationships, especially in remote working, whenever you find someone that's available within your timezone to just ping them with the 20 questions that you have or to ask a hundred things of them. But, I would suggest to all of you that the first thing that you do to someone should really be to ask them how they're doing, to find out what their interests are. It goes a long way towards creating the spirit and creating a team.   Poornima Vijayashanker:        Building a rapport maybe through a water cooler channel on Slack.   Meghan Burgain:     Yes. Yes. That's what we have.   Poornima Vijayashanker:        Wonderful. Well, thank you, Meghan. This has been really helpful. I know our audience out there is going to benefit from these tips.   Meghan Burgain:     It's been my pleasure.   Poornima Vijayashanker:        Wonderful. Well, that's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where you'll get more helpful tips like this.   Meghan Burgain:     Ciao for now.   Poornima Vijayashanker:        Ciao for now.  This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.  Hey, guys. I'm hanging out here in beautiful Bordeaux and I'll just start again. All right.  In today's Build episode, we're going to talk to you about ...   Meghan Burgain:     Remote working.   Poornima Vijayashanker:        Yeah, I know. I forgot what I should introduce you before I ... I think I do need to. OK. Take two.

I don’t know about you, but I cringe at the thought of having to commute. The traffic, road rage, not to mention having to find parking… it was enough to make me throw in the towel 7 years ago! Since then I have been managing remote teams around the world, and as I continue to scale my team I learn best practices <a href="https://www.youtube.com/watch?v=c4iR-FEq5Xk&amp;list=PLNZFyTfZybcxFXrxiMGtEuPfYTv_B12-5&amp;index=30" rel="nofollow" target="_blank"> from companies who have been doing it for longer than I have like Olark</a>. But, I know there are a lot of people out there who just don’t know if they can do it. Maybe you’re one of them. You worry if you’ll be productive, able to communicate effectively and fit into the company culture. One of my employees, Meghan Burgain felt the same way about a year ago. She had a number of reservations having never worked remotely before. In today’s Build episode, Meghan and I are going to dive into some of these reservations, how you can get over them, and of course the wonderful benefits aside from working in your jammies ;) You’ll learn: <ul> <li>The tools and processes to use to stay productive and on top of your projects and tasks</li> <li>How to handle working across multiple time zones</li> <li>How to communicate more effectively with your teammates across a number of channels</li> <li>How to train new hires when you can’t sit right next to them</li> <li>How you can cultivate a great company culture across continents</li> </ul> <a href="https://skillcrush.com/2016/10/10/working-remotely-tips/" rel="nofollow" target="_blank"> Here’s another great source to check out on managing your day-to-day when remote working, from our friends at Skillcrush.</a> Build is produced as a partnership between <a href="http://femgineer.com/" rel="nofollow" target="_blank">Femgineer</a> and <a href="http://pivotaltracker.com/" rel="nofollow" target="_blank">Pivotal Tracker</a>. San Francisco video production by <a href="http://www.startmotionmedia.com/" rel="nofollow" target="_blank">StartMotionMEDIA</a>. Transcript for Remote Working: How To Succeed In Your First Remote Working Position  Poornima Vijayashanker:        Hey, guys. I'm hanging out here in beautiful Bordeaux, France, and taking you behind the scenes this week to show you what remote working is like at Femgineer. If you've been on the fence about taking a remote position, stay tuned for a number of tips in today's *Build* episode. Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. For the past seven years, I have been managing remote teams around the world for my startup as well as other companies. Today, I'm joined by Meghan Burgain, who is the mother of twins and expat who lives here in Bordeaux, France, and is Femgineer's community manager. For the last year, Meghan has been working remotely and she's going to share some of her favorite tips to help you get over any reservations that you might have when it comes to taking on a remote position. Thanks for joining us, Meghan. Meghan Burgain: Thanks for being in France, Poornima. Remote Working Reservations Poornima Vijayashanker:        I know a year ago when I approached you about remote working, you were on the fence. Let's talk about what some of your reservations were. Meghan Burgain:     Yeah. My education and a lot of my experiences are in education. I was actually a teacher before I moved here. I was a little concerned about getting up to speed, getting trained at Femgineer. That was one of my concerns was getting trained. The other one of course was that Bordeaux is nine hours ahead of San Francisco. I knew that there was going to be some difficulty there. Would I have to stay awake at night to get all of the work done or not? Those are my two concerns. How To Handle Time Zones When Remote Working Poornima Vijayashanker:        While you got over the hurdle and joined the team, I know there was that first hiccup that you had where you missed a meeting due to the time zone. What did you learn from that experience? Meghan Burgain:     Time zones are really tricky. I learned that basically communication is paramount, especially when you're working remotely. You need to be explicit, very clear, search for the clarification, ask the questions that you need and really just be polite when you're dealing with people through email. With chat, it can be difficult to maybe misread something so just to be polite and that avoids 90% of the issues. Poornima Vijayashanker:        Then you eventually got over that and learned a number of things over the last year. Let's start with the first thing that you learned. Recommended Tools And Processes To Stay Productive As A Remote Worker Meghan Burgain:     Right. The first thing I learned basically was the importance of the tools that we use. Being that we're not in proximity, we use the tools like Trello and Slack. Trello is great because obviously for communication you can see who's doing what, if it's done or not, but also allows for transparency. You can see the bigger picture: what we're focusing on at Femgineer, what the priorities are, and how that should affect how I prioritize my own tasks as well. Poornima Vijayashanker:        Now, I know another thing you've learned that is even though we're a remote team we still do weekly check-ins where we sync up. Walk us through how weekly check-ins have benefited you. Meghan Burgain:     Weekly check-ins are really important. In startup plans, especially, products change, priorities change, and the weekly check-ins really help me, us both I feel, to stay focused and to stay in the same page working towards the same goal. Training New Remote Hires Poornima Vijayashanker:        Now, I know the third thing is that you were concerned about training, getting trained, training other people. I know as we've scaled the team, you had to train others. How have you gotten over that hurdle? Meghan Burgain:     It's funny that that was one of my reservations and that's actually something that I've been doing at Femgineer. Well, I've realized that training someone via Zoom or Slack, it's not that much different than training someone in person and, in some cases, can actually be better because we can record the training and use it in the future which is what we've done a lot. I've also been relying a lot on our handbook. Poornima Vijayashanker:        What's our handbook? Meghan Burgain:     Our handbook is basically a recipe book for anything that's recurring at Femgineer so whether it's daily or just a certain time of the year, if it happens more than once, it's in the handbook. It's outlined. There's helpful tips and there are links to any outside resources that we might need. Remote Working Benefits Poornima Vijayashanker:        Great. Walk us through what a typical day is like for you. Meghan Burgain:     A typical day I wake up. We get the girls ready. Send them off to daycare. Then I have the majority my day to do the daily tasks that I need to get done, answer emails that came through to do all of my tasks. Towards the end of the day, when the States wakes up, I'm able to schedule phone calls, have meetings and that sort of thing. It's where I base the first part of my day, I didn't have any of those interruptions. I was able to just do whatever I wanted at my own pace. At the end of the day, I have all the things that I need to interact with people. Then I do my to-do list for the next day and it's off to get the kids. Poornima Vijayashanker:        Nice. It sounds like you have a lot of flexible hours. Meghan Burgain:     Oh, yeah. Well, for sure. I have deadlines just like anyone else, but I do have a lot more flexibility with how I get those things done. Poornima Vijayashanker:        What do you think are the key benefits that you've experienced by remote working? Meghan Burgain:     You mean besides being able to work anywhere in the world and in my own kitchen and in my own sweatpants? Poornima Vijayashanker:        Yes. Those are great benefits, by the way. Meghan Burgain:     I would say that the biggest benefit of working remotely is that I've really been able to find a work-life balance that works well for me. I'm able to not only be there for my kids and my family but to provide for them as well. I think that that's just an invaluable thing. It's a win-win. Remote Company Culture Poornima Vijayashanker:        I know for some folks out there they might be on the fence about remote working because of the culture. They might feel like, oh, it's isolated or distant. How have you managed to manage that? Meghan Burgain:     I could see how it could be lonely. You don't have someone just next to you to talk to or whatever but I haven't felt that way and I think to go back to the weekly check-ins, that that's really one of the reasons is that we do get that face time. Also we have Slack which we can talk to all of our team members. I would say when it comes to the culture and the team feeling, you get what you give. It can be tempting in any working relationships, especially in remote working, whenever you find someone that's available within your timezone to just ping them with the 20 questions that you have or to ask a hundred things of them. But, I would suggest to all of you that the first thing that you do to someone should really be to ask them how they're doing, to find out what their interests are. It goes a long way towards creating the spirit and creating a team. Poornima Vijayashanker:        Building a rapport maybe through a water cooler channel on Slack. Meghan Burgain:     Yes. Yes. That's what we have. Poornima Vijayashanker:        Wonderful. Well, thank you, Meghan. This has been really helpful. I know our audience out there is going to benefit from these tips. Meghan Burgain:     It's been my pleasure. Poornima Vijayashanker:        Wonderful. Well, that's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where you'll get more helpful tips like this. Meghan Burgain:     Ciao for now. Poornima Vijayashanker:        Ciao for now. This episode of *Build* is brought to you by our sponsor, <a href="https://www.pivotaltracker.com/" rel="nofollow" target="_blank">Pivotal Tracker</a>. Hey, guys. I'm hanging out here in beautiful Bordeaux and I'll just start again. All right. In today's Build episode, we're going to talk to you about ... Meghan Burgain:     Remote working. Poornima Vijayashanker:        Yeah, I know. I forgot what I should introduce you before I ... I think I do need to. OK. Take two.

Episode 50: How To Succeed In Your First Remote Working Position

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.

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 <a href="http://traffic.libsyn.com/femgineertv/Episode_40_-_Holly_Cardew_-_Segment_1-Patreon.mp4" rel="nofollow" target="_blank"> how to recruit remote workers</a> for people who may be new to it. Then we discussed <a href="http://traffic.libsyn.com/femgineertv/Episode_40_-_Holly_Cardew_-_Segment_2-Patreon.mp3" rel="nofollow" target="_blank"> how to train, hold accountable, and retain remote workers</a>. 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: <ul> <li>How to manage a remote team that is working on a mission critical project</li> <li>How customers and clients benefit from a team of remote workers</li> <li>Why facetime is still important for remote teams—especially when kicking off a project</li> <li>How to facilitate facetime amongst remote workers</li> <li>A simple first step for people who are on the fence about hiring remote workers</li> </ul> -- Build is produced as a partnership between <a href="http://femgineer.com/" rel="nofollow" target="_blank">Femgineer</a> and <a href="http://pivotaltracker.com/" rel="nofollow" target="_blank">Pivotal Tracker</a>. San Francisco video production by <a href="http://www.startmotionmedia.com/" rel="nofollow" target="_blank">StartMotionMEDIA</a>. -- ## 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.

Episode 68: What A Remote Team Needs To Be Successful When Working On A Mission Critical Project

Episode 43: Project Management: How To Keep Your Team Motivated And Successfully Ship

Episode 51: How You Will Be Impacted In 2018 Whether You Are A Startup Founder or Employee

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:   Extreme Programming Explained  How can I practice pair programming? Mob Programming  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.

In last week’s Build Tip, <a href="http://traffic.libsyn.com/femgineertv/BUILD_Podcast_EP39_-_Chris_Jobst_-_Segment_1_mixdown-REV2.mp3" rel="nofollow" target="_blank"> we dove into the importance of onboarding new hires</a>, 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: <ul> <li>Why pair programming may seem daunting but it’s very efficient</li> <li>How pair programming improves the quality of your code base and product</li> <li>What mob programming is</li> <li>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</li> </ul> Build is produced as a partnership between <a href="http://femgineer.com/" rel="nofollow" target="_blank">Femgineer</a> and <a href="http://pivotaltracker.com/" rel="nofollow" target="_blank">Pivotal Tracker</a>. San Francisco video production by <a href="http://www.startmotionmedia.com/" rel="nofollow" target="_blank">StartMotionMEDIA</a>. Check out these additional resources on programming methodologies: <ul> <li><a href="https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658" rel="nofollow" target="_blank"> Extreme Programming Explained</a></li> <li><a href="https://www.codenewbie.org/blogs/how-can-i-practice-pair-programming" rel="nofollow" target="_blank"> How can I practice pair programming?</a></li> <li><a href="http://mobprogramming.org/" rel="nofollow" target="_blank">Mob Programming</a></li> </ul> 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.

Episode 64: How Pair And Mob Programming Help Quickly Onboard New Software Engineers

The best podcast episodes on parenting. Interviewing experts and talking through common issues surrounding parenting. This topic is filled with important lessons and insights for anyone listening. Add episodes you're interested into your queue below!

OwlTail

Best Parenting Podcasts

The best episodes for anyone looking to learn more about topics such as happiness, fulfillment, depression and psychology/mental health in general. With interviews with industry experts, personal stories of individuals, this topic has lessons applicable to everyone. Add episodes you're interested into your queue below!