Thursday, September 8, 2016

Management Fail!



A developer in my org came to me with a technical question she was working on puzzling out around something we call "Decision Units" in portfolio.  Decision units itself is a topic worth its own post, and not really important here, but the gist of it boiled down to this:

Her: "We have a problem handling decision units that exist in multiple business units, where analysts in different groups aren't aware of all of the logic relationships that might exist for that project."

Me: "What's the problem?"

Her: "Well, the way we're handling things right now, if anybody makes a change to the logical relationships for a given project --if they add a dependency or some sort of optional relationship or anything-- it will wipe out all the stored values for that project.  Worse yet, the analyst who loaded them before won't know they were wiped out, and when they go back to load them again, there will be a bunch of new alternatives there that they never heard of!"

Me: "That is a problem!  What do you think we can do about it?"

She gave me a good explanation of the issue that indicated she understood both the technical character of the problem and the business character of the problem. 

She really had her head around the thing.  She then delivered a very technical, possible solution that involved setting some flags and having users determine several things in advance and some other business rules around the process flow.

Me: "I think we can do something simpler.  Here's what I think..."


And then I went on to sort of brainstorm out a couple of default states and business rules that eliminated most of the possible sources of trouble.  Lastly, I sketched out an approach that would handle the last situations elegantly and simply and without requiring the users to do anything they weren't already doing.

Her: "Wow! That was really great!  I'm glad I came to you.  Here I was, thinking of something super-complicated and all I needed was to talk to you and you had a simple answer right away!  Thanks!"

I felt pretty good about myself for a few minutes and then realized I had totally failed her as a manager.

With a little coaching I'm pretty sure that she could have come with the answer on her own.  Maybe a few questions, or at the very least I could have structured the conversation more collaboratively.  I sort of pontificated how I think it should work and we were done.  My developer was left maybe feeling good about my skills, but probably a little less confident in her own.  That's a big fail as a manager.
this is a clever metaphor!
I think this sort of thing is why it's very hard for managers to make those "Career Pipeline" transitions from independent contributor (IC) to manager.  We build up these technical skills and are rewarded for them, and often they become a source of pride and self-worth.  When problems come along that are in the sweet spot, we think immediately of a fix.  We miss the chance to do our new job, which is coach the person bringing the problem as they figure out a fix.

1 comment:

  1. Great post, not the first or last to "fail" there, but the good part is you recognized it and will do differently next time!

    ReplyDelete