Patience is a key skill to master.

Patience is a key skill to master.

Jay Yarow retold a story by Adam Lashinsky, "The Difference Between the Janitor and the Vice President." It's a short story, so I'm lifting the whole thing and quoting it here:
Jobs tells the VP that if the garbage in his office is not being emptied regularly for some reason, he would ask the janitor what the problem is. The janitor could reasonably respond by saying, "Well, the lock on the door was changed, and I couldn't get a key."

An irritation for Jobs, for an understandable excuse for why the janitor couldn't do his job. As a janitor, he's allowed to have excuses.

"When you're the janitor, reasons matter," Jobs tells newly minted VPs, according to Lashinsky.

"Somewhere between the janitor and the CEO, reasons stop mattering," says Jobs, adding, "that Rubicon is crossed when you become a VP."

In other words, you have no excuse for failure. You are now responsible for any mistakes that happen, and it doesn't matter what you say.


So, back to my impatience. The above line of thinking about the spectrum of accountability has brought forth another thought in my head: The period between action and result expands in a similar fashion.

For a Junior Developer, fixing bugs, the time between making a change and seeing a bug squashed is measured in minutes. A Senior Developer may take a day or two to refactor a section of code. A Team Lead providing direction won't see results from their decisions until a week has passed. A Manager may work on quarterly scales.

And the VP? Any action initiated at the higher levels can take a year or more to see the results. Of course in the space between action and result the exec, manager, and team lead, are constantly steering and influencing and course correcting; but ultimately their success comes at the end. Their results are accomplished and recognized only at the end.

And for the VP, results are only measured in a PASS/FAIL grading system too. Everyone else gets some amount of reasoning to justify the result.

This brings about all sort of interesting thoughts: what is Micro Management? It's the result of someone operating on result periods much shorter than they should be. Who should make hiring decisions? Who benefits from changes in corporate policy? Who benefits from applying an Agile development methodology? The answers are obvious if you calibrate the result period to the accountability level.

For example, from the Team Lead and down through the ranks, Code Reviews have very little impact on their units of time. In fact, they probably hinder their ability to meet week sized deadlines. But for a longer event horizon, code reviews have proven to be very effective at improving quality and getting a product ready for release. Code Reviews matter at a Manager level, if you want to hit a monthly target, reducing bug fixing time matters. Therefore the decision to implement a Code Review policy for a project serves all people with long periods of influence. Another is Test Driven Development, again results come much later in the program. Thus the decision to apply TDD must come early so that it can actually have an impact. Therefore it needs upper management influence to ensure it is applied.

If you want to understand your role and sphere of influence in an organization, measure the time between decision and result. If your periods are getting longer and longer then you are influencing more and more. If a majority of your decisions produce results in shorter periods than they should, then you are thinking about problems below your pay grade.

0
0
0
0