Uncharted Waters

Mar 7 2016   8:57AM GMT

Phantom Management

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


I have heard a lot about phantom managers, or sock puppet managers, for a long time now. It was just recently that I actually saw one.

The team I was working with was working on a three week release cycle. About a third of that was spend on tasks that had absolutely nothing to do with the release — mainly updating documentation. The value of that was unclear to the people doing the work, but for some reason it had to be done.

Things got weird when we started asking questions.

We started with the team leads by asking what the value of spending so much time on things that weren’t pushing the release forward and got vague answers about an eventual refactor. That feels like a reasonable answer, but there are tools that can help build a state diagram of large products in a matter of minutes.

After that, it was a little hard to figure out who to ask. Eventually we ended up in the office of the person that ran the entire development group. People at that level are understandably detached from the gritty details of software development. Their focus leans toward the financial value of the product and how things fit into the customers timeline. When we asked that person about that documentation week, of course he had no idea.

Somewhere, somehow. the idea that this one task was extremely important got embedded into that team culture. The person that wanted things done in that particular way had probably since left but the power they had still lingered so much that even asking to do things differently was taboo.

phantom management

That is the sock puppet, the invisible source of power. Invisible power gets teams stuck doing practices that don’t help release software.

But, what if the team had just asked themselves?

Management is ultimately responsible for every success and every failure that happens under her/his watch. If I want to try something new, like getting rid of a boat load of documentation so we can move faster and get permission and fail, the manager looks bad and will have to stand tall for the people higher in the organization. If I try something new and that ends up helping us get higher quality releases, or an extra feature out the door every three weeks, then I look good. But, that puts the manager on the sideline. If the individual contributors can come up with ideas to add value, and push them through on their own, why even have a manager over that group?

Most software companies aren’t terrible. Maybe things could be better, but software is moving out the door every few weeks. Managers in more traditional companies have no incentive to change things, or to try new approaches that, win or lose, threaten their position.

I’d probably do things differently the next time I experienced this. Instead of asking my way up the chain till I found someone that had no clue then working my way back down, I’d just try an experiment. What would happen if I just stopped that documentation. How long would it be before someone noticed? Days, weeks, months, longer than that? If no one notices, chances are that activity wasn’t really adding any value to the team. And also, you just magically found time to do those things that you’ve been wanting to do if some time cropped up.

If you have to ask permission to try something out, you probably won’t get very far. Traditional management is a delicate political game. Take a risk and try it out.

Or you could always go independent.

4  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • mastimela
    Nicely explained article. and you do have a point about people having pigeon hole point of view regarding processes. I call it a "Bull Shit Paradox" = " It is crappy, But it works, so why change it?"
    Also, I was not sure if you meant documentation not a reasonable task or in your case, 1/3 of total time spent on documenting is a little too much.
    10 pointsBadges:
  • TAN1016

    You did not mention what type of documentation was being created/updated.

    Usually when a development group is updating documentation, it is because of a previous management decision to eliminate the tech writer job for the team and just place that task onto the development team. The documentation is usually user or help text for the application being created or enhanced. I challenge you to do what you say and you might see a PO'd support person at your cube asking - Why was this documentation omitted from your latest delivery? Ask yourself how much time will it take to update that documentation after the delivery is out the door before you just take that risk, it might be too much and you may go independent before you would like...

    10 pointsBadges:
  • Silveryne
    Documentation is not important until it becomes important. I work in standard setting and while I understand the value of flexibility, we need to appreciate the value of structure as well. A balance should be struck. 

    If value to documentation is lacking, find out why. Maybe, the solution is the ability to mine the data within prior documentation, that will help your manager to have something to show for the hours invested to such a change. 
    10 pointsBadges:
  • dalinn
    What are these pesky "backup" things.  I think I'll just remove them and see how long until someone notices... 

    While your suggested approach could work in some situations.  There's definitely a high risk of things going wrong.
    30 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: