As an engineering leader, you should be constantly working to reduce the amount of time it takes to complete one cycle of a feedback loop.
What do I mean by feedback loop? This is anything where you do work, and then you need to await a result in order to be able to do more work.
Some examples:
- Your test suite needs to be blazing-fast. The ideal case is that you write code and then your code is immediately validated by a wall of green. Tests in CI should fail fast, so you don’t submit a patch then walk away, thinking things are all hunky-dory when they aren’t.
- Code review should be viewed to be urgent. There should be very few things more important than getting back to your colleagues when they request your review.
- Stakeholders need to be generally available for review. For example, a weekly meeting to review the result of work means that, at worst, a contributor can be waiting up to a week for feedback on work.
- You should be shipping the smallest units of change. You should be constantly validating your changes with the end user, without it needing to be a whole stack of dependencies; likewise, if you have a mistake in your assumptions or an outright bug that’s slipped through your tests, you want to discover that as soon as possible as well.
“That sounds like a lot of work, Joe!” Okay: yes. I’m saying you should prioritize unblocking work — the work to unblock work is well-placed work; it’s an investment that pays dividends.
One of the easiest ways to speed up a test suite is to go in and figure out a way to remove every sleep statement. One of the easiest ways to increase your engineering velocity is to shorten every feedback loop as much as possible.
