Do Developers make good Managers?

Well, turns out someone took note of my last post. (They did, however, refrain from posting a comment : ) One of my colleagues hinted that my definition of Leadership was... incomplete.

Here's the deal, I wanted to illuminate some very specific issues arising out of the concept of Leadership (with capital el) in Software Development Teams. As TDM & TRL indicated– in small groups of skilled professionals, it's hard to put one person in complete control without creating sociological issues. Added to all the other little frustrations of corporate life, these can very easily take you over the edge. Especially these, as team sociology tends to get VERY personal.

I'm guessing that adding the Leader role to teams is a direct consequence of Management's excessive need to delegate out the Manager role, aka Turning Developers into Baby-sitters. Management just seems to want a 'guy on the inside'! But, how wise is it to pick an insider (someone who's already inside the team) and switch roles?

What I'm really trying to get at is that (IMHO) Developers (REAL, HARDCORE developers) don't make good Managers... or Leaders... or... whatever you want to call that abomination of delegation! I prefer Field Manager in specific and Manager in general.

In creative collaborations, leadership is always situational. Each aspect of the problem invites the creative excellence of one or more team members. I don't believe any one person can 'drive' a sizeable effort from inception to conclusion alone. The Skill Sets (sociological as well as operational) required for these two roles are just too diverse for one person to cover! They have different Objectives; Their Interests and Incentives are usually in conflict... I mean how can you
put an individual in this situation? It's almost HARASSMENT!!!

Parting thoughts:

Managers give you a goal and let you figure out how to achieve it, monitoring along the way.

Leaders give you a direction to achieve your goals, walking along the way.

Definitions so far

Just a list of concept posts I have written so far, will try and keep it updated.

• Quality
• Expertise
• Coding
• Programming
• Leadership

Endnote: Why definitions are important.

Defining Leadership

From the Oxford English Dictionary–

[to] lead (v): conduct, guide, esp by going in front; direct movements, actions or opinions of

leader (n): person followed by others

So, let's go over that one more time.

person followed by others... directing their movements, actions or opinions

The whole thing instantly conjures up images of a Seargent carrying his platoon through the tall grass or a Captain marching his company into battle. Respect, Trust,... Glory!!!
So what's wrong with that? Nothing, except that contemporary corporate culture seems to be the only place where the word Leader immediately follows the word Team. "So,” you ask, "what's wrong with a team having a leader? Most normal thing in the world!" Or so you think...!
If you look at the above analogies colsely, you will notice that neither a platoon, nor a company is a team. They are hierarchical structures built into the military chain of command!
A Team is...

... made up of peers, equals that function as equals.

Peopleware
By Tom DeMarco & Timothy Lister

Even the military accepted this when they came up with the idea of special-purpose (ops) teams. Such teams comprise specialists who set aside their ranks to funnel their respective skills into attaining a single, common goal. Teams in our industry have no reason to be an exception.

For all the deference paid to the concept of leadership (a cult word in our [software] industry), it just doesn't have much place here.

Peopleware
By Tom DeMarco & Timothy Lister

Managers/Leaders are never part of the team for the simple reason that they can never be peers; another point sufficiently emphasized by TDM & TRL.
Besides, we're talking creative people here. Creative people are inherently Intelligent! They don't need to be led around like some pack, and they sure as hell don't want to be!
What's even more amazing is the kind of stuff that gets passed off as Leadership qualities, things like:

• Charm (:P)
• Persuasiveness (:S)
• Getting things done (!)
• Maintaining the status quo (:o)
• Assuming authority (out of the blue!)

Parting thought: With all the talk of situational leadership, we seem to want the same people to pick up the flag in all the situations!

When do YOU look at the user?

Think about it. You're putting in this cool new feature, it's going to save the users a lot of time, give them a ton of functionality and, hence, save them a truckload of money. AWESOME!

So, first we nail down the functionality... right? WRONG!!! First you figure out how the users will exercise the new functionality, because that's what you're ultimately giving them- a new user experience. a new interaction mode.

Unless you make sure the user is going to find the new interaction intuitive, any new functionality, however efficient, is a burden. If you make the user jump through a lot of hoops just to do his everyday job, your new feature SUCKS!!!

I actually experienced this first hand recently. We enhanced the TIL Regulation dashboard in an LOS to allow the users to monitor loans as they get dangerously close to the limits and notify them once they fall over. I actually reordered all the controls on the screen just to keep logically related data together. The new design was so intuitive that the Business Analyst approved it in a heartbeat and sent out an appreciation note! (Pat myself on the back)

At the same time, another team member was working on the screen used to configure the regulation limits. Man did they miss the bus! They wrote up the whole screen, new popups et al, and then sat around thinking, 'What if the user checks this but doesn't fill in that...?' WHOA! When he asked me for an opinion, I said that the new validations he was thinking of were cool, but, '...wouldn't it have been much more logical to have thought about this BEFORE you built the whole thing?' Nevertheless, he ended up putting in the validations (in this screen and a few others!). Rework can be such a productivity killer!

The user always comes first. Kathy Sierra agrees in her blog post captioned Ignore the competition.

Turning Developers into Baby-sitters!!!

That's it! I've had it with management covering up their incompetence by 'delegating' work to developers. Enough is enough of this garbage. Ju-JUST BACK OFF... Immediately!!! And do your own work, YOURSELF!!!
Isn't it really annoying when you have to fill up the same data into five different systems (each designed for a specific objective), then wonder if you filled it right everywhere, then draw up a reconciliation sheet because SQA doesn't see the same data as Finance as HR as ...!!! AAARGH!!!
God! Why can't these managers just figure out exactly what data they need and figure out a single source that they can all extract it from. Then we wouldn't have to wast our time filling five different datastores, and reconciling the differences!
Joel Spolsky got it right when he said

...the MBA-types in charge think that coding is a support function, basically a fancy form of typing.

http://www.fogcreek.com/About.html

I'm convinced that most people think about software companies in an upside-down way.

Converting Capital Into Software That Works
By Joel Spolsky

Lessons Learnt

I haven't exactly been soul searching, but here's my list...

This entry is waaaay overdue! 5 months SUCKS!!! I definitely need to post more often.

Fight the PROBLEM, not the PROJECT

Never compromise

Always understand what you're getting into

Don't hold on too hard

Assumption is the Mother of all F**k-ups

I am a Maven looking for a Connector

Don't bite more than you can chew

Who da Man ?!?

I read a blog comment on our corporate intranet recently that said,

Modern banking isn't dependent upon IT, modern banking is IT.

Now there's a repulsive thought! How does anyone get off suggesting that IT could, or already has, taken over or replaced the Business it services? A specific business process implementation does not subsume the business function that it defines. Business Funtions (such as purchase, sale, accept deposit or lend) are independent of and supercede the means applied to realize them.

IT is not Business! IT doesn't run Business; People run Business. People are defined by their Actions; and Actions are channelized and automated using IT.

IT is merely a business facilitator/accelerator. What we really need to be focussing on is figuring out ways to shift from the Facilitator role to that of an Accelerator. That's where the real business propositions lie.

Basically, we ain't NEVER da Man!
We ain't NEVER GONNA BE da Man!!

So let's just get used to playing second fiddle to Business. Besides, why should IT be anything but IT?

We are Who We are.

Coding vs Programming

Coding is about how you should write,
Programming is about how you SHOULDN'T!

Coding as about the Language and Syntax,
Programming is about the Paradigm, the Thought Process

Coding is represented by the 'Writing' Metaphor,
Programming is epitomized by the 'Construction' metaphor

Coding defines the Solution,
Programming defines the Problem too!

Coding creates the Implementation,
Programming creates the Interface

Coding is about "Getting it done...",
Programming is about "Getting to know it!"

Coding gets you Paid,
Programming makes you Satisfied.

Coding is what we HAVE to do,
Programming is what we SHOULD be doing!