Engineering Team Management: A Proactive Approach to Retain Developers
In our series, we do interviews with tech leaders on engineering team management, covering a broad set of topics from hiring, retaining developers, measuring performance, sharing knowledge and forming a great team culture.
Our intention is to provide detailed, actionable case studies on how other tech leaders manage teams so the rest of us can learn from them.
Here is what we cover in this post:
Hiring developers for exotic technologies
Using effective ways to find developer candidates
Forming a great team culture
Measuring performance and motivating teams
Divvy is a financial technology company allowing companies to issue credit cards with allocated budgets for employees, departments and teams, giving them only as much access to money to spend as you want them to.
Hiring software developers for exotic technologies
Hiring is a big challenge in any kind of sector where software developers are needed. From the latest State of Software Development report it turns out that hiring is among the biggest challenges, 20.7% of the tech leaders mentioned it as their biggest one.
It’s not different at Divvy. Here is what Greg said:
“It's definitely a challenge here to hire software engineers of any kind in Utah because there's more jobs by far than people who work in them. You often hear stats there are 9 open positions for every software engineer, so it's incredibly competitive and things like salaries are going up year over year like crazy. It can be really hard to find talent and then retain them too.”
The other thing that makes hiring even harder for Divvy is that they work with exotic technologies. The vast majority of their production back-end services are all written in Elixir.
“We found Elixir to be an incredibly productive and powerful technology that we love using, but it's still a very new technology and the community around it is very small and people with professional experience with Elixir is very small.”
Before Divvy, Greg led a development team in a different company that was using Scala, which is a similarly unique language as Elixir. There he learned how to hire engineers that can work with new technologies who and be productive really quickly.
Here is what Gregory did:
“We've developed a way to source engineers and then interview them and vet them in a way that helps us understand not necessarily how good they are with Elixir, because a lot of times, most of the people we hire don't have any experience with Elixir.
We had people come in who had never heard of Elixir, but now a few months after being on the job, they're attending conferences, they're featured on blogs and running their own blogs about Elixir.
So when it comes to hiring developers to work with an exotic technology, the most important hiring criteria should be willingness and ability to learn and passion for the new technology.”
How to find developer candidates
The best way to find great developers is through referrals.
“I like hiring through referrals because you already have someone who has experience with the engineer, so you have a good source of whether the person will be a good fit for the team.”
The best thing is that every time you hire an engineer, you typically get access to his network as well, and you potentially get more referrals in the future.
How to make sure referrals work
“To get good referrals, your engineers can't be skeptical of where they work. They're very protective of their friends, and so if they don't think that Divvy is going to be a great place to work, they're not going to refer their friends here.”
You have to make sure you have good team culture, and provide a good environment where people love being and feel like they would not only refer their friends, but also want to have their friends here.
How to build and maintain good team culture
“Even with referrals to ensure that we keep our bar quality high we require every candidate to go through the same interview process.
Even if there's someone we've worked with before, like for example, I've got a few people here I've worked with at two other places before Divvy, but rather than giving in the pass all the way through just to start on a team, they still had to go through the same interview process to ensure they’re good fit.”
How to retain developers
Greg is doing a great job retaining developers. So we asked him to share exactly what they have done so we can learn from their example.
1. Clear career path
“We were very quick to develop a clear leveling system and a clear career path. We have a transparent plan for every candidate about how their career could progress and how we make sure we keep their compensation competitive.
We regularly go through and evaluate everyone's pay against where we feel it should be to be competitive in the market. Last time we did it there were developers that earned below the competitive pay, so we just corrected their pay to what it should be, which means people got sometimes a pretty significant bump in their salary.
And it wasn't necessarily a promotion. It was just:
“Hey, you know, the market is competitive and things keep getting more expensive and people keep getting more expensive with wages going up. So we value you and we want to just keep you at a good place and without asking or telling, we just said your pay’s up, just make sure that you're comfortable.”
2. Transparency and openness to feedback
We try to be very transparent about the good and bad things and we also try to implement feedback as quickly as possible.
Our CEO is well known for hearing about a problem and getting to work right away to fix it.
I think when engineers come forward and say, “You know, I can be more productive if,” or, “I'm having an issue with this thing,” or, “I don't like, you know, whatever it is,”
We're very quick to move on something and take action to implement feedback.
3. Give developers ownership of something
The last thing that helps retain engineers is to give them real ownership of something. That's something we strive to do where we give every engineer ownership of something significant.
We give them the autonomy and empower them to actually do what they want to do with that area.
Here is an example.
We have a few engineers who are owning a new product where they make all the decisions about what technology they want to use, how they want to organize their group, and how they want to do their agile development process.
So they're more likely to stick around because they feel like they can affect their own careers and their own work here.
Key takeaways on retaining developers:
Make sure the potential career path is clear for every developer, showing them where they can get if they put in the work.
Be proactive with compensating and promoting developers before it’s too late
Be transparent with the good and bad things in the company
Be open to feedback and act on it as soon as possible
Give your developers ownership of something significant where they can make technological decisions
How to share knowledge within the team
Divvy’s developers are organized into groups and guilds.
Engineers are grouped together into development groups with product managers, QA and DevOps and they all work very closely together as a cross-functional group to deliver on products and features for certain experiences or parts of the product.
The guilds are very specific to certain areas of technology or disciplines. For example, Divvy has guilds such as mobile engineers, web engineers, back-end engineers, and at the same time they're members of their cross-functional teams.
“You could be in a guild with someone who’s working on a completely different part of the product that you'll never really work with side by side on a feature, but because the guilds get together and meet regularly, they can share knowledge about the different things they're doing” - said Greg.
How to measure developer performance
We certainly try to measure what we want and what matters.
For us, that's the impact or the outcome rather than trying to measure things like how much a developer is committing, lines of code written, story points, or something like that. We try to measure the outcome of what they've done.
We're still trying to get better at getting some kind of numbers around that to make it more obvious, but we try to look at what the predicted outcome should be, and then we compare that with what happened.
For example, if a group of software developers is working on a feature that's supposed to make a certain experience better that means maybe our NPS for that user should increase or we should see more adoption of that feature.
So we’ll make that hypothesis and then track that, and if they were able to accomplish that, then it’s a job well done.
I've always been a big believer that you have to take an individual approach with everyone.
And so everyone's different, everyone's going to work differently, so you set up sort of a framework, but then you take a very individual approach with every person within that framework.
Our framework contains objectives and key results (from the OKR framework) that engineers should just be doing:
What's your personal objective?
What do you think will make you successful?
That's a discussion between the developer and the manager; they set up the objectives and goals together and figure out a way to make it happen.”
Other requirements Greg mentioned:
“Every engineer should be releasing code at least weekly.“
“We deploy multiple times a day, and so there's plenty of opportunity for software developers to be deploying it at least weekly. It’s an expectation and goal for engineers to deliver code weekly, so when they don’t we start a conversation to find out why and how we can improve.“
Bonus advice from Greg:
1. Importance of how you hire.
That's where it all begins. You can do yourself a ton of favors by hiring the right people upfront, and you can also cause a lot of pain by not hiring well upfront.
I think there's often a lot of pressure to hire quickly and often people don't feel like they have the time to really vet candidates the best or they don't know if their process works, but it's hard to overstate the importance of hiring and how that can set you up. It's just easier to manage people you know are going to work well with you.
2. Don’t manage work; manage the workers
What I mean by that is that management should be more about leadership, motivation, inspiration and aligning people on vision and strategy rather than counting metrics and looking at graphs and following process, and implementing process around work to improve efficiency.
I think there is a lot of good best practices out there about how to organize teams, how to implement processes and things to manage the work happening in the teams.
So the real work should be focused on:
How am I working with the individuals?
How do I excite the individuals?
How do I make sure each engineer is bought into what we're trying to accomplish and they know what we're trying to accomplish?
How can they help accomplish it?
That's the most important thing a leader or manager can be doing is really passing that strategy and vision to each individual and then giving them the ownership and empowerment to do something about it.
An engineering team is a complex system. To keep it running and growing it requires a multi-front effort on hiring, retaining developers, figuring out ways to share knowledge and to measure developers’ performance.
I hope Greg’s insights through Divvy provided some valuable tips you can apply right away in your team to achieve similar great results.