SimpleLeadership Podcast

Diversity & Inclusion in Tech with Christine Awad

What are the challenges that accompany being a woman leader in technology? How can you be an ally for women in your workplace? How do you overcome imposter syndrome? These are just a few of the questions Christine Awad—the Director of Engineering at Facebook—so kindly answers in this episode of Simple Leadership.

Engineer Your Teams for Impact with Ashish Aggarwal

How do you build an engineering team of A-players? What does a well-rounded high-performing team look like? Why is engineering for impact more important than solving hard problems? In a world where engineers are looking to pad their resume and solve cutting-edge problems, Ashish Aggarwal shares the one thing that is far more important: solving your customer’s problems. In this episode of Simple Leadership, he walks through building high-performing teams, solving customer problems, and the best way to maintain technical excellence. Do not miss this one.  Ashish Aggarwal is the Co-Founder and CTO of enterprise SaaS management platform, Productiv. Prior to founding Productiv, Ashish was the VP of Engineering at Postmates, where he built and led a team of over 130 engineers to develop all technology for the food delivery marketplace. Before Postmates, Ashish led product and engineering teams at Amazon, where he helped build and launch Amazon’s own Freight Transportation Network in North America, Europe, India, and China. Ashish has also held senior leadership roles at eBay, where he built the e-commerce platform’s checkout experience, and at Microsoft, where he built the enterprise conferencing solution, Skype for Business. Ashish holds a Bachelors in Computer Science from the Indian Institute of Technology, Delhi.  Outline of This Episode [1:14] Ashish’s background in the space [3:46] The transition into a management role [6:15] What Ashish has learned from years of management [12:11] What does a well-rounded high-performing team look like? [16:49] High-performance teams don’t happen overnight [20:55] Solve high-impact problems—not hard problems [24:50] Solve short-term problems versus taking shortcuts [29:18] How to maintain deep technical excellence over time [33:43] How to find success with a smaller company [37:29] Amazon's leadership principles [40:02] How to connect with Ashish Aggarwal What Ashish has learned from years in management Ashish notes that he made the typical mistake of not letting go. He struggled to trust that his team could take control. He admits that he needed to let go of the notion that he was the smartest person in the room. Once he realized that he needed to let things go, he stopped reviewing every document from the last line of the design to every line of code. What led to his change of heart? One of his coaches told him, “You know, your team can run much, much faster than this and we understand you're new, but let go. We understand it's hard, but try it. See what your team does when you just let them be. Give them the problem and let them come with the solution. They might just surprise you.” Ashish notes that it was eye-opening. He can now say, "Hey, I will let my team solve this problem—even though I have good ideas about it—I can give input, but let me give up control." What does a well-rounded high-performing team look like? Ashish states that the obvious thing that you must look for is competence and skill. You can't have a high performing team without core capabilities. But beyond that, you need a team that is passionate. You want to build a team of self-motivated players who see a problem that needs to be solved and will solve it.  Ashish emphasizes that taking ownership is a culmination of all of this. He wants engineers that are constantly asking, “What is the next big problem I can solve?” Ashish doesn’t assign problems to his team members. Instead, he points them in a certain direction and they identify the problem. They identify the solution. They know what success looks like, and they are diving in to get that done. When an entire team is the problem identifier and the problem solver, you naturally start thinking more long-term. High performing teams take ownership of solving the customer’s problem and do.  Ashish has seen teams where the culture of collaboration is not there. Competition is there. Cutthroat culture is there. So the question must be asked—is the management defining the vision? Are they letting their team members solve the problem? Find what is broken by talking to the team.  Solve high-impact problems—not hard problems Ashish emphasizes that high-performing teams don't work on the hardest problems. High-performing teams work on the most impactful problems. High-performing teams take ownership of the customer's problem. The solution may be pretty low tech. Maybe the solution doesn't add to their resume. That doesn’t matter if the impact on the customer is there.  High-performing doesn't mean that their performance was stellar or they worked on cutting-edge technology. High performance means that their customers say, "Oh man, my problems are solved in record time.” Impact is not always dollars. It's not always revenue. It depends on the problem. It depends on the customer. You should define what is going to help your customer and that's what your teams should focus on. How to maintain deep technical excellence over time Take ownership. If your team doesn’t know the answer to a problem or have someone to solve it, allow them to do the research. Find out what it takes. But it’s also not up to you to make sure your people are tech-savvy and up to take with the latest technology. Ashish firmly believes that it is everybody's problem. “Increasing their own technical capability to solve bigger and better problems is as much their problem as it's mine...I cannot mandate passion. I cannot mandate learning. Learning—the passion for learning—and solving problems comes from inside the team. I just need to hire the right people and I need to have the environment around them.”  Ashish is full of amazing insight into building A-teams in the engineering space. Listen to the whole episode to take advantage of his years of expertise in the field.  Resources & People Mentioned Amazon’s leadership principles Connect with Ashish Aggarwal Productiv Cto(at)productiv.com  Connect on LinkedIn Follow on Twitter Connect With Christian McCarrick and SimpleLeadership http://simpleleadership.io/ Christian on LinkedIn Christian on Twitter: @CMcCarrick Subscribe to SIMPLELEADERHIP onApple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio

A Discussion of Good Technical Debt with Jon Thornton

Jon Thornton worked at some small companies in NYC before he ended up at Squarespace. He’s been able to build a new product and new team—their email marketing product. He launched that and has since been supporting other products. Throughout his career, he’s learned how to manage technical debt. What is the difference between technical debt and good technical debt? What is a framework for using technical debt? Listen to this episode of Simple Leadership for Jon’s advice on managing technical debt.  Jon has been solving problems with software for over 20 years and leading engineering teams for 10. Along the way, he's parked millions of cars, improved textbooks with AI, reduced the price of prescription medication, and sent billions of emails. Currently, he's an engineering director at Squarespace in New York City. Though Jon's day job is mostly meetings and documents, he still gets his coding kicks in by maintaining a mildly popular jQuery plugin in his free time.  Outline of This Episode [1:26] Jon’s history in programming [4:43] Mistakes Jon made early on [6:22] What would he have done differently? [7:32] Teamwork isn’t about individual output [8:25] Financial debt and technical debt [10:53] Why time is currency [14:32] Good technical debt is intentional [17:14] A framework for using technical debt [21:24] Why building trust with your team is important [22:37] Jon’s book + podcast recommendations  [24:54] How to connect with Jon  How technical debt compares to financial debt The common definition of technical debt is that it’s code that you don’t like and you’ll need to fix or change later. But Jon applies a more narrow definition: It’s work that he expects to have to do in the future. It’s not necessarily code that he doesn’t like.  Jon points out that financial debt is a commonly accepted occurrence. Someone that takes out a mortgage to buy a house and is congratulated. It’s a “responsible” use of debt. You can use technical debt to get value now and then you can pay it down over time. It’s a tool. It allows you to reorder when they value and the payment happens—you just have to use it responsibly.  People want to have perfect code from the moment of conception, but it isn’t always worthwhile from an ROI standpoint. If it doesn’t make more money or provide more value, it can be shelved for later.  How to manage technical debt When you think about starting a new engineering project, it starts with estimates: “How much is this project going to cost us?” It typically refers to man-hours or engineering week. The cost of the project is how long the team will spend building it. If you’re following the financial debt analogy, you are taking out a tech debt mortgage. You’re borrowing time that will be paid back later. You’re doing it in a way that creates more value now. The main reason engineers exist is to provide value—to shareholders, your company, and the users of your product. If a manager takes over a team from another company, they’re immediately taking on technical debt or risk that has accumulated. How do you walk through that? How do you evaluate that? According to Jon, you can talk to people or read commit history to understand how you ended up with the system you have. The next step is to assess the kind of technical debt you’re dealing with. What technical debt is actively accruing interest? Are you spending time on it with bug fixes? Is it growing larger?  There may be an API with design issues. If you keep building on top of it, it will be harder to evolve later. Other kinds of debt may be a scaling issue where performance is okay now, but your database can’t support it later. You have more time to put that technical debt aside and address it later. Assess and establish urgency. Good technical debt is intentional During his initial Squarespace project, Jon used an access control list where only certain people had access to certain features. The right way to build it is to have a database table and management UI that makes it easy to add people. But the list didn’t change frequently. It would be easier to have a hard-coded list of IDs in their code-base. To give someone access, they’d make a new commit and deploy it. It was fine for the first two years of the project. They’d instead spend their time on things that immediately impacted the project they were working on. They could go in and make the list more dynamic down the road. Jon recommends that you do the riskiest parts of your project first. Reordering the way you build things enables you to tackle risk first. With any project, there's usually going to be some problems that you have to solve that are going to make or break the success of that project. You want to figure out those things as soon as possible so you have time to deal with any consequences. Managing a list wasn’t going to make or break their project. But the email editor they were building was going to make or break it, so they spent time on that first.  A framework for using technical debt Jon’s techniques for managing technical debt (scaffolding, hard-coding, edge cases, etc.) are all based around the idea of accepting that it’s okay to build something twice. That can help you reorder the way in which you build things. Scaffolding is inspired by physical buildings. Sometimes while you’re building one structure, you need to build a temporary structure (scaffolding) to support what you’re building. You’ll eventually take it down and replace it with something more permanent.  They knew they needed the capability to send billions of emails, but they didn’t need that capability to test the email editor that they were building. They needed to build the editor before building the sending capabilities. There was less innovation to solve there. So they built something unscalable that allowed them to test the editor first. They knew they would build the delivery pipeline twice. It had value. How do you show that technical debt is deliberate? How do you get stakeholders on board with the technical debt? Why is trust so important? Listen to the whole episode for the whole story on technical debt.  Resources & People Mentioned BOOK: Nonviolent Communication BOOK: Borrow Your Way to Wealth BLOG: https://noidea.dog/ BLOG: https://blog.danielna.com/ Connect with Jon Thornton Jon’s Website Connect on LinkedIn Connect With Christian McCarrick and SimpleLeadership http://simpleleadership.io/ Christian on LinkedIn Christian on Twitter: @CMcCarrick Subscribe to SIMPLELEADERHIP onApple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio

Redefining Parental Leave with Matt Newkirk

Being in a management position in any industry can often leave you overwhelmed. Striking a balance between your work and personal life is already difficult. So how does a manager take parental leave? Matt Newkirk—the engineering lead for Etsy’s International Customer Experience initiative—has worked out some of the kinks.  I’m the father of three girls. During their birth, I was fully involved in startups and was never able to take parental leave. Not only did I miss out, but as a manager I feel I can’t help my team plan a successful leave because I never experienced it. So in this episode of Simple Leadership, Matt shares how to plan and prepare for parental leave. Anyone in leadership can benefit from his experiences. Outline of This Episode [1:14] Matt’s background in coding + role at Etsy [3:48] Why two-way communication is important [6:33] Matt’s advice for a new manager [8:20] Taking parental leave as a manager [12:57] Parental leave can empower your employees [15:15] How to prepare for parental leave [18:07] How do you tell your boss you’re taking leave [19:19] You need to have a reintegration plan [25:29] How does a manager support employee leave? [31:46] Supporting employees who are parents in a pandemic [34:57] How to navigate “work from home” in leadership [38:06] Parental leave needs to be normalized [41:30] How to connect with Matt Newkirk How can a manager take parental leave? Matt has two children, a 4-year-old son and a 2-year-old girl. He started at Etsy when his son was 7 weeks old. He was fortunate to receive some parental leave, but there was an odd tension. He was just forming relationships with his team and it felt strange to disappear. So he took that leave very sporadically, almost as if he was taking vacations here and there. Most of the decisions were made before or after that. Very little true delegation had to happen. But when his daughter was born, he wanted to take his full leave. He’s very fortunate that Etsy provides 6 months of parental leave. It was a great opportunity to reconnect with his family and disengage from work. When anyone in leadership takes time off, its news. But it is possible. You want to role model that it’s okay to take parental leave. It shouldn’t just be a benefit on paper that no one uses. How can taking parental leave empower your employees? Listen to hear Matt’s take.  You HAVE to plan your leave When possible, you have to build out a plan for your parental leave. Matt was managing many different teams with different scenarios. He notes that sometimes it’s as easy as delegating one person to carry out a task. But it needs to be clear to stakeholders and delegates who is taking on what responsibility.  It took him 2–3 months to iron out the details for his leave. He recommends to try and have this done at least one month before you take leave—in case your baby comes early. When should you start planning? Around the time you’re comfortable telling your boss. These plans don’t expire. So if you wrap up a project earlier than you thought, it’s great.  Before you leave, Matt says “I think your job before that happens is to make sure that your reports trust you enough, that they don't have to wonder what's going to happen.” You don’t have to think about missing out on opportunities or ask: “Am I going to lose my job? Am I going to get reassigned? Am I going to get the side-eye for the next six months?” Your job is to make sure that none of those things happen. You need to have a reintegration plan A reintegration plan is just as important as planning your leave. In Matt’s case, he knew he was coming back to a reorganization and a new boss. He wasn’t sure how the units would fit together. So the first thing he did was contact his new boss and let him know when he was coming back. Then he thought about how he’d spend his time. He took some strategies from the book “The First 90 Days” and planned to spend the first 30 days figuring stuff out, listening to his team, and understanding perceived problems. Then he spent the next 30 days building hypotheses, testing them with new data, etc. In the last 30 days, you begin to act on that research. He emphasizes that it all comes down to communicating effectively. Matt also talks about how the transition back isn’t always smooth and shares how he adjusted to his role in a very changed company.  How a manager should support their team’s parental leave Matt notes when someone tells you they’re going out on leave, your one job is to make them feel at ease. Let them know you’re there to support them. Then figure out when they’re going to share that information. Set up time to figure out delegation plans. Once they’re out, find out what information they want from you while they’re out. You can front-load some expectations. Other than expected communications, leave them alone. Let them enjoy their leave.  Matt also emphasizes that you should be flexible about their return schedule. Do not push back projects for them to handle when they get back from leave. Have a transitional return schedule that starts on a Thursday or Friday and a part-time first week back.  Do not make any assumptions. They come back as different people. Some have difficult transitions, others are easy. Don’t make assumptive comments like “I hope you had a great time” or “I bet you’re exhausted.” Above all, don’t reduce their opportunities.  How else can you support your employees through a leave? How do you support your team’s work from home in a pandemic? Where can leadership receive support? Matt shares his thoughts on these questions and more—so listen to the whole episode.  Resources & People Mentioned BOOK: The 5 Dysfunctions of a Team BOOK: The First 90 Days Molly Graham's Give Away Your Legos Tara Feener's part-time return suggestion Michael Harriot Alice Goldfuss Anne Hjortshøj Pie Bob (Rachel Perkins) Lara Hogan BICEPS Presentation: Revitalizing a Cross-Functional Product Org Connect with Matt Newkirk Follow on Twitter Connect on LinkedIn Connect With Christian McCarrick and SimpleLeadership http://simpleleadership.io/ Christian on LinkedIn Christian on Twitter: @CMcCarrick Subscribe to SIMPLELEADERHIP onApple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio

Hiring Engineers: Junior, Senior, or Boot Camp Graduates? Johnny Ray Austin Shares His Take

If you’re an engineer in a leadership role where you’re dealt with the task of developing teams, the hiring process can be daunting. Do you hire junior engineers that you can shape and mold? Or senior engineers who are experienced, but come with baggage? And how do you throw boot camp graduates into the mix? Johnny Ray Austin joins me to lend his thoughts on the hiring process, including what he looks for in an engineer. Don’t miss it! Johnny is an experienced engineering executive and international public speaker. Johnny claims he got into leadership by sheer luck—but he ended up taking the leadership position and never looked back. He’s now the VP of engineering and CTO at Till, a company that helps people pay, stay, and thrive in their homes.  Outline of This Episode [2:23] Johnny Ray Austin’s background in engineering [4:33] The biggest mistake Johnny’s made—and the lesson learned [7:35] Transitioning into leadership: Johnny’s top tips [9:58] Handling remote work amidst a pandemic [14:00] “The Death of the Full Stack Developer” [18:54] How do engineering leaders keep up with new technology? [24:50] Hire for strengths, not lack of weaknesses [20:57] Develop a hiring process based on your company [27:24] Junior engineer vs. senior engineer: which is better? [31:38] Advice for managers for coaching junior engineers at home [34:18] Why you don’t want to rush through the junior engineer phase [38:15] Bootcamp graduates: to hire or not to hire?  [41:10] Embracing the concept of radical candor “The Death of the Full Stack Developer” Johnny’s talk, “The Death of the Full Stack Developer”, was a culmination of what he's seen developing in the industry. He’s seen an evolution of people switching engineering midway through other careers. The people who are switching have a more difficult time because of the expectations that are placed on engineers to know it all.  Catching up to everything that’s happened struck Johnny as silly. He can’t keep up with all of the new stuff out there. It also depends on our definition of “the stack” (It’s typically short-hand for front-end and back-end experience). 80% of people land on their website from a mobile device—but no one talks about mobile devices when they talk about the stack.  The full stack encompasses a lot more than what we mean when we use the phrase. When you look at it that way, it’s unreasonable to expect someone to be an expert in the entire stack. The true full stack developer is dead and gone. Johnny is quick to point out that that doesn’t mean you can’t be good in multiple areas. But you have to recognize that there are specialties. While you do want as much bang for your buck as possible when hiring, you can't burn people out. You have to set expectations accordingly. How do engineering leaders stay on top of new technology? Keep listening to hear our discussion.  Hire engineers for their strengths—not lack of weaknesses Johnny points out that—as an industry—we assume that one hiring process is going to work for every company out there. But it’s up to you to find a process that works for you and your team. You have to take into account questions like: Can they grow into what I might need in a year? Or 18 months? Does your company align with their future goals? The paradox is that you need to stop hiring for the now—and hire for tomorrow—while still solving today’s problems.  John screens a potential team member’s ability and willingness to grow with the company from the first phone call. He talks about their ambitions as a business and asks if the potential engineer can see themselves growing with that vision. Are they interested in leadership? Are they willing to mentor other engineers? What is their mindset regarding operational excellence? He’s honest about his expectations moving forward.  Hiring engineers is a risky endeavor. Bringing on the wrong person can damage the team. Johnny emphasizes that you should hire engineers based on their strengths. Then, you can hire other engineers to fill in the gaps. They can learn from each other while complementing each other.  Where are they really strong? What are their interests? Some people are good at cranking things out. Some people are great at communications. You want your engineers to work on the things that allow them to thrive. You need to build teams that are diverse because together you have something greater. Junior engineer, senior engineer, or boot camp grad: which is better?  Johnny points out that if you hire a senior engineer, you reap the benefit of their experience and track record. So there’s less training involved—but they often come with baggage. They’ve done things a certain way their entire career and tend to be resistant to learning new methods. With a junior engineer, you don’t get the experience—but you don’t get the scar tissue either. You have a blank slate. They can grow in a way that fits your company.  When Johnny is considering a junior engineer, he looks for two things: intellectual curiosity and the types of questions they ask. It’s a good indicator of someone willing to level up and gain experience. He’s found that intellectual curiosity is positively correlated with great performance.  To further complicate the hiring options, boot camp graduates can be thrown into the mix. Johnny is an advocate for hiring out of boot camps. Some of the sharpest engineers he knows had no formal education of any kind.  Someone with a CS degree knows a lot of theory but they have no clue how to be a day-to-day software engineer. Bootcamp developers have the day-to-day software engineer requirement without the foundation in theory. They often also have industry experience in other fields that they can bring to the table. Either way, there will be gaps to fill. As a manager, you have to decide which gaps you want to fill and train. To hear the full discussion about hiring, transitioning into a leadership position, and much more—listen to this episode of the Simple Leadership podcast! Resources & People Mentioned Till Miro BOOK: An Elegant Puzzle by Will Larson BOOK: Radical Candor by Kim Scott The Death of the Full Stack Developer Connect with Johnny Ray Austin Connect on LinkedIn Follow on Twitter Recursive Funk Connect With Christian McCarrick and SimpleLeadership http://simpleleadership.io/ Christian on LinkedIn Christian on Twitter: @CMcCarrick Subscribe to SIMPLELEADERHIP onApple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio