Managing Expectations

“This team isn’t delivering enough.”

You’ve had a fully funded team of engineers working on a product for 3 years. It has fundamental issues with quality and completeness, and still isn’t integrated with the core platform seamlessly. As time has gone on, you’re getting further behind, not closer.

There is either a problem with execution against the strategy, or with the strategy itself.

You reflect. You’re sure that the quality of the engineers is not the issue. The drive and work ethic is there, and they collaborate effectively. Everyone understands the plan, and everytime you question the decision making of the engineers within the team, you’re satisfied the right call was made. The perception cannot be ignored though: your team looks slow. You are not meeting expectations.

If there isn’t a problem within the team, but rather the tactics are wrong, how do you make that point effectively? How do you manage expectations to be more realistic?

Without looking at the odometer as a passenger in a car, you can estimate from a few sensory clues as to how fast you’re going, but you won’t know for certain. Unless you’re the driver, you may not know just how fast this car is capable of going. As a software leader not responsible for developing the code yourself, but instead accountable for it, you face similar uncertainty.

Counting average number of lines of code per merge request, and average number of merge requests per week, is a nuanced metric at best. It won’t confirm who the best or most prolific engineers are. Leaders, especially the more senior ones, get to where they are from having delivered successful business outcomes by making happy users. They will have a ‘feeling’ for how fast your car (team) is capable of going, and how well you’re driving (running the team), based on their memory of successfully driving a different car.

This is an obvious apples to oranges comparison. If you match or exceed leadership expectations, all would be good. You’re not though. And you’re sure that the problem isn’t with the team. What can you do to get a more accurate expectation from your manager?

Perception

The first step is not to look at your team, but instead to understand the perception of the person who holds the expectation. Why do they think your team is slow? What is it that was so different about their car, and how they drove it?

Were their engineers better? Were there more of them so they could plough through a mountain of work? Were there fewer of them so communication and organisation was simpler? Were the engineers more invested in the outcomes? Did their engineers have more in the tank? Was the codebase smaller? Was the codebase simpler? Were there fewer codebases? Were the standards less? Was the level of maintenance reduced? Were they never blocked by anyone? Were their engineers interrupted less? Was the regulatory landscape different? Were their fewer responsibilities for the team?

This is scratching the surface of the number of questions that could be asked. Regardless of how many people you speak to, you have one journey through your career as a software engineer. There’s an idea in a tech leader’s head about a typical engineer, at a particular year in history, working at a particular company, of how much time and energy there is in a day, and how they should be spending it. The first step in managing expectations effectively, is to understand what the leader thinks that is.

Measurement

The second step is to take measurements. Where does the engineering time go? Consider two teams which are slow to deliver features. One spends 10% of their time working on feature delivery, and the other 90% in manual operational work, bug fixing, and customer support. The reason is clear as to why their feature delivery is slow. Another team though could spend 70% of their time in feature delivery, but their codebase is complex to reason with, and has inconsistent design patterns. The product is hard to test, with an inverted test pyramid, and many manual deployment and verification steps.

Here, 100% of time could be placed on feature delivery, but it wouldn’t be enough. Collect the data, and use it to tell a story of a day in the life of your team. If the perception of the team is slow, it’s likely that the team are haemorrhaging time, and precious mental energy, in areas of which the software leader had no idea. This hypothetical team needs more time for “go slow, to go fast” (see #5 Automate).