Encouraging autonomy

I recently completed a minor technical project for my company last week.  Since then, I’ve been considering what went right, what went wrong, and what could have been improved.  The resources I’d been assigned were over-qualified, the budget was generous enough to be irrelevant, and we were given an appropriate amount of time.  In my analysis, I began to fall into a dangerous delusion of self-serving bias – that I was responsible for everything that was correct and the saving grace for everything that was wrong.

Then I came across an article highlighting leadership practices at Google.  It outlined that regardless of a project manager or manger’s background, successful individuals were predictable.  When stated so bluntly the connotation seems negative, but the article elaborates that such predictability fosters autonomy in those around them.  Had I been stifling my team members through micromanagement?  The article opened my mind to the idea that I could have been the cause of many of the problems experienced during the project.

Am I at fault?


What is the solution?

Communication is paramount when entering a situation where the parties involved have different goals and priorities.  As a project manager, my desire to meet scheduled deadlines may have placed unnecessary stress or burdens upon my teammates.  The Project Management Institute offered the following solutions to help get out of trouble:

  1. Seek out your sponsors – Leverage their expertise and experience, don’t avoid escalating requests until it is too late.
  2. Consult with your team – Don’t try to hold others accountable for unforeseen circumstances, utilize team meetings to get honest and open feedback.  Take heed of ideas from others and give them fair consideration against your own.
  3. Rely on backup and supporting information – Create documentation with the idea that it WILL be used later.  Making the effort ahead of time to record details will ensure that they are more thorough as the information is still fresh and will save time later when details are needed.
  4. Enlist outside resources, if needed – Don’t let pride keep you from obtaining outside expertise when necessary.  A timely admission that “I don’t know” is better than letting a mistake carry through to later stages of the project and then incurring rework.
  5. Remember that halt is an option – With the exception of drop-dead dates, remember that asking for more time given reasonable factors is ok.  Taking a bit more time will help to avoid doing too many things at once and get critical components in place that will in turn improve future decision making.


Another article emphasizes that storyboarding, like our class’s Post-It exercise, would prevent or remedy such hold ups. I worried about the impact some of my decisions had over the course of the project – a couple of the employees are now leaving the company perhaps to find autonomy, mastery, or purpose that I did not provide.  One such employee bolstered Google’s view on predictability, stating that while our project went well he sought a “stable” environment.  Distraught, I considered my approach and whether or not to use storyboarding as opposed to a conservative waterfall approach.

Does storyboarding create too many subtasks and therefore encourage micromanaging?

Or does it encourage autonomy?

Is it possible to have increased autonomy without giving up the ability to track progress at a low level?