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.

Anticipation, proactivity, and the Invisibles

Just read an article via Slashdot on this thing called “Tab Warming” that the Mozilla team is testing for the Firefox Web Browser.

I won’t go into the details, but in essence what Tab Warming does is that it anticipates whether or not you’ll click on a link, and if it does it “paints” the page in the background saving you milliseconds of loading time when you eventually click on it.

Despite the seemingly very small difference in absolute time, (I mean, really, milliseconds?) it has the potential to be the difference between somebody thinking about the page loading versus somebody not thinking about the page loading at all and purely on the content of the page.

And that’s huge. Isn’t the ultimate aim of interface usability to become invisible, after all?

This reminded me of how the best people I’ve worked with are those who pretty much do this all the time: they anticipate what I may need, and even before I’d mentioned it they’re bringing it up and telling me it’s already done.

And to me, despite my never thinking about them (because I don’t have to!), they’re the ultimate stars in our work lives.

To the invisibles: Thank you.

What’s Sales Reporting Governance got to do with Bribery?

I lead a Sales Operations team, and one of our objectives for this year is to establish a “sales reporting governance structure”: to ensure that the right reports/tools get developed, with the right specifications, at the right time; and, perhaps most importantly, with the buy-in by the right people.

Essentially this governance structure looks at controlling the reporting life cycle (something like this report life cycle diagram) from when a report is dreamt up in the head of one of our business partners (our “internal customers”), through to when the report reaches its EOL (end-of-life) and can be stopped.

Though you may think this is somewhat dry work, let me assure you that it’s often anything but. Conversations can be excruciating quite colourful, particularly when it comes to prioritisation and negotiating timelines.

Take for example the following conversation between one of our business partners (BP) and us:

BP: “What do you mean you can only deliver it next Friday? I need it by Tuesday.”

Us: “Sure, that can be done, but we’ll need to stop work on the other three developments we’re working on for you that are due next Monday.”

BP: “No, you can’t stop work on those. I need those next Monday, and this one by next Tuesday.”

Us: “Sure, but we’ll have to exclude the new functionalities that you’d asked for.”

BP: “No, you can’t do that.”

Us:“I’m sorry but if you’re not able to budge on re-prioritising the other work, nor reducing the scope, there’s no way we can hit the timelines you’re asking for, especially when you’re asking for this so late in the game.”

BP: “I’m escalating this. You’ll hear from my manager.”

And so on.

In all fairness though, I have to say that in my experience most managers and senior colleagues (and anyone who has worked in, or closely with, IT) tend to understand that we have to satisfy ourselves with but 24 hours a day to do all we need to do.

These sort of escalations tend to end with “the manager” having a cordial chat with us and agreeing on a workable next step forward, none of which involves us engineering more time into the day.

Establishing a Governance Structure

Having a governance structure tends to minimise “unconstructive” conversations like those above, I think largely because of a mutual trust: the business partner trusts our verdict of whether something is possible or not impossible within a specific time frame,  while we trust that they have thought carefully through their requests and won’t be changing or adding to them unnecessarily.

But the problem with establishing a governance structure is that it, well, needs to be established, which can be incredibly tricky to get going. It’s almost like an negotiating a peace deal, where both sides want the conflict to stop, but are worried what might happen the moment they lay down their arms — will the other side take advantage and strike when they are at their most vulnerable?

I will be the first to admit that it takes a leap of faith going from a world of “if I don’t shout loud enough, and often enough, nothing’s going to get done”, to one where we’re all amicably setting and agreeing on priorities, and where promised delivery deadlines are actually being met.

It also doesn’t help that from a developer’s side, without the benefit of having past projects to tune one’s intuition, accurately estimating project scope or determining deadlines is going to be difficult;  often multiple iterations are necessary before this sort of “accuracy” is achieved. What this means is that early on, chances are good deadlines are going to be missed, which doesn’t help in building trust.

After a missed deadline or two, it’s all too easy to fall back into old patterns and proclaim that the process doesn’t work.

There will also be many, especially those more used to the “free-and-easy” days of yore, who will actively fight the change, citing that it creates too much red tape and jumping through hoops to get things done.

“We need to establish our reporting as soon as possible or we’ll just be flying blind — we can’t afford to go through this process!”

But the thing is, we often can’t afford not to.

When the number of development projects are small, I have to agree that the process, this “bureaucracy”, adds little value. We could simply get on a phone call, or write an e-mail, and agree among ourselves what needs to be done and when. If the requirement changes, no biggie, we simply tweak until its perfect – there’s sufficient slack in the system that will enable us to do just that.

But problems will occur when the number of projects starts to creep up, and more stakeholders are introduced.

The Need for a Tighter Process

The first problem is that due to the higher workload, the slack in the system that allowed for changes in between a development cycle will be gone. This means that changes or additions to the original requirement will likely have to be parked until development time opens up, which could be weeks down the road.

Business partners are not going to like that. “It’s a simple change for God’s sake!”

The thing is, no matter how small a change is, it’s going to be work. Somebody’s got to do it, and that means time out from other projects, which also have agreed timelines. If we focus on that change now, it risks jeopardising the timelines for every other project down the line.

If the change is important enough, then maybe we can take time out from another project and put it into executing the change. But it needs to be agreed by the team owning the other project. Which leads nicely to the second problem.

The second problem is that everyone will have their own agendas, and everyone’s pet project will be “of the highest priority”.

What happens when Team A, B, and C all have “high priority projects” that need to be done by next Monday, and development team only has the capacity to complete one or two? Without a proper process or governance structure, can we guarantee that the project of the highest priority for the business will be one that’s completed?

In the end, more time will be spent explaining to each of the stakeholders why their project was not completed; people will be upset, and the next time they’ll just be sure to shout all the louder, and all the more frequently. More time will be spent on meetings and e-mails, people “ensuring” this and that and never really ensuring anything at all. Estimated delivery dates will be given, but nobody would trust them because they know someone else coming in with an “urgent” request would likely take priority. If it’s “last in, first out”, why should I raise a request early only to be relegated down to the bottom of the delivery pile?

This just struck me as very analogous to the concept of bribery, which I was reminded of on my reading of the book Treasure Islands by Nicholas Shaxson:

Some argue that bribery is ‘efficient’ because it helps people get around bureaucratic obstacles, and get things done. Bribery is efficient in that very narrow sense. But consider whether a system plagued by bribery is efficient and the answer is the exact opposite. [Bribery undermines] the rules, systems, and institutions that promote the public good, and they undermine our faith in those rules.

Despite any short-term drawbacks, there are plenty of longer-term benefits, not least that of supporting stronger surrounding report development structures and a generally healthier culture.

Though setting up the governance structure thus far has been tough, with plenty of push-back and many of our business partners trying to circumvent the process we have established, I think it’s one of the most important things we can, and have ever attempted, to do.