GitPrime elevates engineering leadership with objective data. In this interview series, Engineering Leaders talk about how to build high performing teams.
Your primary target as a leader is to advance your organization’s goals. Obviously. But you’re also working with a team of human beings who have their own needs within the company and outside of it.
Your engineers have lives, too.
So how do you approach meeting your company’s goals while also caring about the needs of the individuals you lead?
In his experience, from leading teams at NodeSource and Adobe, you can start answering that pressing question by flipping it: You can meet your goals by caring more about the people you lead.
In other words, caring for the people you work with can actually rally them around your organization’s purpose. But it’s not as simple as showing up one day with your caring hat on. Stewart has a process for building an environment where caring can actually become a manager’s primary focus.
We turned to Stewart to get a clearer sense of how to pull this off.
Prep yourself as a leader
The first step to rallying your team is to rally yourself. That is to say, make the effort to really understand the organization you’re a part of, whether you’re a seasoned veteran, or it’s your first day on the job at a brand-new startup.
“If you don’t understand the end-to-end process of building a product, then you’re going to have a terrible time trying to manage the process,” Stewart says.
“That is something we try to teach developers. Learn the entire process—from inception all the way to delivery.”
Understanding the organization you’re working with sounds like a no-brainer. But how often do people – how often do you – gloss over understanding something because it’s technically someone else’s job?
“Someone on your team has to be responsible for the overall outcome,” Stewart suggests. “For example, you’ve got to work with the services team in order to put together a one-pager on the product functionality. You have to work with the QA team to make sure that you have test bandwidth. You have to work with marketing. You have to know about the entire process.”
And that somebody might as well be you.
“That is something we try to teach developers, too,” Stewart says. “There’s more to this than you contributing to the codebase. Being a developer is a lot more than just writing code. Learn the entire process—from inception all the way to delivery.” It’s not just a way for engineers to see the bigger picture and understand their part in it, but it also gives them a clearer picture around what kind of challenges they want to take on, whether they want to transition to management, and so on.
Rally the team
You can use that advantage of understanding the end-to-end process—and encouraging your engineers to do the same—to rally your team both as engineers and as people. Because if engineers are involved in your organization’s entire process, they’ll take greater ownership in its goals.
“Most importantly, engineers want to be heard,” Stewart says. So if you want to boost your team’s engagement, the most valuable things you can do are invite their input by making time and space for it, and then actually listening to it.
Heptio, for example, embraces what they call ‘radical transparency,’ so the engineers have plenty of opportunities to share their ideas or concerns. Whether or not your organization goes that far, weekly stand-ups, retrospectives, one-on-ones, etc. are all great opportunities to receive input from your team, and show them how and why their input is valuable.
“It always comes down to communication,” Stewart says. “Most importantly, engineers want to be heard.”
But in any case, encourage that culture of open communication if you really want your engineers to rally around your business goals.
“We value diversity in thinking,” Stewart says. “Engineers come from different walks of life, bringing vastly different experiences, so they may see things that we don’t see, or otherwise have ideas that we want to factor in.”
Anything you can do as a leader to facilitate an environment that capitalizes on these opportunities will set you up for more innovative and effective collaboration.
“It always comes down to communication,” Stewart says. And that goes both ways – ensure that you’re holding dialogues, and not just monologues. In addition to listening to your team, explain what your business goals are, what’s on target for you, and what’s more incidental to the greater mission. Because aligning your team with your organization’s goals is paramount to your success.
Pushback and disagreement
Now, there will be instances when engineers feel really passionately about pursuing an idea that you’re not going to do, or are opposed to a decision that you’ve already made.
This is a critical aspect of rallying the team: it doesn’t mean you will always go along with them. How you handle those moments of disagreement goes a long way toward maintaining the culture you’re creating.
“When that idea was first brought to me, I hated it,” he admits. “I was like, ‘Disagree and commit? No, I disagree, period.’ And then I learned the whole point of ‘disagree and commit’ and why it’s important.”
At the end of the day, a decision has to be made, and it’s the manager’s job to move the process forward—whether or not everyone agrees. It’s not about bullheadedly following your decision. Rather, your team can pursue that direction wholeheartedly and change direction as needed.
That means if your team disagrees with an idea, you can encourage them to push especially hard to make it work well. Then you’ll all discover whether or not it was a genuinely bad idea, without interference from poor implementation.
A helpful approach here is one of experimentation. Stewart suggests testing all of your decisions as you would hypotheses. If you document and review your assumptions, you’ll always learn from your decisions.
“Every time I start a new project, I can see what I didn’t do well the previous time that I want to try and tackle the next time around,” he says. “It’s better for us to make a decision, move in a direction, and get data that either supports the decision or contradicts it. If it contradicts, then there are no sacred cows. We change direction, and as long as you back up that course correction, and are consistent, engineers can respect that.”
The team that doesn’t need you
By creating a culture that empowers your team, you’re building an adept team that can function creatively and independently. You’re ultimately building a team that doesn’t need you. And that’s the right idea.
“You hired a bunch of incredibly smart people,” Stewart says. “You don’t want to get into a mode where you’re just telling them what to do.”
But that doesn’t mean that your rallied team will put you out of a job. Instead, you can finally focus on your real job as an engineering manager: caring about the needs of the people you lead.
“Know what exactly is going on with every single person. That’s what makes us able to adapt at a drop of a dime to deliver the stuff you need to deliver.”
“I want managers paying attention to the signals from the team,” Stewart says. “You need to know when somebody’s having a good day or a bad day. Notice when their productivity is dropping off. Have conversations with them.”
Of course, your purpose within the company is to meet the business’s goals. The way to that outcome, though, is by being there for your team members as human beings who happen to be engineers.
“You should be able to tell me almost everything about an individual on your team because you’re spending that much time understanding them as a person,” Stewart says. “I’ve told my managers that that’s what they pay me for: to know what exactly is going on (within reason) with every single person. That’s what makes us able to adapt at a drop of a dime to deliver the stuff you need to deliver.”
Once the team is rolling along and the team members are on board with the mission, management is all about this human side of the equation. And effective managers, as Stewart describes them, still keep everything running at this point – but from behind the curtain.
“I don’t need the applause,” he says. “I take pride in my team shipping. If they’re the front people, going on stage with confidence, writing the blog post, doing the video, I want that. Being a developer these days is a lot more than just writing the code. So the more I can fade into the background, the better off they are.”