I once worked on a team supporting an internally developed and maintained application.

This application was the beating heart of the organisation. Every organisation has one of these.

You know the application at your company, the one that can’t be bought off the shelf? The one that reflects your company’s business model?

That one.

These applications have proprietary information in them. Information that is, more often than not, difficult to extract.

The only people who know the data are the team that support the application. That creates a reliance on that team to provide that data when requested. Particularly when it is an unusual request.

Is Any Question Complete?

When senior leaders needed information not available in any existing report, we would get a request via the IT Director.

These requests were unique. They couldn’t be met by a standard report. These leaders and managers were trying to answer a question they could not fully articulate.

They did not know exactly what they wanted or were looking for … yet.

These requests used to go to one of my senior team members. Lets call him Mike*.

You could sense Mike bristle when the IT Director approached, we’ll call her Ellen*. Mike knew what was coming. The stress that came over him with one of these requests was palpable. Mike had been here before.

Ellen would ask for what she needed.

Mike would listen. **

Ellen would go back to her office.

Mike would start work on the query to get the data.

And he would work at it, and play with it, and polish it. Mike always produced a well thought out and considered report. Applying all his considerable local knowledge of the data.

It was presentable and had everything Ellen was looking for.

Mike would head for Ellen’s office with a printout, or email it, and get on with the rest of his work.

Is the First Answer Correct?

You know what is coming don’t you? You have been here before. With your own boss, or your own team, or your own customers and stakeholders.

Ellen would review the report and immediately make changes.

However Ellen would phrase her feedback, it mostly go interpreted as her saying it was not what she asked for, and therefore wrong.

Not what she wanted?

None of us want to hear that after putting a whole lot of effort into something.

And the cycle would repeat again. Each time with more frustration and more steam and hot air … until eventually it was right.

This happened all the time. And Ellen always went to Mike for the requests

Until one day she didn’t…

Until one day she didn’t.

One day that request fell on me. Ellen approached me.

Being young and impressionable I modeled my response on Mike. I bristled and felt stressed at the request. I knew what was coming.

Whatever I did I was going to be wrong.

Except I didn’t model him.

The stress, for me personally, made me do something different right up front. I think that having seen how this would play out with Mike I wanted to get ahead of the curve.

So …

I Showed Early

I showed my initial output early.

Before it was pretty.

Before I was sure I had all the right data points.

Before I was sure that all my query was accurate.

I extracted everything I thought I heard Ellen ask for, and a little bit more that was stored in the same place.

I took that draft into Ellen’s office feeling apprehensive.

And it was fine. Ellen was fine. The world kept turning.

Ellen looked at what I had produced. She thought about it and adjusted her request. She asked for some additional data and to remove some.

I went back to my desk and made the changes.

I Showed Often

And we repeated that cycle. This time it was shorter, maybe the adjustments took only 10 minutes.

And Ellen made more suggestions.

And I made more adjustments.

And the cycle repeated, getting shorter each time. Until we had exactly what she wanted.

The process was less painful than I thought it would be, and less painful than what I had observed.

It was quicker too. We got to the right answer quicker and with less tension and frustration.

And I became her go-to person for those requests going forward.

Show Early, Show Often

I learnt a valuable lesson that day.

People don’t know what they want to ask

The IT Director, Ellen, didn’t know exactly what she wanted. She had an idea of what she wanted, but she didn’t know exactly.

She couldn’t describe it in sufficient detail to get it right first time.

The sooner you realise this the sooner you can adapt your approach and ask better questions to find out what they really want.

For example:

• Why do you want this information?
• What problem are you trying to understand or solve?
• Who is asking Ellen for this information?

People want to work with you even if they don’t say so

She wanted to work with me to figure out the answer, even if she didn’t know it or say it. Yes she was my senior, and she probably didn’t think of it that way, but she needed help getting her request right.

She needed a sounding board and to see it take shape.

It is not a competition. You are not out to score points by being a hero. You are working in partnership with your stakeholders. Approach it that way and you can build the relationships required to get the best outcome.

Back Brief and Show your Drafts

In this example, I did that by presenting an early draft. The back brief process helps me check whether I heard the instruction correctly.

This is a form of listening. Showing that you heard  what was asked. The feedback is critical for making the required adjustments.

Show what you think you heard. Show it early. 

If you are Polishing, Stop

If you find yourself spending more time making it pretty, stop. Check in with your stakeholders.

Polishing is a sign that it is time to share your work and get feedback. It can be a form of procrastination.

Before you get all the formatting just perfect, be sure the content is correct or you are just wasting time.

Do it again

Repeat until you are all satisfied.

I absorbed this lesson early in my career and have followed it ever since. It comes naturally to me now. Maybe it always did.

I am sure I use it as a defense mechanism too. I really don’t like being wrong. Not in the know-it-all sense, but in the exam question sense. And this approach helps me make constant small adjustments in the right direction.

So my ask of you is:

• Show your messy early drafts.
• Show them all the time.
• Don’t take the red marks and comments personally.

You will get there faster and you will have more fun doing it.

* Names changed.

** This would have been a great opportunity for Mike to practice the back brief process to check his understanding before writing any line of code.

If you want to learn more join my email list here.

Feature image courtesy of Alice Grace and Unsplash.com