24 February 04 - 17:02Career advice to a young graduate engineer

There's a tragedy going on in our industry; at least in my country, where I was deeply saddened by a recent post to the newsgroup fr.comp.developpement.

This was a post by a recent graduate of a prestigious engineering school, asking if he "really needed to have development experience before moving on to project management". It seems that the only job offers this person is finding are for analyst or engineer positions, and he's concerned that he will "waste [his] time mucking around with code for a year or more" before moving on to a position "more in line with [his] true skill and ambitions". That graduates at Master's level or graduates of "lesser" engineering schools should be required to prove their mettle is understandable, he added, but he felt it was "a waste" in regard to his own education.

I'm not qualified to comment on the educational systems of other countries, but this kind of declaration confirms what I've learned from personal observation: so many people who train in engineering come out of school not wanting to be engineers, but managers of engineers. I've lost count of how often I've heard "I don't plan to stay in development, I'm really interested in being a project manager". I don't know what's going on in the schools here, but I can only call it a tragedy that so many people are misled in their career choices.

I had the following advice to give to this tragically misled young graduate:

What is it about project management that attracts you ? Of the various activities that you have experienced in the course of your education, what are those which leave you tired but happy and proud of what you've accomplished, and what are those which leave you bored, or frustrated, or angry, or depressed ?

Discover the work-related activities that you derive value from, and strive to have your responsibilities in areas related to these activities. Request from your management that you be assigned to functions which match these choices; to discover those, look around you and spot the people whose job requires that they perform the kind of activity you prefer. You might well not end up in a position called "Project Manager", but I guarantee that you will be satisfied with your career choices.

Do not forget that, over time, these preferences will change. I know many people (myself included) who started out happiest when they were solving thorny technical problems, and now enjoy a lot more helping others solve thorny technical problems. Developer to project manager is but one of the many paths along which such a change might happen, and it is but one of the changes that a person may undergo. Review your work preferences periodically, and adjust your career choices in consequence.

Also, be aware that characterizing software development as a "waste of time" and "mucking around with code", in a public forum read by many software professionals local to your country... may not be the smartest career move you will ever make.

- Management - six comments / No trackbacks - § ¶

19 February 04 - 21:18The Buridan Project

Once upon a time a donkey was dozing in a field, growing hungry. "This bunch of thistle shoots over there looks quite nice. I'll wander in that direction and have myself a nice meal." The donkey made to stand up, but a thought struck him.

"From this vantage point, that looks like a meager bunch. I'm liable to be still hungry when I'm done with it. Here's another, a few steps to the left - I'll wander over there first, and take the two in one go." At the thought of this exertion, the donkey's hunger grew, and he was less sure of his plans. "I just need to spot a third small bunch, not too far off; or it could be a bigger bunch, worth taking a few more steps".

By then another thought struck the donkey. "Oh, I remember this story. If I don't move my hind quarters soon, I'll end up be starving from indecision. My donkey brains are just too small for all these concerns anyway." He got up, had a nice meal of thistle, and promptly settled down to sleep again.

I once knew a project which had one person spend six month gathering requirements, by which time the customer had eventually settled on an off-the-shelf package. A colleague of mine recently told me a story of a person tasked with procurement who spent a full-time month trying to cut costs on a vendor proposal by five man-days.

This tale has two morals : the first is that the things we do before we can start a project are part of that project, even when it's not officially started; sometimes the costs accrued to a project have killed it before it starts, maybe even before we know there is a project.

The second is that donkeys have it easy - it must be nice not to be riddled by too large a brain. ;)

- Management - one comment / No trackbacks - § ¶

11 February 04 - 21:27The roles you take on

"Try being a manager yourself before you go too far off into your 'they're all idiots' zone." That was Jim's feedback on an earlier note of mine, and not the first time I've had this sort of feedback.

I've had "manager" titles pinned on me, which certainly is different from actually being a manager. I'm also a parent, which is somewhat like being a manager. There too, there are occasions when you can do nothing right.

When you have the "manager" title pinned on you, you also inherit, by way of culture, a repertoire of behaviors, most of which are idiotic. For instance, you might inherit the model that a manager's job is to make decisions; to be an arbiter. In many cases, this is actually the case, and actually a useful function you can perform for the business; but far too often, the model is implicitly held, never questioned, and inappropriately applied to all sorts of situations.

Unlearning these "model manager" behaviours is the hard part of that job. So in that sense, managers are all idiots; and subordinates are all incompetent in that same sense. The "manager/subordinate" structure carries with it these assumptions. So do "parent/child", "husband/wife", etc. come with theirs.

If you are lucky, you will have at some point the opportunity to actually train for the kind of situations you will encounter as a manager (or a subordinate, or a parent, etc.). In many of these roles "training" is quite unlike the sort of formal training we are familiar with, but it takes place anyway.

By training, I mean a context in which it is safe to experiment, and discard what the model says you "should" do, and come up with behaviours that a) fit the situation at hand, b) make effective use of your individual skills and abilities, and c) are considerate of the other persons involved in the situation.

When we pull that off, we're definitely not idiots. The more we build up our repertoire of behaviours that fit these criteria, the smarter we become. And the smarter we are, the farther away from stereotype roles such as "manager".

- Management - three comments / No trackbacks - § ¶

07 February 04 - 15:41Someone has to be the boss

I'll take complete responsibility for anyone having missed the point of the previous entry. Stefan thought I was "pushing it" in asserting that a team does not remember. I will stand by that: a team does not have a singular memory. You can't remember what your teammates did yesterday, nor they remember what you did.

What a team does have is memories - but the tough problem is not to remember things; it is to recall them. The problem is not storing information relevant to the project, such as Bob's suspicion that this gnarly bit of code might have a nasty bug, but accessing the information: if you had been in Bob's head when that suspicion crossed it, you might have been less enthusiastic about shipping the latest release to the customer site. That is why teams have meetings - to exchange information that might be relevant. It's also why frequent meetings work better than infrequent ones - when timely access to information that is in other people's heads can be critical to project outcomes.

Another thing a team doesn't have is a singular personality. As with Memento, we can stretch our imagination and envision what it might feel like not to have a personality, by reading novels or seeing movies about people afflicted with multiple-personality disorders (MPD). These people's lives are a mess, of course; that's what makes the stories interesting. You can't take a decision and actually stick to it, since another personality will soon be taking over.

Instead of memories, teams have meetings. Instead of personalities, teams have managers, or architects. There is one person who is "the brain" of the operation, integrates the various perspectives, and ensures that the decisions taken are consistent. Fred Brooks argued that for software projects, this was the only way to maintain the "conceptual integrity" of the software that got built.

We believe that "someone has to be the boss" when teams are concerned, because we believe it about ourselves. But what if that wasn't true ?

That theory of Dennett's which I cited previously strongly undermines the notion that our own personality and consciousness are really singular; Dennet calls consciousness a "user illusion", saying that we perceive the world as a serial, ordered, continuous stream of events because that's a workable design, not because our minds actually work that way - the mind's nature is actually parallel, modular, messy and contentious, just like a team of individuals.

There is a school of thought that if conditions are right, teams actually work better when there isn't a boss; they're called "self-directed work teams", or self-organized teams in the Agile jargon. With teams where "someone has to be the boss", or the single brain that directs all the activity, you also have to suppress the motivations of the individuals, or at least provide enough incentives to ensure that they completely align with the bosses' motivations, and not work against them. Robert Austin's book "Measuring and Managing Performance in Organizations" does a great job of illustrating the problems with that strategy.

- Management - No comments / No trackbacks - § ¶

06 February 04 - 15:46Least surprise, or even no surprise

I like Johanna's take on the principle of least surprise. It could serve as one more item in Esther's list of "etiquette for managers". A courteous manager will not spring surprises on the people she manages. If she has information relevant to these people's jobs, she shares it as she comes by it.

I've known managers who hoarded information "in the best interests" of workers, saving it for inappropriate moments like status meetings. ("Oh, one more item; I met with the board early last week, and they told me they would pull funding unless we could move ship date two weeks earlier.") I'm not sure how I'd choose between an abusive manager or a secretive one.

- Management - No comments / No trackbacks - § ¶

05 February 04 - 22:32How do you know who you are ?

In the movie Memento, Leonard Shelby suffers from a total loss of short-term memory. He remembers his previous life up to the accident which caused that condition, but nothing beyond that - and since then he is unable to retain any memory of what happens to him.

Shelby has a project: track down and kill his wife's murderer. No brain that fragmented could cope with a definite, long-term project, you might think. How would one keep track of intermediate sub-goals, make plans for various contingencies, assess an overall situation ? But Shelby does cope; what he does is write notes to himself - on scraps of papers and on notebooks, on the back of Polaroid snapshots and beer mats. The most important notes he tattoos on his own body. With these aids, Shelby pulls off splendid project management in spite of an overwhelming handicap.

To Shelby, memory is overrated; documentation is crucial. "Memory's unreliable. No no no, really. Memory's not perfect; it's not even that good. [...] Look, memory can change the shape of a room; it can change the color of a car. And memories can be distorted. They're just an interpretation, they're not a record, and they're irrelevant if you have the facts." The continuity of Shelby's existence depends on constant interpretation and re-interpretation as new facts come in.

A project team is a creature much like Leonard Shelby - one with no continuity, no unicity of consciousness, but still with a definite goal to strive for. A project team cannot remember. That is why it must do two things: first, constantly leave mementoes to itself in the form of project artifacts (documentation, code, diagrams, and so forth). But more importantly, it must draw all these together into a coherent whole at regular intervals by telling itself the story of the project.

According to philosopher Daniel Dennett's theory of consciousness, what he calls the multiple-drafts model, this is also true of an individual - in spite of the strong impression we have that our consciousness is a single integrated whole. That's actually an illusion - which we only maintain by constantly telling and retelling ourselves our own stories.

- Private Life Of The Brain - three comments / No trackbacks - § ¶