Last year, I started working as one of the tech leaders on a performance optimization project for one of my employer’s customers. At first, the team started using a regular Kanban process, so an engineer would pick some part of the code to optimize and work on until we felt good about the improvement. To me, it felt not to be the right approach to the problems we were trying to solve.

After working part time on this project for about two months (I was dividing my attention between 2 other projects for the same client), I started working full time on the project when the team was already facing some significant process issues.

• P1: Parts of the team had been working interrupted on the same problems for over two months, and they felt the results were not as good as they had expected.

• P2: Leadership, anxious about better ways to follow progress and what was happening in the day-to-day activities, was wondering if the problems would be resolved on time and whether or not we would meet the expectations.

• P3: Senior leadership was pressing for a more concrete plan and predictable results from the team.

These were all legit expectations and concerns. The hard question I asked myself was: How do we approach a performance optimization project in a way that avoids all these problems? The basecamp ShapeUp came to my mind.

ShapeUp is a process created by Basecamp to manage projects. I won’t spend too much time explaining how it works because there are too many posts out there, including the free and available book. Instead, I will explain each part of the process that I adopt and how it helped solve the problems I mentioned above.

Bets, not milestones

To solve the first problem, P1 (the team is frustrated after working on a problem for too much time), I suggest calling each task a bet, not milestones or a story. This naming gives the team a better idea of the nature of their work. I searched for “bet” in the Cambridge dictionary, and it says: “To risk money on the result of an event or a competition, such as a horse race, in the hope of winning more money.”. So, the approach of the engineer working on the task is entirely different.

Let’s create an example to show the power of this simple change. In parentheses will be my opinion.

Case 1 “Project: reduce the time to load Something.”

• Manager, explaining the task to the engineering team: Your goal is to improve the time to load Something as much as possible. (This is too generic to be useful for an engineer.)

• Engineers, in their minds: How can I make the load Something faster? (Here, they will start reading all the code, every single metric, do some napkin math.)

What if I cannot improve this at the end of the sprint or at the end of two sprints? (they will think this after some time.)

Maybe, if I rewrite the latest greatest technology out there, it will improve the load a lot. (You know engineers? right? We need limits to be effective.)

• My learning:

This scenario has too much freedom. The engineer’s creative mind will drive toward perfect solutions that may take forever to implement, or even worse, after working on the problem for a certain amount of time, they may feel lost and unproductive Innovation needs constraints.

Now, let’s make a simple change to the task’s title by replacing “project” with “bet.”

Case 1 “Bet: reduce the time to load Something.”

• Manager, explaining the task to the engineering team:

We will bet your next three weeks of work on improving the time to load Something. (Note how the message sounds completely different)

• Engineer in their minds:

What can I improve in three weeks that can reduce the time to load Something? (The deadline constraint here has driven all the effort to look for solutions.) Maybe if I rewrite the latest, greatest technology…no, three weeks is not enough for that. (Here, the solution-driven engineer mind will cut out that possibility.)

• My learning:

Note that in this case, the imaginary engineer team didn’t even spend time thinking to themselves, “What if we fail?” No one bet to lose (or, at last, that is not normal), but losing is part of the game. Even more important, if you win a bet and think you have the right hand, you may want to double the Bet. Imagine in this situation after the three weeks of work, the engineer comes to the team and shows he improved 30% of the load time. Still, they found another issue that they think they can fix in two weeks, and it will improve another 40%, resulting in a 70% better, faster load. The team can decide together if they want to leave the Bet with the already won 30% or bet another three weeks on this new promise.

How I convinced leadership to take this idea

Other teams were already overusing the words milestones and projects and the organization was dating their deliveries, so everyone was already looking for better names for the performance team. Moreover, they were already aware of the team’s stress (sometimes unjustified), and calling the tasks Bets would improve setting the right expectations. Lastly, I told them the same story I told you (above), and they captured the idea.

Shaping performance improvements projects

Introducing the idea of bets was a great win. Still, it was not enough to solve the other problems, P2 (Leadership anxious to follow progress) and P3 (Senior leadership pressing for a more concrete plan), so my next step was to introduce the principles of shaping to the project planning.

Planning performance improvements are challenging. Often you won’t know what to change. You may have a goal but no clue about what to change or where to start.

My next challenge: How do I set goals for a project so the engineer can make the best use of their creativity but within the proper constraints?

“Request to /images/get must return under 100ms” is too concrete, and “Improve user experience” is too abstract. We need to find the middle ground.

Creating a list of bets

When you are on a performance project, there will be ideas of what to improve. This initial list does not yet need to be final or very well explored. With an initial conversation with the team, we can develop a list of bets worth putting on time. A few steps suggested from the ShapeUp book help to make them more concrete after getting the list.

So here is what I did.

Set boundaries

The time to complete the project is fixed, so that is an excellent boundary already. It will serve as a base for the other boundaries you may want to set, such as backend-only improvements. (If the team does not have frontend engineers for that bet, this is an important boundary to set.)

Define the elements

After setting the boundaries, it will be easier to find what elements need to be changed. It is essential not to go too deep into the details as we create the list of bets. This is not a deliverable list yet, as this is hard to define with this kind of project, at this phase.

Define risks and rabbit holes

This is the most crucial step of the bet list definition. What are the risks of losing this bet? And more importantly, where are the potential rabbit holes that may take forever to overcome? Senior engineers will probably know the rabbit holes of any performance task. (They probably have been there already during some other work.) If the team is entirely new to the code or the problem, you may want to do one or two POC cycles before shaping this work.

Examples of rabbit holes in performance-improvement projects

• Rewriting in the latest greatest technology

• Trying to optimize external dependencies’ performance too much, for instance, focusing all the time trying to measure every single query that goals to your database to see if tiny query improvements may lead to a great result.

• Trying to parallelize problems when the parallelization may not be worth it

Don’t get me wrong here. Parallelizing algorithms may result in tremendous performance improvements, but take into account that it is not an easy solution. It may also lead to even worse problems than slowness (like data races). Also, if the project’s main stack is not well suited for doing that, it may introduce much more complexity to the solution and end up being infinitely more complex to maintain in the future.

How I convinced leadership of taking on this idea

If you consider problems P2 and P3, the leadership team was already open to different ideas given that there was little visibility in the other option. What I sold to the leadership team was:

1. This provides predictable timelines. Since the bets have a fixed time to finish, it will provide an idea of the direction that the team is going, even though it does not provide a clear idea about what to expect as a result of a bet, which the previous method also did not provide.

2. Boundaries and knowledge risks are provided right away, so they can decide which ones to take on and which ones not to bet on.

3. Regarding the leadership (project managers and scrum masters), give them a clear idea of what bets are in progress, and let them know the rabbit holes in advance. They will see when a blocker shows up and can determine if they should help the team to unblock it or orient the team in a different direction because they are headed into a rabbit-hole rote. There may not be a rote for returning any time soon.

Betting table

We also incorporate a lighter version of the betting table. Before starting the next cycle of improvements, we visit the Bets list, and the engineer picks the bet for the team (this includes the QE team), prioritizes (decides on the order) the list, and then chooses the immediate next bet we will work on.

Conclusion

Interestingly enough, these ideas were not hard to sell to the leadership of this project. Everyone bought the naming concept first and then the way to shape the work because they fit well with the problems we were facing. In some presentations for teams outside of ours, we sometimes remove the word “Bet:” from the title of tasks because it requires initial explanations, such as addressing the question “Why Bets???” However, I think this is all part of the process, and once our team starts collecting more consistent results, we can sell this process outside the performance team, and we may have to adequate one practice or another.

It is still too early to state in this blog post how ShapeUp has helped this project succeed. The project must still run for the next year or so before I can call it a success. Yet, it has supported engineers and leadership’s communications, giving both sides the right ideas and expectations. It has reduced stress levels by enabling a clear “when to stop” point for the team.

I hope to come back to this subject a year from now to speak on how the project ended. Still, I am happy with how the method made the team work better, for example, helping me as a tech lead on this project, seeling the results in my daily tasks, shaping work for the team or for me.

I believe significant changes for engineering companies are implemented bottom-up rather than top-down. I think it was an excellent opportunity to bring ShapeUp’s ideas to the organization I am consulting in, so let’s see where it leads us.