Back to resources

The Value of Speed and Iteration

Dev Processes
Performance

21 July, 2021

Sebastien Cuendet
Sebastien Cuendet

Sr. Engineering Manager at dbt Labs

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

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

How to Help Employees Find Their Strengths and Passions

22 June

Łukasz Biedrycki, VP of Engineering at BlockFi, talks about the importance of building on your strengths and finding your passions to maximize your impact. He dives into the tactics that managers can use to support their teammates in this pursuit.

Different Skillsets
Personal Growth
Leadership
Motivation
Career Path
Performance
Łukasz Biedrycki

Łukasz Biedrycki

Head of Engineering at Spectral Finance

How to Motivate Your Engineers to Grow in Their Careers

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, highlights the importance of soft skills and shares how he motivates his engineers to further their careers by focusing on personal growth.

Goal Setting
Different Skillsets
Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Motivation
Team Processes
Career Path
Performance
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Successfully Rebuild Your Product

6 June

Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.

Customers
Product
Dev Processes
Users
Prioritization
Adir Nashawi

Adir Nashawi

Senior Product Manager at Hibob

How to Empower Teams to Build Out a Product Portfolio During Company Growth

6 June

Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Alignment
Goal Setting
Product
Ownership
Performance
Ivo Minjauw

Ivo Minjauw

Global Product Director at OTA Insight