Blog
: January 2005
Monday, January 31, 2005
Building Microsoft to Last
I wasn’t surprised by the theme in this interview with Steve Ballmer. Recently posters proclaiming Good to Great have appeared around the campus. The top management are clearly Jim Collins fans. They’ve constructed the company’s new vision statement with its mission, values, and core tenets. The new mission is to help companies and people around the world to realize their potential. No difficulty then for me in identifying my day-to-day work with the company’s mission. My job is to help software developers and their management around the world better realize their potential by building better software, faster, and cheaper. For me, it is as Steve says, “galvanizing”. Unlike the tone in the article, I don’t see it as a problem. It’s part of the reason I joined Microsoft.
It’s not surprising that the founders of Microsoft have turned their attention to leaving a long term legacy. It’ll be interesting for all of us to follow this over the next twenty years. Is it possible to imagine a Microsoft without Bill and Steve? I’d love to speculate but I’ve decided to keep those thoughts to myself.
Posted by David on 01/31 at 11:45 AM
(0)
Trackbacks •
Permalink
Sunday, January 30, 2005
Some Military Lessons
As promised yesterday, another example of bad leadership, this time from the most recent episode of The Apprentice (now in the third season). In this episode, Verna walked out. Yip! She packed her bags and walked off early on the 2nd morning. It required Carolyn to show what a true leader would do under these circumstances. She got in her car and went to look for her.
There’s a lesson that Michael could have learned from a former military leader like last season’s winner, Kelly - you never leave anyone behind. Where was Michael after Verna disappeared?
Something which led to Verna’s departure was her lack of sleep. In fact, both teams seemed to pass on sleeping at all in order to maximize their input. The leaders were managing hours of effort rather than effectiveness. Something else military people understand is that some sleep is essential. When a platoon sleeps, two soldiers keep watch. After an hour or two, they wake colleagues and swap. In a critical situation, more stay awake, but the platoon commander always ensures that every team member gets a couple of hours of sleep. We seldom, if ever see this on The Apprentice.
And finally, a theme which comes up again and again throughout the three seasons - food. Every good military manager knows that an army marches on its stomach. It’s a key part of management and leadership to insure that workers are well fed. If a manager ask staff to work overtime, then the manager shows up and makes the tea, fetches the pizza or whatever it takes to keep people productive. Again and again on this show, we see project managers neglect to insure that their team get fed.
These are such basic mistakes. Every manager should adopt the three golden rules we can learn from this…
- No one gets left behind. It’s very bad for morale. When the team sees that management will abandon a weak member it makes them feel insecure. Deming said that we should “drive out fear”. You can’t eliminate fear if you show that you’ll leave someone behind.
- Everyone gets some sleep. People start to make mistakes very quickly when they are tired. Mistakes cause trouble and agitate others. It becomes a vicious cycle as tired people irritate each other more and more. More mistakes get made. More time is wasted. Focus on the task is lost.
- Everyone gets to eat a sufficiency. Without food people don’t think straight or act rationally. Mistakes get made. This irritates others on the team and undermines trust amongst the team members. They see others at their worst and they react to it. A team can fracture into a group of individuals because trust breaks down when mistakes are made due to basic elements at the top of Mazlov’s hierarchy.
Posted by David on 01/30 at 04:04 AM
(0)
Trackbacks •
Permalink
Saturday, January 29, 2005
Emotional Elizabeth
Today’s blog entry was inspired by my wife, whilst we watched an episode of The Apprentice last season. Elizabeth was having yet another crying scene and my wife blurted out, “Ahhh, Elizabeth is just such a woman!” I almost choked on my fruit tea. So Elizabeth was showing her emotional and sensitive side - I guess these are attributes more commonly found in women. Of all the people I know, perhaps only my home-maker wife can get away with a comment like this. It’s certainly not something an American manager can explicitly express in the workplace. And it made me think. Although I don’t see such sentiment expressed explicitly, I do see managers complain about behavior in men and women which could be described as merely “human.” Just as in the show with Elizabeth, these expressions of humanity are often looked upon negatively - as though it is a failing. So to pick on the specific example - do we really want all women in the knowledge workplace to be hard, unemotional and thick skinned? Do we want them to be able to take everything in their stride - all business, totally focused. Personally, I find this idea a bit frightening.
People come in a whole range of varieties and managers have to understand that. Some don’t cope well with change, or uncertainty, or lack of direction. People feel pressure in different ways - worry about things which often aren’t worth worrying about. It’s the manager’s job to understand and assign them roles and responsibilities appropriately. Furthermore, it’s the manager’s responsibility to control chaos, bring stability to an organization and to act rationally in the face of variation - to understand what is normal variation and what represents exceptional circumstances that require intervention. Stability helps staff to function better regardless of their emotional or cultural disposition. In the event that one of the team does have a breakdown, it’s the manager’s job to fix it.
The implication that someone “can’t handle it” and there is “no room on the team for someone who can’t pull themselves together” is really a manager treating the symptom - taking the easy way out. It’s easier to say, “I don’t want this person around.” The harder job is to look for the root cause and deal with that. Take away the circumstances which caused the emotional breakdown so that it doesn’t happen again. It was a lack of leadership which failed Elizabeth and the nature of this game show which has one person eliminated each week didn’t help. Elizabeth identified as a weak link quickly became an outcast - someone who could be sacrificed for the survival of the others. This made the situation worse. It became a vicious cycle as she felt more and more isolated.
This is where a show like The Apprentice helps us all by highlighting some bad examples of poor leadership. More tomorrow…
Posted by David on 01/29 at 04:04 AM
(0)
Trackbacks •
Permalink
Tuesday, January 18, 2005
Defect Ratio > 1.0
In manufacturing quality assurance, they measure something called defects per opportunity. It is always a number less than 1. For rivet you pop, it’s either a good rivet or its not. Terms like Six Sigma meaning less than 4 defects per million opportunities are born out of this paradigm. However, in software we have a bigger problem. In software, defects per opportunity can be greater than one. Even using the SEI’s measurement of defects per line of code, it is possible to insert more than one defect per line - unless you are working in machine code.
It’s for this reason that reducing defects, eliminating the opportunity for them, pays such a high dividend in software development. In some of my recent presentations, I talk about reducing defect rates from 3:1 to 2:100 and I’m not making this data up. It is real data from real projects. I did see a team inserting around 3 defects per feature and another team sitting on the same floor deliver a 7 week iteration with as few as 2 escaped defects per 100 Features. This represents a staggering improvement. Capers Jones has data that suggests the poorest of the poor insert about 5 defects per function point. If we take this as equivalent of 1:1 in manufacturing then 2 per 100 is equivalent to 3 sigma or 3 per thousand in manufacturing.
Now these numbers are still nowhere close to some other human activities such as landing airliners - around 7 sigma. However, considering software development is design work where no two features (or function points) are really the same, then it’s remarkably good.
Now let’s assume that a QA department was as good at catching escaped defects through integration, system and product testing, then we could assume that only 2 escaped defects per hundred would actually escape to the customer. That’s only 4 for every 10,000 features. Using my manufacturing equivalency its about 49 per million or considerably better than 5 sigma.
Hmmm…
Posted by David on 01/18 at 01:25 PM
(0)
Trackbacks •
Permalink
Monday, January 17, 2005
Variation in Software Engineering
Finally, my slides from my presentation at the Seattle Chapter of the American Society for Quality from last September.
In this paper, I start to tie together several themes around the theory of variation. This is the beginnings of a Theory of Profound Knowledge approach to managing software engineering development and quality. Like most of my presentations, the slides are just talking points. You need to be in the room to hear the words. There isn’t a paper for this presentation.
[Download Variation in Software Engineering 580KBytes in PDF]
Posted by David on 01/17 at 01:59 PM
(0)
Trackbacks •
Permalink