Engineering Productivity: How Two Sigma Keeps Developers Engaged

Prioritize, prioritize, prioritize

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.

Don’t be a teddy bear

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.

Challenge your people

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.

What advice would you give for engineering leaders to improve engineering productivity?

Release code more frequently

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.

Use 1-on-1s

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 the information flows

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.

About Camille Fournier

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.

Camille Fournier returned for a panel discussion about the software development trends in 2020, and another interview about building platform teams!