Get A Clue From The Clueless

"Why is my <manager>|<project>|<pointy-haired boss> so clueless"?

If you had a dime for every time you found yourself asking this question, would you have retired by now? It's the catch 22 for a developer, you have tons of code to write and test, but also tons of interruptions and meetings to talk about when you'll be able to finish your work. Worse yet, they're so out of touch with technology, they offer no help if you do run into a real problem, am I right? Completely Clueless, proof positive of the Peter Principal in action.

Or are we developers missing something, blinded by our brilliant technical skills?

Early in my career my father gave this advice: "Don't dismiss anybody. They have their job for some reason, be it a skill, knowledge they hold, or a personality trait. Find out what it is they know that you don't and learn from it."

If we take a step back and apply a little logic, that clueless manager is likely higher in the food chain than you, which means that at some point they've had to impress somebody to get promoted. They get to keep that job only so long as they continue to fulfill the business's needs. These facts would contradict our original hypothesis, perhaps those clueless managers aren't so clueless after all?

The reality is a manager has to be aware of and answer to the business reality. It's never just a matter of "will it work?" but "when will it work and at what cost?". No matter how good an idea seems on paper, ultimately it's got to look good in a project plan to be worth money from a project sponsor. Businesses survive because of Profitable Success.

So a challenge to you if you are struggling with a clueless manager. For the next few months, but aside your assumptions about what your boss needs to hear and instead open up and really listen to what they are asking for. For example you can start with the following exercises:

1) Switch from a pull to a push status model. If you don't know already, ask your boss what day of the week they report the project status up the chain. Then prepare your status report to them a day earlier and send it (put the reminder in your calendar!). Be ready to clarify anything they have questions on.

I've found that after a few weeks as my boss learned to trust my report, more importantly I learned how to phrase things to get my boss's attention when needed, those annoying interruptions to explain current project state dropped off to almost nothing.

2) Use your boss's words back at them: If your boss talks in percentages report percentages, If your boss likes hours talk in hours. Whatever your internal project clock is, figure out a formula to convert to their measure and stick to it consistently.

My company requires percentages. My boss likes hours. I only trust completed test cases. My solution was a spreadsheet that tracked hours worked then subtracted that from hours estimated, generating a total hours remaining and percentage complete. If my test cases success % matched these raw numbers, I knew project was on track. When my test case % started slipping, I adjusted the raw numbers down and more importantly, communicated how I would catch up with the plan. Turns out my boss is not a complete ogre, and offered up solutions other than overtime to get things back on track. (It helps that she's being measured on keeping week to week consistency. who knew?)

3) Temper your innate optimism and supreme confidence in your god-like technical skills. Leave room for a little self-doubt. Chances are your manager has seen all kinds of ways that projects fail: technical, political, financial. Chances are also that your manager is where they are because they've survived those various disasters, and earned the credit for saving what they can. Ask your boss for war stories. Turns out while technology moves forward, the fundamental problems facing software development haven't. Your boss has likely moved through all kinds of fads, vaporware, and religions. Likely, they've survived by paying attention to some eternal truths, and not limited their career to the buzzword of the day.

Thoughts on Furniture Police...

Yesterday, Neil Ford presented "On the lam from from the furniture police" as keynote to Atlanta DevNexus conference.   In it he commented on all the ways that corporate workplaces inhibit 'knowledge worker' productivity.   One of key points that stuck in my head were his examples of how far companies will go to maintain 'standards' no matter how ridiculous the enforcement of standards becomes.

The talk brought to mind a few quotes from Peter F Drucker:

"Efficiency is doing things right, effectiveness is doing the right things."

"There is nothing so useless as doing efficiently that which should not be done at all."

"What gets measured gets managed."  

Corporations can measure and therefore manage the tangible - IDE software, Source Repository, types of UML diagrams used in code documentation.  Good developers do appear to share some common philosophies for example, DRY, separation of concerns, testability.  But what inevitably happens when companies try to measure these things?  We lose the spirit of the art in order to adhere to the letter of the law defined by an inflexible, but measurable, standard. 

You know good code when you see it.  You know a good developer when you work with them.   A system of peer review is the only reliable way to measure the true effectiveness of knowledge workers.  It is also the only way to provide meaningful feedback that drives increased effectiveness.  

How do you foster a culture that standardizes effective choice of tools for problem to be solved?   Does coding style at your workplace measure reusability and extensibility or are you simply reformatting  files to ensure 'proper' parenthesis placement?   Who gives the measure of your work?  Is it your manager or your peers?  Do you find yourself going to ridiculous lengths to meet those expectations?

Blue Angels for Corporate America?

A documentary on the Blue Angels, the Navy's ace demo flight team, got me to thinking about how dismally most corporations manage technical talent and imagine how things might be different if the average company ran a team modeled after the Blue Angels.

1. Anyone can apply to become a Blue Angel, but the existing team has complete say in who joins.  It's clear that they pick the best of the best and require not only ace skills but also the ability to represent the team and the Navy in the best light.
2. You serve only three years as a member of the team.  One year to learn your stuff.  One year to do it best.  The last year is dedicated to training your replacement.
3. After your stint, you return to real life.  This opens spots for the next crop of team members and ensures that everything you've learned about being the best is carried back out to the Navy at large to help the whole organization improve.

I can only imagine the effects of running such a team might have on the average corporate IT organization.

First, companies might finally be able to maintain highly motivated and skilled people.  Too often it's the case that  your best and brightest get bored and go looking for a new job just at the point where they're ready to become truly useful to the company.   Imagine instead this energy and talent earning a place on the Blue Angel team and getting assigned tasks that will really stretch and challenge them to take it up another level.  Imagine too, having a real alternative besides promotion to management to reward your technical stars.

Usually Managers let go their star employees only grudgingly knowing there's a good chance that it will be a long while before they find somebody to replace their ace.   But imagine instead, that as you let go of your favorite talent, you get in return an Ace.  Better yet, and ace who's now a trained expert on the latest and greatest trends approved for use in the business.  You get a direct liaison to the powers that be, someone who's got the training and knowledge to actually improve all your team members' productivity.  Someone who's ready to help ensure your team understands and adheres to the proven best practices...

Imagine being a CIO knowing that there is an effective and constant flow of ideas among all your disparate teams.  That best practices are more than just empty bits on a sharepoint site that nobody reads and most teams have no way of understanding let alone adopting.   Instead, you have evangelists of excellence cycling throughout your company,  leaders with the hands on knowledge and skills ready to rapidly deploy key changes to any team in need.  And don't forget you also the Blue Angels team itself, full of great minds ready to tackle any thorny problem that may arise.

And lastly, imagine just being a cog in the wheels at such a company.  Maybe you don't feel up to putting in the extra effort to become a Blue Angel.  Maybe you have kids you want to watch grow up or you're writing your novel.  But imagine how much better to be a cog in a company where the hotshots really do get their time to shine and so don't just sit around kvetching about how backwards and stupid everybody else is.  Imagine that you had actual working code examples to follow when asked to adopt a new standard or better yet real automation tools and robust frameworks to make the job easier.

Seems like a win-win all around,  does any place like this exist in the IT world?  What would it really take to run a shop like this?