Engineering productivity is key to building good software. It comes down to the manager to make sure the developer team is performing as expected.
Improving engineering productivity in your team will definitely help to ease this challenge. In this interview, you will learn some hands-on tips from Camille Fournier.
Camille is currently the managing director at Two Sigma. She has years of experience with every level of engineering management, running teams of all sizes, and she's the author of the widely successful book, The Manager's Path.
It’s about how effectively your engineering team can get important and valuable work done. How productive are they? Do they regularly produce the results that you expect them to? Do results come slower than you’d expect?
That’s the high-level thinking around engineering productivity.
Different people have more or less rigor around this.
My approach is all about goal setting and achievement. Our engineering teams set ambitious goals, whether it’s about building new features, stabilizing systems or cleaning up bugs. We expect ourselves to hit at least a reasonable percentage of them. It’s no problem if we miss, but it should be for a good reason, like learning new information while developing the project.
Others are more rigorous about the number of features they measure, such as story points, tickets, or other measurements they track over time. It only works if you make sure people don't start grinding those measurements or inflating estimates to make themselves look more productive.
This is why I prefer to focus on what we think of as goals and achievements relative to that, versus worrying about details like story points and tickets.
Another helpful way to think about engineering productivity is, how often can your team make changes in production. If they make changes frequently, they tend to be more productive. That's a good approximation.
Many engineering managers struggle with setting goals. They think about goal setting in a way that’s inspiring to their team without making it easy or pushing too hard.
Some managers say the way to build a productive team is to hire smart people and get out of their way. I have never seen that work. It might work in theory if you have clear goals and if you motivate people to achieve them.
Most managers aren’t good at setting clear goals. When you're always adjusting your goals, you can’t expect to just hire smart people, get out of their way, and watch them be productive.
Most engineers don't learn how to be productive on a team without having experienced it. If you've never been an engineer on a hyper-productive team, you won’t know what it’s like or what you could do to make a productive team happen.
Engineering managers need to put policies and practices in place depending on the team and the goals to make them productive. You need to be careful not to implement too many, or they'll drag down team productivity. Engineering managers always need to work on being as clear as possible about goals, so the team feels motivated to get things done.
They tend to forget how the processes and expectations around the way the work is done on their teams have an impact on engineering productivity. Many engineering managers don’t consider that if you have tons of meetings that everyone is expected to tend, it will take up too much time and drag the team's productivity down.
New hires need context about what's going on around them, no matter how smart they are. There's everything to learn when you join an established team with established technology. You need to figure out how the systems work and who all the people are, and you need to understand the problems the team is solving.
One of the best ways to bring new hires up to speed is pair programming
Just about every company has some non-standard tools in their chain they need to use for their software development process. An experienced developer can show the ropes to a new hire, and it could take as little time as a few days or a couple of weeks. It’s a great process to help new people quickly learn a lot of information and context about your team.
You need to be clear about the goals of the team and the work that needs to be done, so it’s easier for new hires to figure out what to do. Most of the time it's not obvious for new hires what to do, unless they are with a veteran senior. If you don't have a clear idea about what they should be doing, it’ll be hard for them to figure it out, and they’ll likely not end up working on the most important tasks.
Pair programming partially does that. It's not the manager pairing with the new hire but with another engineer on the team, and it creates a buddy system as well. You might pair with a more senior person, and they could mentor you. Mentoring happens in different ways, and it really depends on your team and your company.
People have different ideas when it comes to mentoring. A mentor has an advisory role and can be helpful to clue someone in on company, team or project stuff. Mentors can also help someone navigate their tech career or learn different skills.
For people new to the industry, giving them mentors earlier is a lot easier, because you have many people who would be qualified to mentor them. It's also more important because when you're starting out in tech, there's a lot to learn about being an engineer. You don’t learn that in college, even if you do internships.
Mentoring isn’t a prerequisite for new hires. You don't have to set every new developer up with a long-term mentor.
But it's a good idea to set up a new hire with a buddy, especially at a bigger company. Depending on the seniority of the new hire, you may want to wait until you get to know the person and their goals before you try to find them a mentor.
With experienced engineers, it's better to wait and figure out the right mentor for that person. They don’t need it from day one, but a buddy on the team is great to have.
Keeping people motivated and engaged is a challenge. When I became an engineering manager, I was obsessed with developer motivation, like almost all fresh managers. I have learned that you have to be clear about the goals.
People need to understand they’re working for a reason, and they have goals. The more developers understand the goals and the reasons, the more engaged they’ll be with the problems they're working on.
I'm in senior management now, and most of my time is spent thinking about the future and where we're going. I make sure to explain that to motivate the team, so they appreciate the fact that the things they’re working on are in line with the goals.
There are always a million things to work on. I have a team of about 150 people, and we own dozens of products within the company. My job is to help the team be the most effective and productive, so I need to make sure my engineers know what the most important problems to solve are. These choices also need to align with the high-level goals of the team.
To give you an example, let's say you have a big data center footprint, and you want to move to the cloud. That could be a goal. Or you want to rebuild the architecture of the company and move from a monolithic library-driven architecture to a services architecture. This is the type of goals teams like mine face.
All these goals can’t be the most important. I need to be able to explain to my team, “Look, we want to progress on many things. Right now, the most important thing is moving to a services architecture. We care about the operational stability, but we're not going to stop all work on features and products to stabilize everything.”
My job is helping the team through my reporting chain and helping with communications among the groups. We do goal setting as an organization, by helping the team understand what is important. I think that helps a lot in keeping people productive.
Engineers won’t be productive if they don't know what to work on. You have to make choices. There are too many different things that could be done, that you need to focus on, or you end up with teams going in all directions, slowing down progress.
So, I think engagement and engineering productivity is mostly about making it clear what people should be working on.
New managers often try to make their team like them, and be nice all the time. You should be kind to your team; everyone hates mean and abusive managers screaming at them. But often a team loves their manager, but they aren’t as productive and engaged as you’d expect them to be. They don't blame the manager, but in my experience, the manager is the one at fault.
When an engineering manager says yes to everything and avoids giving negative feedback to his developers, the team feels loved by their manager. But when things go wrong on the team, the manager can’t correct things. As a manager, you need to call the shots and explain to your team the reasons why they need to do something, instead of whatever they may find more interesting.
You can make people productive and engaged by challenging them, by having hard conversations or by asking them to do things that make them uncomfortable. You don’t do this in an abusive way but by giving them tasks that require a stretch from them.
People get scared to tackle problems they're not sure how to handle. It’s the manager’s job to push them and make them understand that the task is a priority, how it will benefit the team, and that they’ll improve along the way.
So, you can't say yes all the time, and you have to push your engineers a bit. You are responsible to improve the way the team works. Sometimes, you're going to have to ask your engineers to do things they’re not excited about for the long-term health of the team.
The more frequently your team can make changes to the code, the more engaged and productive they're going to be. I’ve never seen this fail. Pushing on an increased release cadence makes the team almost immediately happier. My preference is at least once a week, but once a day is even better. If your team can’t release their code at least once a week, you’re holding them back.
Recently, I heard an engineer describing her team as constipated, which was a very vivid description. Everything feels stopped up because it’s so hard to release new code, and developers build up lots of changes. Inevitably, something will break, and you have to figure out what to do. Do you fix it, or roll back and build up even more changes before release?
The book Accelerate by Nicole Forsgren says the most productive teams release frequently. I'm a huge believer in releasing cadence being a key element.
I advise managers to have regular one-on-ones; they’re essential. One of the reasons is that managers have to build trust with their engineering team. The most important way people build trust is by having regular contact with the person and getting to know each other.
You don't want to build up things to talk about for long; otherwise, you can’t get through all of them in one sitting. Your report may feel like it's building up changes to your production code, and then you find a bug in the conversation. Then the conversation didn't touch on all the important topics and you have to wait for the next meeting in another month or two.
You want 1-on-1s frequently so you get through all the stuff. You won't have all those changes built up, but that ultimately ends up decaying over time.
Make sure people are talking to each other. You don't need a million meetings, but you need some, unless you have a great ad-hoc communication process. The idea is to make sure you’re explicit in understanding all the problems and you're all on the same page.
You should be talking as a team at least once a week to get an opportunity to share context, to make sure you’re aligned, and to get ideas out of the team. This will help a lot with improving engineering productivity.
My name is Camille Fournier. I come from software engineering, and I have an undergraduate and master's degree in computer science. I worked at Goldman Sachs as an individual contributor with a bit of team management.
Later, I went to Rent the Runway, a startup in the US renting women's clothing and accessories. It's extremely popular, especially in New York City, and I became their CTO. I spent 4 years there and learned a lot, going from minimal management experience to managing managers.
Currently, I run a platform engineering team, at Two Sigma, a financial company in New York City.
I wrote the book The Manager’s Path, which is about all levels of engineering leadership focusing on management. I edited another book called 97 Things Every Engineering Manager Should Know that released recently.
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀