Tuesday, August 09, 2005

I’ve Been Moved

I’ve been moved!

Back in 1996, when I finished my first 3 month period of contract labor at IBM, I was renewed for one year and in a team reshuffle moved to a better desk where I could work as a more integral part of the team. We didn’t have partitions or cubes or offices, we had an open space with desks. The whole team, more or less, worked in this space which was partitioned from other teams. I got to sit at an end desk. The previous occupant, a developer called Julie, welcomed me to the “slap head seat” so called because anyone on the team might be tempted to slap your head as they walked past. [No head slapping actually took place but the thought surely crossed a few minds.] She then added, “Welcome, to IBM. You are official now, you have been moved.”

So it was a deja vu for me when I joined Microsoft and was told the very same thing. And sure enough I was moved from building 41 to 25 within 3 months of joining the company.

Well today on my one year anniversary, I have once again been moved. This time not just my physical presence but my group, the MSF team (Randy Miller and me), has been re-orged under Julia Liuson, the product unit manager, for Enterprise Framework and Tools within Visual Studio, a.k.a the Team Architect team. This means that I now sit next to Keith Short and Jack Greenfield, Stuart Kent, and Steve Cooke are now my colleagues.

This post is bound to drive questions about what this means for MSF and DSLs and Software Factories. In the short term - nothing, no change to anything that has been announced. The re-org came about when Keith Rowe moved on to another job in the Mobile and Embedded Devices group. It’s as simple as that. So put your conspiracy theories away.

What does it mean in future for say MSF v5.0? Well that is anyone’s guess because we haven’t talked about it yet.

Inside-inside, Inside, Outside

I’ve mentioned before that Microsoft hires for intelligence but values experience. One way of measuring individual value in the Microsoft tribe is through the allocation of office space. Unlike many companies where position of an office is associated with position in the hierarchy and power, at Microsoft it is associated with longevity of service. So you can have a corner window office even if you are a programmer, or a user experience designer, but you need to have about 18 years of service.

So outside offices go to long service personnel. Offices on the inside of a corridor with no windows tend to go to newer hires like me. Meanwhile, offices on inner corridors where neither side has any windows - an inside-inside office - tend to be used as meeting rooms, labs or are reserved for temporary staff who have to share perhaps with one or two others.

So individual value in the tribe is communicated by the location of your office. Not by the color of your badge, or by the incantations woven into your email alias. This in my opinion is a far better way of communicating value, respect and trust in a healthy way than the more conventional tactics I described yesterday.

Monday, August 08, 2005

HR Myth #4: Tribal Markings

Why do HR departments insist on issuing different colored badges to contingent contract labor and vendors on long term contracts? It’s clearly tribal. It clearly marks the individual as somehow less worthy. Why? The assumption is that temporary staff are less trustworthy. Hmmm. This feels that it belongs in medieval Japan’s early Edo period where Samurai without a master - ronin - were treated with suspicion.

The ronin’s loyalty was to himself as he had no warlord. So to is the geek for hire contract laborer - loyal to him or herself and his or her career development. They will ply their trade wherever makes the most economic sense. But does anyone really think that a full time employee is any more loyal to their employer than to their own career and its development? In the 21st Century? Really? In medieval Japan loyalty to a group and its master were built into the religion as a core Confucian value. We still see that today in modern Japan with employees still very loyal to their employers and in return they expect a lifetime of employment. But in America? Really?

When I worked at IBM’s PC Company in the mid-1990’s contractors like me had a yellow stripe on their badges. We also suffered the indignity of a temporary email address. Mine if I recall correctly was .(JavaScript must be enabled to view this email address). Furthermore, as I was an untrustworthy ronin, I was restricted under IBM’s strict waterfall process (a relic of the Fred Brooks’ days - evidently no one at IBM had bothered to read Fred’s retraction) to performing only coding and testing tasks, analysis and design were reserved only for full time employees. Hence, I had to code designs given to me by a full timer - an IBMer.

My current employer, Microsoft too makes temporary staff wear a variety of different colored badges, segregating them in a strict caste system. And they get special aliases too. It just doesn’t make sense to me. I can see no reason why a temporary knowledge worker should be treated as untrustworthy. They have a loyalty to their career and their development relies on them carrying good references and respect from one job to another. The temporary staff has just as much incentive or perhaps more, to do a good job than a full time employee.

So might their be other reasons why HR departments the world over persist in this behavior? After all it’s not just IBM and Microsoft that are doing this! Well, maybe! Temporary staff are often more highly paid but do not receive benefits such as health care. Sometimes there is resentment at the higher pay rate. At IBM contractors were expected to pick up the bill if the team went out drinking together in the evening. This wasn’t too much of a burden if the group had several contractors who could share the cost. I’ve also seen managers become irrational when dealing with temporary staff who are doing a good job. They cannot get away from the fact that the temporary worker makes more money than them. On several occasions I have seen managers eliminate a high performing temporary worker by not renewing their contract, only to suffer a delay in a schedule or an outright project failure after the talent has gone. And all this to make themselves feel better. As a line manager, I had several temporary staff making ridiculous money during the boom years of telecom. But I simply had to put it out of my mind. They were doing a job that I couldn’t easily backfill. Their pay rate was determined by the market. Meanwhile, I got my projects delivered on time.

So perhaps the segregating colored badge is all about making people feel better or superior? Humiliate the ronin! If this is true, am I the only person who looks at history and finds this idea discomforting?

When I left IBM to go to Singapore and set out on my agile journey with FDD, I offered, despite my temporary status, and despite the fact that I had fully met my contractual obligations, to find them a replacement for my position. I recommended a college buddy. He still holds that job today - many years later - and he is still temporary. About two years ago, I noticed that his email address had changed to .(JavaScript must be enabled to view this email address). I assumed that he had gone full time. I learned later that he hadn’t. Instead IBM had ended the humiliating practice of giving temporary staff ridiculous email aliases. So kudos to them. A step in the right direction. Software development is a team sport and productivity is directly related to team morale and the ability of a team to work together effectively. We know that agile software development rides on trust between team members. Eliminating division and artificial barriers to trust like colored badges and funky email aliases is surely a driver of higher productivity.

Sunday, August 07, 2005

Alma Mater Voted Best in Britain

I’ve been waiting to blog this until my buddy, the horseman of the telepocalypse, got back from vacation. My old college, the University of Strathcylde was recently voted the best in Britain as reported by the BBC [via Duncan’s Jotter]. Well, congratulations! Apparently, Oxford only came second. Read it and weep, Mr Geddes!

Tribal? Moi?

Monday, August 01, 2005

Agile Program Management

One criticism of my book was the omission of a chapter on multi-project or program management. At the time, I didn’t think I knew how to write that chapter. Later I made amends with a paper on use of critical chain multi-project management based on my experience at 4thpass/Motorola using the user experience group as the synchronizing drum or constraint.

However, on reflection, I did know how to write a chapter on agile program management because Sprintpcs.com’s PMO (program management office) had largely solved the problem but I didn’t recognize it.

Back in the day, I wasn’t a regular attendee at the PMO meetings. I typically delegated it to one of my staff. That’s my excuse for failing to recognize how well the PMO team had done to create a truly agile opportunity for multi-project coordination and resource contention. They booked a large meeting room for 2 hours on a Wednesday evening. I can’t recall the precise time but 4pm to 6pm jumps to mind and occasionally the meeting would run until 7pm. Each team in the business unit and the business owners - senior managers in the marketing department - would show up. The development groups would have the dev manager or team leads and from the project management side either the GPM or some of the PM’s. Other functional groups such as user experience or testing would send a representative who had resource management as part of their role.

The PMO would bring a very large wall chart size plot of the master schedule for the business unit. They would lay it out on the meeting table. This was a very large plot - perhaps 12’ long by 5’ wide. The attendees would then simply swarm over it and mark it up with new projects, changes to existing plans and so forth. As they were doing so, others would see the changes which related to them and start to debate them. Small groups would form to resolve or discuss conflicts. This was a self-organizing meeting. There was no formality to it. Multiple groups would form simultaneously. Individuals would move around from one group to another. It looked and felt like a free-for-all. It was noisy. It was uncontrolled. It was highly productive. People would come and go - if they had no further issues they might leave early. Others would turn up late, delayed by other commitments. Towards the end of the time period, the manager of the PMO (there were actually two of them sharing the responsibility - Connie and Keith) would call the meeting to order and summarize the changes made to the master schedule and ask for a consensus from those still in attendance. The marked up schedule would be taken away and within a day or two the PMO would publish a new electronic copy along with the minutes of the meeting. This process would be repeated every week.

Issues raised from the meeting - such as insufficient resources, or resource conflicts which could not be locally resolved, would be taken by the PMO. The manager would then raise them with colleagues at the managers staff meeting with their director or VP. Some might be serious enough to be escalated to the monthly operations review with executive leadership. And provides me with a nice segue into my next posting about aspects of Sprintpcs.com that were done right - the operations review. Until then…