working on this?!” is what Ido, a senior engineer who worked on my team at RapidAPI, used to frequently say out of deep frustration. I can truly relate. I remember when I was working at Wiser, we were constantly getting more work and work done without an end in sight. Another component to code, another feature to deliver. But even after a perfectly done execution, a week or two afterwards a Change was needed. It could have been just a small bug to a specific client. Or that we haven’t entirely 100% resolved what the company is still continuously trying to resolve. The need is not yet fulfilled. We merely thought we were done with it, but we never were. And we never will. Let’s talk about how Tasks are born and die.
Change entails Feedback that entails Change. We need to pause and ask ourselves “has it always been like this?”. So let’s take a little detour. Let’s go back to the days before Agile and get a quick history lesson. We’d know better where we are when we know where we came from. To understand how The Wheel of Change does any good.
We realized how important it is for it to keep spinning, to meet business needs. And we do so by making sure to deliver fast by delivering small. And as change entails feedback, it would entail we’d be getting back a small feedback. Which would entail only a small change. Let's start talking about how these insights affect our day-to-day work, what challenges they present and how to overcome them.
In this chapter, we’re going to examine another property of it. The spin has a speed which can be controlled by throttling it correctly. By speeding it up & slowing it down when necessary. That would require to act correctly under necessity itself and overcome it.
Good timing is knowing when the exact time is to do a Change. And it relies on having a clear expected value. But only when the Change is done, the actual value presents itself. From the moment of initiation to the moment of completion, we go through a process or fruition which ends with the actual value. The actual value and the expected will probably differ, but they also differ because of the duration of the fruition process.
In the last few chapters we’ve talked about three concepts. Throttling, where some actions we take spins The Wheel of Change and causes the change-feedback-change cycle; Inertia, when the spin takes control over us; And fruition, the time it takes for the actual value to surface v.s. the perceived value. In this chapter, we’re going to see how thinking of the three together helps us avoid executions of valueless tasks.
As most Changes are born out of it, feedback fuels, throttles and sets the direction of The Wheel of Change. We would only be talking about feedback caused by people, processes, communication and relationships. In this chapter, we’d first be talking about the importance of feedback itself. With stories and use cases from non-feedback processes.
In this chapter, we’d be exploring the effect of Feedback on Change. On how the right feedback at the right time leads us away from a non-beneficial Change, which then leads us away from the wrong rabbit holes. We’ll see what happens when insufficient feedback is gathered, the wrong one, or at the wrong time.
we’ve talked about what are the benefits of getting the right feedback at the right time. It prevents us from going down the wrong rabbit hole, and from wasting time on coding. Alas, there is one more thing that takes us there. And that is misunderstanding feedback. And we do plenty of that.
In the last few chapters, we talked about the importance of feedback and the feedback process. We’ll follow up In this chapter and the next, by talking about the internal feedback process, and how it changes the development process and feedback itself. As it involves the two characters of engineers and product managers, we’ll be exploring it from both their perspectives. By that, to try and reconcile between the two.