Shane defines “soft skills” as the capabilities you rely on when working with people, not machines. In software engineering — and also in life — much of what we do involves human interaction. Having competency in soft skills helps engineers and engineering leaders achieve things in a way that’s smoother or better, says Shane.
A challenge, however, is that professors don’t teach soft skills in engineering school. As a result, engineers need to learn to develop and harness soft skills on the job: things like communications skills, emotional intelligence, listening and empathy. David echoed a similar thought when he said that kids are taught physical hygiene, but not emotional hygiene.
According to David, “When we get angry, all of our blood tends to flow into our lizard brain and our emotional brain loses it.” In his many years leading engineering teams, Shane says that very few projects fail because of technology. Instead, many projects fail because people communicate poorly — in other words, they fail in the proper use of their soft skills.
Shane shared an example of a recent 1:1 meeting to discuss a technical problem. At first, Shane failed to pick up on some physical cues. As a result, the conversation became a bit stressful. Once Shane noticed the cues, he realized that the problem they were discussing wasn’t the true problem, it was something else entirely. When Shane steered the conversation to cover the real issue, things worked out much better.
Due to the pandemic, engineers have worked in remote teams for well over a year. As Shane wrote in a post on our blog, leading a large engineering team during the pandemic has been a challenge.
Shane says that leading remote teams is a lot more work than leading in-person teams. Why? Because you need to pay extra attention to signs and signals online. When you’re in-person, a leader can look at a team member’s body language and understand what kind of day they’re having. In online meetings, this is far more challenging.
In a remote setting, you might have a team member who always has their camera on. In the last few meetings, however, the camera has been off and the audio muted. Might be time to check in and see how they’re doing.
Things can also happen that leaders are unaware of. For example, two people had an argument during a meeting. The argument upset them so much that negative feelings lingered. Weeks later, the same two people couldn’t get on the same page to ship a project deliverable. Without talking to each person, engineering leaders may never get to the bottom of things, since they were not a witness to that prior argument.
Shane says it’s also important to keep tabs on what’s going on in people’s lives. Are they going through any health issues? Is everything OK in their household? The passing of a family member or a family pet can be difficult and cause team members to act differently in meetings. Shane encourages leaders to ask team members how everything is outside of work.
How can leaders tell when they’re focused too much on the delivery of projects and not enough on the well-being of their teams? Shane says to look back at the end of a week and count how many meetings you cancelled or postponed. In particular, pay attention to 1:1 check-in meetings that you re-frame to ask about project status.
If you spend too much time focused on technical problems, there may be larger issues at play, says Shane. You might need to de-scope some deliverables in order to meet a date or push the date out in order to meet the deliverables.
For 1:1 meetings, Shane’s rule is that he can’t cancel a 1:1 unless he asks for permission. Team members, on the other hand, can cancel a 1:1 with Shane if they have project deliverables to attend to.
Shane leads a team of 120 engineers but doesn’t directly manage a lot of people. There are 14 dev teams and 7 engineering managers. Each of the engineering managers report to Shane and lead their own sets of teams. Shane meets with his direct reports weekly and the broader team engages in 10-minute daily standups.
Shane meets with individual contributors every two weeks and has ad hoc meetings with people as needed. “The larger your team, the more you need to know a little about everyone. Show them you’re aware of the work they’re doing and give them kudos on things they did well.” David said that in a past job, the fact that a senior leader knew his name — and knew what he was working on — was a thrill, as well as a significant morale booster.
Shane practices servant leadership, a philosophy in which leaders exist to serve their teams. It’s unlike traditional leadership, in which the leader is more focused on the success of their teams, but less focused on being a servant to those teams.
According to Shane, “My job is to make sure that every engineer is unblocked and has the tools and training she needs to make her day complete and move forward.” Shane tells members of his team, “I’m here to make sure you can do the best job you can. The price I charge for doing that is I get to bask in the glory of your success.”