Info

SimpleLeadership Podcast

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.
RSS Feed
SimpleLeadership Podcast
2021
May
January


2020
December
October
August
April
March
February
January


2019
September
July
June
May
April
March
February


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


2017
December
November
October
September
August
July
June
April
February
January


2016
December


Categories

All Episodes
Archives
Categories
Now displaying: March, 2020
Mar 23, 2020

If you’re in a leadership position in the engineering industry and have suddenly been thrust into working remotely, it may feel like your world has been turned upside down. In this episode of Simple Leadership, Dana Lawson and I discuss a few tips to help you manage remote teams. You want your team to thrive and be successful during a time of great uncertainty.

Dana describes herself as an atypical engineer. She wanted to attend college to be an artist but soon realized the ‘starving artist’ lifestyle wasn’t going to cut it. She took the ASVAB test when she joined the military and scored high in engineering categories. In the last 20 years, she’s worked in every tech position possible—most recently, she is the VP of Engineering at GitHub. Listen to hear her unique story!

Outline of This Episode

  • [1:38] Dana Lawson: from art major to engineer
  • [6:18] How Dana found herself in a leadership role
  • [9:02] Mistakes Dana has learned from throughout her career
  • [12:27] We got to eat dinner at Al Gore’s house
  • [15:48] Tips and strategies for managing remotely
  • [26:38] Don’t forget these aren’t just transactional relationships
  • [30:42] How to onboard a new hire completely remotely
  • [34:45] What happens when the process doesn’t go well?
  • [37:04] Help remote employees advocate for themselves

You have to embrace a leadership mindset

Dana states that “Anybody can be a leader, it’s just how much you wanna unlock it”. She believes it’s an attribute that’s been ingrained in her personality. She’s naturally an A-Type and has never been afraid to speak her mind. In whatever capacity she was working in, she always took the initiative to move the ball forward. 

You don’t have to have a management title to be a leader. 

She just believes that some of us gravitate towards being a leader more than others—but that we all have the calling to lead in some way. Dana argues, “Anybody has the ability to go influence change and bring up the people around them to do great things”. 

Tips and strategies to manage remote teams

Dana shared some tips she’s learned from a managerial role:

  • Write it down. Have a good practice of writing things down. Track what’s being done throughout the day. Reiterate tasks and instructions multiple times through different modes of communication whenever possible. 
  • Form a daily structure for your team and yourself. Don’t stop the practices you already have in place because you suddenly have this new obstacle of working from home. You can still hold the same meetings, just do them virtually. 
  • Take advantage of ALL the communication tools available to you. Slack and online chats are great, but if the conversation is going to be longer than 5 minutes, hop in a video chat (Zoom, Skype, FaceTime) or a phone call. 90% of communication is non-verbal and it’s okay to jump from chat to a call.
  • Invest in some camera gear: This is my tip here, but get a decent webcam off of Amazon and use appropriate lighting when using Zoom or other video applications. 

To keep things light-hearted—though partially serious—Dana points out that you have be on-point with your emoji game. There’s verbal communication, non-verbal, and emoji verbal. Humans have reverted to Egyptian Hieroglyphs. Oddly enough, each company has its own set of social norms with emojis—so learn quickly. 

These aren’t just transactional relationships

Don’t forget there are humans on the other side of your communication. How would you interact with someone in the office? What about pleasantries like “Hey, good morning!” or “How are you today?”. Dana points out you can ask about your team’s families, learn about their dog, and keep apprised of their life like you would in the office

A distributed workforce still needs to feel like they’re part of the office family. Dana points out that you want to build empathy even when you won't have the physical contact that you would in an office setting. Especially now, with many people working from home due to the Coronavirus, people are anxious. They’re worried about their jobs and their livelihood. 

As a manager, you’ll have to learn how to empathize with them and how to quell their fears. You’ll likely have to help them focus on the projects at-hand and iterate that you are in this together. Above all, Dana recommends being realistic about your deadlines. Transitioning into working remotely won’t be 100% smooth and you have to have grace through the process.

How to onboard a new hire 100% remotely

Dana believes the easiest way to onboard remotely is to be completely intentional with everything you do. Schedule every onboarding task and learning opportunity into their calendar Direct them to all of the tools and processes they’ll need. Email them with links to training documents, with a schedule of when to go through them. Dana points out this is a great time to record training videos. It helps break up written policies and gives new hires a face and voice to connect to. 

Communication is key during the onboarding process and needs to be even more emphasized with a remote workforce. You can’t just tell them, “Connect with me if you have questions” or “Tell me if you have a problem”. As the manager, it is your job to consistently check-in, ask how they’re doing, and walk them through issues they may run into. Worst comes to worst, you can always push the onboarding process until you have a better system in place.

Listen to the whole episode to hear Dana and I talk about helping remote employees advocate for themselves and hear in detail our discussion on leading remotely and doing so successfully. 

Resources & People Mentioned

Connect with Dana Lawson

Connect With Christian McCarrick and SimpleLeadership


Subscribe to SIMPLELEADERHIP on
Apple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio

Mar 9, 2020

A management role in software development can be difficult to navigate. You need to keep a high-level perspective on projects while making sure they go smoothly. Eric Elliott, today’s guest on the show, believes that you need to implement coding quality practices such as test-driven development. In this episode, we talk about why software development processes such test-driven development makes an impact and why it’s important to remove bugs. We’ll also talk about how to train developers and keep them happy—and why it’s inherently important not to rush the process.

Eric Elliott has been in software development for the better part of his life. He co-founded EricElliottJS.com and DevAnywhere.io, which aim to teach developers essential software development skills. He is also the author of the books, “Composing Software” and “Programming JavaScript Applications” He builds and advises development teams for crypto projects, and has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more. 

Outline of This Episode

  • [2:08] Eric’s background in software development
  • [4:28] What’s happened in the last year?
  • [6:17] Tangible benefits to reducing bugs on the front-end
  • [9:34] How much time should be spent on fixing bugs?
  • [11:43] What happens when you rush engineers?
  • [13:35] What happens when a manager steps in
  • [19:50] How to communicate with your leadership
  • [25:11] What tangible things should you measure?
  • [29:55] Top 3 things to do to improve quality of code
  • [34:30]Measure pull requests and open bug tickets
  • [40:49] Test-driven development (TDD)
  • [43:50] Resources Eric recommends 

What are the tangible benefits to reducing bugs?

If you are able to reduce bugs on the front end, you spend less time fighting fires. According to Eric, “Fixing bugs is not work that’s delivering direct value to your customers—it’s rework”. Customers don’t look at your software and think being “bug-free” is a benefit. They just assume that it’s a given that there will be no bugs. 

Secondly, Eric points out that you will lose customers if you produce buggy software. Struggling client retention and turnover means you’ll have to increase your marketing budget in order to attract new business. 

It is the most expensive and time consuming part of producing software. But it is imperative to deliver a stellar product on the front end. Because, per Eric, “Every hour spent in code review saves 33 hours of maintenance”. The hardest part is understanding that this process takes time and cannot be rushed, but it is well worth it in the end. 

What happens when you try to rush your engineers?

Those in leadership positions often have to deal with pressure from higher-ups to rush a project or push a timeline. This is the worst thing that could happen, and you’ll start to see significant negative results of rushing your developers. 

Eric points out that bugs will pile up, testing will get skipped, and communication will suffer. Your team will feel like they don’t have adequate time to mentor each other, and knowledge sharing is left behind. Productivity levels will plummet

Even worse, your developers can reach the point of burnout—with effects that can be long-lasting. The Japanese struggle with a culture of over-working to the point that they have a coined term for people who die because of overworking—”Karoshi”. While this is an extreme example, it’s something you want to steer clear of. Pushing your team to rush will bring to fruition the opposite of what you intend. 

What is your role as a manager/leader?

Eric uses a manufacturing analogy to drive this point home:

“ There's a floor manager who is usually perched up high above a factory floor so they can see everything happening on the factory floor. They can see where things are piling up. So on an assembly line work comes in one end of a line and goes out the other end of the line, but then all these different processes thrown in the middle that take different amounts of time to complete. Optimizing that process is the job of the floor manager”. 

The moment a manager steps in and gets themselves involved in the work they lose perspective of the overall process. No one is doing quality control. The assembly line will start to have pile-ups with no one able to step in and smooth the process. 

It’s a manager’s role to ensure the process is slow and smooth, but efficient. The key is proper communication—If you show your superiors that progress is being made on a regular basis, it eases their anxiety. If every part of your code includes code review and test-driven development (TDD) it is just another part of delivering software responsibly. 

Improve the quality of your code with good software development practices

Eric recommends using a non-predictive burndown chart (a graphical representation of work left to do versus time). A predictive chart can set unrealistic expectations for a project, which is a developer’s #1 complaint. 

He also believes you need to track developer happiness and improve it when needed. Know what makes them happy or satisfied with their work. Developers deal with time pressure, unrealistic expectations, and problems they don’t know how to tackle on a daily basis. They need to be empowered and given permission to spend time on mentoring, learning, and quality control. 

Happy developers perform their jobs up to 20% faster. 

Secondly, you must implement test-driven development. In Eric’s experience, TDD is crucial to delivering a great product. Universally, the teams that test first work better. Eric researched studies on the topic and found that testing reduces bug density by 40-80%. You will always see the test fail before it passes, which allows you to debug and find improvements. It leads to continuous delivery, which keeps everyone happy. 

What you should and shouldn’t measure

Everyone has heard the phrase “What gets measured gets managed”, but it isn’t always in your best interest to measure everything. Eric shares his take on what NOT to measure as well as what you should track.

Eric points out that you shouldn’t measure individual developers' number of closed tickets. Why? The developers closing the least amount of tickets are the ones with all the answers that everyone else comes to. They’re spreading their knowledge which will multiply the productivity of the organization. 

You DO need to measure bug commit density instead of bugs per line of code. If you have a file with 51 commits and 14 are bug fixes, that’s a 20% bug commit density. You also need to look at recency of the rework. Doing these things allow you to see what is causing bugs now and allows you to fix what needs fixing.

DO measure how many open pull requests there are. Your team needs to be able to have the time to do code review. It needs to be prioritized. It allows your teams to learn from each other and get everyone on the same page. 

DO measure the number of open bug tickets. Bugs reproduce, and critical bugs will interrupt developers. When they're interrupted, it takes twice as long to complete the tasks they were working on—and they end up with more bugs. This comes full circle, back to the software development practice of test-driven development. This mitigates the number of bugs that will creep up and changes the cycle. 

Eric delivers a lot of solid advice for developers and managers in this episode. Listen to the whole episode for all the important details. 

Resources & People Mentioned

Connect with Eric Elliott

Connect With Christian McCarrick and SimpleLeadership

Subscribe to SIMPLELEADERHIP on
Apple Podcasts, Google Podcasts, Spotify, Player FM, TuneIn, iHeart Radio

1