Seek feedback and iterate

As I sat there in front of my screen developing the spreadsheet/tool that was to be shared with the more than hundred salespeople in the company I realised I had doubts – would this really work? Was this an improvement to what they already had? Or was it more change for the sake of change?

I honestly felt that it was a genuine improvement, but I didn’t know. And having spent so much time already getting to where I was on its development, the last thing I wanted to hear was that I was on the wrong track, and that my work would come to nought.

Also, I was in a state of flow, and getting feedback was an overhead that would break that. Did I really want that?

I got up from my seat, walked over the coffee machine and made myself a coffee while mulling over this: to get feedback or not to get feedback – that was the question.


Development’s fun – I enjoy it. Solving technical problems and shipping something useful is one of the main reasons I entered the tech/data space. But having moved into a managerial role it’s something I do less and less – development’s now a team sport, one in which I’m no longer the star.

That sense of accomplishment when something you create goes out into the wild and receives accolades is something I really miss.

If this piece of development went live, I would well get back that high.


The steaming cup of coffee in my hand relaxed me and made things a little clearer: I made a mistake of having worked on the development as long as I had without getting feedback. I should have followed the same advice I always give my team: don’t work on something for too long without getting feedback, otherwise you may just find yourself spending days or even weeks on end working on something nobody wants to use.

(Thank goodness I also always drill it into them: “Do what I say; not what I do.”)

The longer I went without feedback, the harder it was psychologically to want to seek it. But I knew I had to do it.

I personally had doubts, and this was my baby here. I gritted my teeth, got up from my seat, and started seeking feedback. Like Sun Wukong (aka Monkey King), I reluctantly travelled to collect the sutras, during which I had to bear the pain of hearing things like “it won’t work” and having my “great” ideas turn bad.

It was emotionally draining, but it had to be done.


Hard as it was, I stopped development that day. The week (and weekend!) of frantic development came up to nothing.

Still, there was something I got out of it — like they say, there are no mistakes, only learning opportunities. And for me, it was a reminder to myself to seek feedback early, and iterate.


It was ironic that it was about this time that I was reading the Lean Startup by Eric Reis, one of the pioneering books on iteration and getting feedback. I leave you with this passage that I always use to remind myself before I go too deep into a development or process rabbit hole (text in bold mine):

From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributors accountable, and, most important, allows experts to work without interruption. At least that’s the theory. Unfortunately, reality seldom works out that way.

Consider our hypothetical example. After passing thirty design drawings to engineering, the designer is free to turn his or her attention to the next project. But remember the problems that came up during the envelope stuffing exercise. What happens when engineering has questions about how the drawings are supposed to work? What if some of the drawings are unclear? What if something goes wrong when engineering attempts to use the drawings?

These problems inevitably turn into interruptions for the designer, and how those interruptions are interfering with the next large batch the designer is supposed to be working on. If the drawings need to be redone, the engineers may become idle while they wait for the rework to be completed. If the designer is not available, the engineers may have to redo the designs themselves. This is why so few products are actually built the way they are designed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s