10,000 Foot Developer

Let’s go back in time, to a famous Mythical Man Month lesson:  Nine women can’t have a baby in one month.  Translates to: Throwing more developers at a project will not get it done faster.  Also translate from my personal experience of being a developer for over 20 years: nothing demotivates a developer more than removing ownership of a story from that person during the time they are working on it.

Developers are motivated by ownership.  And nothing annoys a developer — a good developer — more than having to continuously maintain an old stale piece of code.

One gig I worked was a young upstart “lead,” not the worst by any means.  The lead’s only weapon was to come to a developer or a pair and say “is there anything we can split up into more stories to help out?”    We were on a time crunched schedule and the lead was one of those who didn’t understand where estimates came from, thought the title “lead” meant “better developer” (it’s about 50/50 — and in this case did not).

The problem the rest of us were having was that our estimates were being ignored and we were being held to the lead and a few other pm/BA types estimates.  The usual big corporate — you have all the blame but none of the power.  Usually I would write up analysis of the problem I was assigned with meaningful breakdowns, but, since I wasn’t the “lead” this would get ignored.  Experienced developers know how this goes, and its happened many times over my career.  And I don’t mean that my estimates and analysis were refuted, I mean not even looked at, taken seriously, or considered.  When that happens — you let go.

Many of us were taking strategies on the team to get around this management blocker.  Most would lie about their work.  Some would “push it along.”  Some used social context/friendship to coax sanity out of management.   In fact not one of the developers or pairs during standup status meetings in the morning would say anything other than gray reports because of this management style.

If you worked on the piece the inevitable would come — the lead would “break it up” mid development, cause another to waste their time explaining it, hand it off, while the next person then tacked on another thought of code at the end of the first part.  Defects showed up everywhere and eventually we would get a story done and spend twice as much time fixing defects because developers were forced to mid-work divide and conquer when it didn’t make sense.

Rereading the above, two things come to mind:

• The lack of trust on the team from less experience leads created havoc and defects.
• This lack of trust and respect force all developers, junior to senior, to be forced to work in a political minefield.

When a consultant says “that’s why I get the big bucks” — this example is one of the why’s.  Dealing with the BS.

The most difficult thing to do in a management position is to let go and trust.  An even more difficult thing to do is to mentor “superiors” on the org chart through their learning journeys.

In the end cool heads and experience prevailed,