SimpleLeadership Podcast Podcast Por Christian McCarrick arte de portada

SimpleLeadership Podcast

SimpleLeadership Podcast

De: Christian McCarrick
Escúchala gratis

SimpleLeadership specifically focuses on improving the craft of software engineering leadership. As a VP of Engineering & CTO I am acutely aware of the lack of good resources available for new and existing software engineering managers. SimpleLeadership is designed for both new and experienced software & technology managers who want to build high-performing teams, better motivate & mentor their employees, reduce attrition and advance their career. It is for people who want to go beyond just being a manager and become a true leader. In this interview based show I ask each guest to share their journey from individual contributor to software engineering manager and provide any guidance on the transition. The SimpleLeadership Podcast will present real and actionable stories from people who have navigated their way from being an individual contributor into a software engineering manager. We will also hear from experts on specifics of team dynamics, motivation, feedback, leadership and many more aspects of being a successful engineering manager.copyright 2017 SimpleLeadership Economía Exito Profesional Gestión Gestión y Liderazgo
Episodios
  • Diversity & Inclusion in Tech with Christine Awad

    Diversity & Inclusion in Tech with Christine Awad
    May 10 2021

    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.
    Más Menos
    41 m
  • Engineer Your Teams for Impact with Ashish Aggarwal

    Engineer Your Teams for Impact with Ashish Aggarwal
    Jan 11 2021
    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 ...
    Más Menos
    41 m
  • A Discussion of Good Technical Debt with Jon Thornton

    A Discussion of Good Technical Debt with Jon Thornton
    Dec 14 2020
    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 ...
    Más Menos
    26 m
Todavía no hay opiniones