Back to resources

The Value of Speed and Iteration

Performance
Dev Processes

21 July, 2021

Sebastien Cuendet
Sebastien Cuendet

Sr. Director of Engineering at AppFolio

Sebastien Cuendet, Senior Director of Engineering at AppFolio, likes to move quickly when developing a product in order to give his team as much time as possible to perfect their work before delivering their final version.

Problem

When I’m asked what my number one principle is in the world of engineering and product development, the answer is usually speed of iteration.

I really don’t think that this opinion is revolutionary or even original, plenty of engineering leaders and engineers will agree. I think one of the really key things that people often miss, and engineers are among these people, is the value of many shorter iterations. The more iterations that your team is able to generate, the more chances you have in your pipeline to correct your course when you sail astray.

In order to have a lot of iterations, you need to have speed. The faster you work, the more chances you have to iterate. You only have so much money and so much time to produce what you wish to share with the world.

Actions taken

The way I often explain it to people: imagine that you have a budget of four weeks to build something. If you spend four weeks building the first version and then release it, you’ve already used all of your chips. You’re done.

If, say, instead, you spend only one week on your first version and then release it, that first round of user feedback comes all that much sooner. Now, you have three weeks to iron out any problems with the product. This will usually result in a much more robust final product.

The first natural objection to this school of thought: if you’re constantly moving so quickly, how will you be able to manage and maintain a high bar for quality? If you go too fast, don’t you ship crappy code and a crappy product? This is actually a false dichotomy. Speed and quality go together. Refactoring code early and often results in better code than trying to design everything upfront. The same is true for product development.

One way to promote fast iteration is to measure cycle time. Cycle time is the time between when somebody starts working on a code change to the time that it is merged to master. The bigger the code change is, the longer that this cycle time will be.

On a typical agile team, if not especially concerned with speed, the average cycle time may be seven or eight days, depending on what type of product is being built. A cycle time this long means that you’re definitely not delivering value to the user on a weekly basis. I have a goal for my team’s cycle time to be around two to three days.

Think about the change you are making: what value would it have if you released it today, as opposed to in a month? Could you split your change into smaller pieces so that you could deliver some value today already? A user story in progress brings no value to the customer. Releasing even a small portion of it sooner will bring value to the user and to you in terms of this extremely important first round of user feedback.

Lessons learned

  • One thing that I do with my teams: I force them to come up with a weekly goal for themselves. They have to find a way to relate the work that they’re doing to customer value. Essentially, they have to find a way to deliver this customer value every single week. It’s a good forcing function that ends up encouraging these shorter, more frequent iterations.
  • The faster you are moving forward, the more chances that you have to catch any bugs in your product. If you just release a bunch of stuff together, you won’t even know where the bug is coming from. By that point, you’ve already run out of time to fix everything for the users.
  • Splitting the work into very small chunks and making sure we are clear on how each piece of work delivers value to customers are my two strategies when it comes to helping the engineers that I work with.
  • It’s not enough to just put your product out there and to wait. You have to actively be managing it as your users respond to it. I think that this is something that we have not quite perfected yet as an industry. On your Trello board (or wherever you are managing your team’s work), add a column reminding them to look back at what they released.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Changing Face of Life Insurance

24 September

Ben Picolo, Engineering Manager at PolicyGenius Inc., talks about an industry-changing that his team shipped amidst the chaos in the product line.

Dev Processes
Convincing
Leadership
Ownership
Ben Picolo

Ben Picolo

Engineering Manager at PolicyGenius Inc.

Prioritizing Technical Debt

24 September

Ben Picolo, Engineering Manager at PolicyGenius Inc., shares how together with his team, they gamified the whole technical debt solving process.

Tech Debt
Dev Processes
Team Processes
Ben Picolo

Ben Picolo

Engineering Manager at PolicyGenius Inc.

How to Manage an Employee With Depression

24 September

Sachin Shah, CTO, discusses how he dealt with and supported a team member with mental health challenges while handling project deadlines.

Coaching / Training / Mentorship
Juniors
Leadership
Motivation
Performance
Sachin Shah

Sachin Shah

CTO at Self Employeed

When Legacy Codebase Stalls Innovation

19 September

Arpan Dalal, Sr. Director Engineering at RepairPal, shares how sticking to a functional, legacy codebase can stall innovation by deterring people from trying new things.

Innovation / Experiment
Dev Processes
Motivation
Arpan Dalal

Arpan Dalal

Sr. Director Engineering at RepairPal

Making Delivery Faster

19 September

Arpan Dalal, Sr. Director Engineering at RepairPal, explains how to make the delivery faster by improving critical processes.

Dev Processes
Team Processes
Arpan Dalal

Arpan Dalal

Sr. Director Engineering at RepairPal

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.