confidence and visiblity

People don’t have confidence if they don’t have visibility.

I’ve just recruited 9 temps to work on our data cleansing project.  One of them, John, has recently finished an IT degree so I asked him if he would work on what I call our “data engine”.  At it’s simplest this involves running queries against an Oracle database using Microsoft access and Excel, but in the longer term he will need to rewrite a rickety system that I’d hobbled together to automatically identify dirty data and to catch when other parts of the organization have dirtied data that we have previously cleaned.

I’ve done lots of this sort of stuff before so it is easy for me, but John had no experience with any of the technologies I was asking him to use. 

So, I asked John to do a couple of tasks that would be easy for me but would be harder for him.  I made it clear that I was throwing him in the deep end and that I expected it to take him a few days, but that I wanted him to struggle a bit – because that’s how you learn the tricky stuff.  I asked him to ask me for help when he got stuck. 

He went off and did exactly as I asked him.  He took his time and in the end he did a good job, in good time.  I was really pleased with his effort.

But here’s the glimpse that scared me:  while he was working independently (just as I asked), I kept having these horrible urges to ask him to prepare a design document. 

But, a design document wasn’t necessary:

• If I was doing the task, with his same level of experience, I wouldn’t prepare a design document.
• The size of the task didn’t warrant a design document – beyond a few scribblings on a pad.  This was a university-assignment sized exercise where (if you are average or above) you solve the problem first in code, then you write the design up, then you hand in the assignment.
• A document wouldn’t be any use because the only way he could build what I asked for was to (a) verify his requirements (b) do a little research (c) build a little bit (d) test that it worked. (e) repeat until he had something to show me.  That is, he’d have to do it as a learning exercise.

I was a little bothered by my reaction – why would I want to ask him to do something that I didn’t want him to do?  I thought about this inconsistency a bit and I realized that a design document would serve a purpose: it would give me some visibility (and therefore confidence) in what he was doing.  I’ve only known John a few weeks and I didn’t know him well enough to have faith or trust that he was up to the job (which he is). 

I thought a little more and I realized that an easier way for me to gain confidence and visibility was (a) to spend a little more time with him and (b) break the task down into smaller deliverables.  Both of these were easy to do.

This little incident helped explain another little incident: when I started my current role, despite busily working to construct our “data engine” before we ramped up with the new staff, someone in the client organization asked “what value” I was adding.  Why were they paying for me?

This seemed, to me, to be a stupid question.  I was very busy doing what I was asked, and  I hadn’t done anything to demonstrate that I wasn’t adding value.  My first instinct was to think he was stupid. 

I chatted with my boss about this and we agreed that the client wasn’t stupid. 

We agreed that the problem that I needed to solve was that not only did I have to add value I had to demonstrate that I was adding value.  This was easy, I just spent a little more time writing up my progress reports to emphasis not just what I was doing, but why I was doing it.

People don’t have confidence if they don’t have visibility.

Comments

[John Rusk]

Very good post Clarke.

I think it's relevant not only inside teams - as you describe - but also between teams and their customers. I suspect some customers, like you with your new team member, look for documentation when other evidence of progress (e.g. iterative releases) would be more appropriate.

[Lasse]

Clarke, I see that you've corrected the "visability" typo.
Too late, though, since you already managed to coin a new term for me:

visability = ability to make stuff visible

[John Rusk]

visa-bility - wouldn't that be the ability to pay by credit card ;-)