Working Up

by Dwayne Phillips

Most meetings are a waste of time and most meetings are conducted by educated, intelligent, and accomplished people. These contradictions fit when I realized that the people conducting the worthless meetings simply didn’t have the energy to make them worthwhile. I needed another tact besides sighing and suffering.

I have sat in a lot of meetings in my career. Most of the meetings were bad. There was no agenda, there was no point, there was no organization, and there was no idea of how much it cost for a bunch of people to sit in chairs and accomplish nothing.

What frustrated me was that the people leading these worthless meetings were smart people. They were educated, intelligent, and accomplished. Yet, week after week, we had these awful meetings. Nothing ever changed. How in the world could such smart people allow such stupid behavior to continue?

Such questions led to long sighs from me. Then it hit me – I was sighing. I was gassed, no energy. That was it. These smart people had no energy to fix their meetings. They spent their energy on everything else. That is how they had become accomplished people. They had put their energy into accomplishing things that their superiors noticed and rewarded. Internal meetings were not noticed by superiors; internal meetings were only suffered by subordinates like me.

Try as I might, I could never persuade these managers to fix their meetings. The meetings simply were not important enough to fix; bettering the day of subordinates didn’t merit a piece of energy as energy was precious and devoted to only a certain class of task.

Please take note when something awful continues. There is no urgency in correcting it; there is no energy to change it, and there is no reward from improving it. Try what you can to improve it from your side (I started writing stories in my notebook to help me stay awake, plus I enjoy writing stories). If possible, provide the manager with extra energy. Some of that may go to fixing the meetings, but alas, that extra energy may merely be spent accomplishing extra tasks that are noticed and rewarded.

by Dwayne Phillips

As a manager, I once believed that life could not occur without my presence. I killed myself to be at everything. I learned that was false. This was a blow to my ego that I was around people who were competent enough to work without me.

The biggest college basketball game of the year was played Monday night. And I didn’t watch a minute of it. The game happened without me.

I used to watch every NCAA basketball championship game. It didn’t matter how much sleep I lost and what was to happen the next day. The game couldn’t go on without me.

Then something strange happened: I missed a championship or two because of inattention or travel. The games went on anyway. How dare they play without me watching.

It was a big blow to my ego to realize that people could do big, important activities without me. As the years passed, I found more and more big, important activities occurring without me. One year, they played the Super Bowl without me watching! Imagine that.

Then I started noticing this at work. Critical meetings, tests, and milestones happened when I wasn’t present. The other people at work were smart enough and capable enough to do things when I wasn’t around. How could this be?

Well, it could be just fine. I could even leave a job, be replaced by someone else, (a nice someone else, but surely not as capable as me 😉 and the building would not collapse due to the vacuum of my absence. Amazing.

I learned – slowly, but I learned – to stop worrying about everything. I learned that my two eyes didn’t have to witness something for it to occur. I learned to trust other people to be competent and do a fine job.

I became much happier.

I would still like to watch the NCAA basketball championships. But I wake early in the morning and they play those games so late at night.

by Dwayne Phillips

Kids today. They do new things at dizzying speeds. Sometimes it is a big waste of time, but sometimes it is quite productive. They are entering the work force in droves, so be ready.

Yesterday 6AM – I wake my son. He wanted to ask me something about headphones, so he left me a note the night before.

He is writing a paper in college about a piece of music. He had arranged to interview a performer who had recorded that piece of music. Pretty clever idea, something I never did in college.

He is going to do the interview over Skype – also pretty clever as I won’t have to pay for a long, long-distance call. He is struggling to find a way to record the conversation so he writes accurately what the performer says. Somehow a headphone splitter was one solution?

We find a Skype recorder online. It costs $15, but has a free 7-day trial. We download it. We need to test it. He runs upstairs to my iMac, installs Skype on it, and we test Skype and the Skype recorder.

Everything works, and I now know how to use Skype (yes, I am a little behind on some things).

It is now 6:15 AM.

We have

1. found just the right application
2. installed it
3. tested it
4. installed Skype on my computer
5. tested it
6. learned how to use the whole thing

in 15 minutes.

I needed to go back to bed and take a nap. A full day’s work in 15 minuts.

By Dwayne Phillips

I had to explain the concept of a subroutine in a computer program. The humble subroutine is a type of a module in a system. Modules in systems are wonderful devices. Often, however, we forget about them and how to use them well.

Now and then, a fundamental concept comes back to me as I try to explain it to someone else. This past week, the subroutine came back to me. My youngest son is taking a beginning programming class in college. Finally, the instructor (I am pretty sure he is a grad student, not a professor, although I am not sure a professor would be a better teacher) reached the point in the semester where he “had to” give an assignment that required subroutines (“functions” in Python). I didn’t like the assignment as I felt it didn’t show the power of subroutines.

Enough lament on the state of college education in America today.

I found myself explaining the concept to my son the music major. Hmmm, if you are not familiar with music concepts, this may not make sense to you, but it made sense to him. Often, a section of music is played several times such as when a pop song has three verses and the music is the same for each verse. That section of music is like a subroutine. It does something for the song, but there is no need for the composer to write the music three times. The composer writes it once and the notation points the performer to the same section of music three times.

A subroutine is like that. The programmer writes that piece of source code one time. The programming language notation allows the programmer to point to that section of code several times without writing it each time.

The subroutine is a piece of work or a piece of data or a piece of both work and data. Once that piece is created, it can be used in many ways with many advantages.

This brings me up a level of abstration to a module in a system. A module is a thing that is smaller than the entire system, but once made can be used in many ways by the system. Looking on my desk right now I see many modules in systems.

The cartridge that fits in a ball point or other type of pen. Once the ink is spent, I replace just the cartridge instead of the entire pen. Different types of cartridges will fit in the same pen body as long as they meet the interface standard defined.

The staples inside the stapler. The staples come glued together in a defined size. Once the staples are spent, I merely replace them instead of replacing the entire stapler.

The clip that holds my ID badge to my shirt. I can remove it and replace it with a spring or a coil or any one of several different types of connectors. After removing the clip, I can use it on another ID badge or some other type of device.

The monitor I am looking at right now. There are many different sizes, shapes, and makes of monitors that I can connect to the computer on the desk. As long as a monitor fits the defined interface, it will work.

I am not sure who invented the concept of the module in a system. Several people are credited with putting that concept into the subroutine in a computer program (see reference below). I am glad the subroutine exists.

In a way, I am happy with the failings of the state of college education in America today. That allowed me to explain the subroutine to my son the  music major. I still think that an instructor should be able to say more about the humble subroutine than “we have to do an assignment with one.”

Reference:

I think the Wikipedia page on subroutines is excellent. See it here. It credits Maurice Wilkes, David Wheeler, and Stanley Gill with inventing the subroutine.

by Dwayne Phillips

Small tasks should need small effort. Large tasks should need large effort. Those nuggets of management wisdom are often wrong. I find that task effort relates to task difficulty, and task difficulty relates to the experience of the people on hand.

I recently helped some people remodel a person’s house. We did major work on almost every room in the house.

There is one thing we didn’t finish – a little spot in a second bathroom. This little spot is where the baseboard meets the shower stall meets the wall meets the floor meets a piece of trim. This little spot is about 2 cubic inches of space.

That little spot is little. It seems that such a little thing would require a little work. Wrong!

We carpeted four bedrooms in less time and manpower than we have spent on that little spot in the bathroom. We painted six rooms in less time and manpower than we have spent on that little spot in the bathroom. We hauled ten pickup truck loads of trash to the dump in less time and manpower than we have spent on that little spot in the bathroom. I could go on with other examples.

That little spot in the bathroom is still a little spot as we have yet to find a way to fill it with something other than crumpled newspaper and duct tape.

I have similar experiences in my real-life paying job. I was once on a project where we used satellites to move data between places on the earth. The satellites were shared resources, so we needed software to manage schedule conflicts. We were able to find satellites that met our needs, meet with satellite access providers, sign contracts, and bring a hundred people to agreement on interfaces. We struggled, however, to  figure 24 hours in a day, the rollover from one day to the next, and the rollover from one month to the next. Simple calendar functions almost killed a multi-million dollar project.

I have learned (the hard way) that the size of a task does not indicate the cost of the task. That cost can be measured in person-hours, dollars, materials, and any other resource you wish to count. Assuming task size equals cost can be disastrous. If nothing else, it is frustrating to no end.

Task cost is more a measure of difficulty. In my experience, difficulty relates to the experience of the people attempting the task. For remodeling the house, we had people who could paint rooms, lay carpet, and haul trash. We didn’t have people who could remodel bathrooms. In the satellite example, we had satellite engineers and managers. We didn’t have calendar programmers.

Always try to have people on hand who are experienced at the tasks on hand.

Now where is the newspaper and duct tape?

by Dwayne Phillips

Some system developments take a long time and drain people. You walk in to work and there is no energy. A demonstration of capability is one way to awaken people and bring focus to a project.

Several years ago, I was working with about a hundred people on a large ($100 million) project. We had a rough start, recovered somewhat, but we weren’t focused – we had little energy, and it showed in everything we did.

Enter the demonstration. I asked that we demonstrate what capabilities we had in hand. To those who use the various strains of Agile Development this brings a resounding “No Duh!” Frequent, short, iterations that put something of use in the users’ hands are the foundation of these methods. This organization and this project, however, were not agile.

The system didn’t lend itself to two- or six-week iterations. Hardware was involved – one-of-a-kind, hard-to-build, hard-to-purchase-parts-for hardware.

Nevertheless, we had reached a stage with the hardware that it functioned. It wasn’t pretty, it looked like a rat’s nest of wires trimmed with duct tape, but it functioned. We could use the hardware to sense a signal and store that signal to a disk drive. We had software scripts that proved our signal processing algorithms. I emphasize that these were scripts, not compiled code.

We picked a date to demonstrate what we had – concentration ensued.

The hardware engineers removed the duct tape, secured their connectors, and tamed the rats nest into somewhat presentable wiring harnesses. The algorithm developers found their scripts and moved them from their experimenting computers to the project’s server. That movement took far more work than anyone anticipated. It forced the algorithm developers to learn about the environment they were using and if that environment existed anywhere else. It also forced the programmers working on production code to look at their environments again. They learned a few things.

The demonstration date arrived. The hardware sensed the signal and sent it to a disk drive. The alorithm developers ran their scripts. A system administrator rigged a way to play the result over speakers.

The hardware and software we had in hand worked! Many people breathed normally again. People smiled, and the  boss took everyone to lunch.

Agile methods aren’t appropriate or possible for every type of project, but demonstrations of capability work in almost all projects. People concentrate, people look at their work closer, and they pull together as a team.

by Dwayne Phillips

Bringing about change in a group of people is perhaps the most difficult task anyone can undertake. An old fable sheds light on one technique for encouraging change.

I wish I knew the origin of this little fable. I hope that I relay it well enough. Anyways, here goes:

Once upon a time, a man wandered into a strange land. Hence, he became “the stranger” to those who lived in the land.

The inhabitants of the land befriended the stranger – they provided him with food, shelter, and the necessities of life plus a few of the luxuries. Since they were kind to the stranger, they told him to stay away from one field that was inhabited by monsters. They were earnest in their warnings.

The stranger’s curiosity was too powerful for him. One day, while alone, he wandered into the field to see what monsters were there. He was surprised to find that the “monsters” were watermelons. He didn’t understand how the people had decided that the watermelons were monsters, but he would show the people that they had nothing to fear from the monsters (a.k.a. watermelons).

The stranger cut the vine of a large watermelon, carried the watermelon from the field into a village of the people, and ate the watermelon to demonstrate how harmless it was.

The people were terrified. This stranger was a bigger monster than the monsters that lived in the field. In horror, they killed the stranger.

Years later, another man wandered into the same strange land. Hence, he became “the stranger” to those who lived in the land.

The inhabitants of the land befriended this stranger as well. They provided him with food, shelter, and the necessities of life plus a few of the luxuries. Since they were kind to the stranger, they told him to stay away from the one field that was inhabited by monsters. They were earnest in their warnings.

This stranger’s curiosity also was too powerful for him. One day, while along, he wandered into the field to see what monsters were there. He was surprised to find that the “monsters” were watermelons. He didn’t understand how the people had decided that the watermelons were monsters.

He went back to the village where the people let him live. Each day he would talk to the people about the monsters. He agreed that the monsters were indeed fearsome. He learned why the people decided that the watermelons were monsters. Weeks passed with continuing talk about the monsters.

In time, this stranger convinced the people that the monsters were very similar to large melons that people in his land far away grew and ate. He built the courage of the people to the point where they went into the field and took a watermelon back to their village. After watching the watermelon for many days, they decided it was safe to eat it.

Now the people of this land grow their own watermelons and enjoy eating them.

This story is not for people who fear watermelons as if the melons were monsters.

This story is for us strangers who wander into a land and find people who are afraid of watermelons.

by Dwayne Phillips

Urgency and energy are great qualities to have in the people on your project. Urgency can be instilled in people via careful and thoughtful motivation. Energy may come in the door with some people. Given either of these, work moves quickly. Without them, work doesn’t move.

I have become my father.

That statement is usually given with a sigh of woe. I recall Billy Crystal saying it once in a movie as he bemoaned this and that about the inevitable atrophy of his physique. I, however, make the statement with pride and a big smile.

Four months ago, I became a grandfather with the arrival of a grandson. I am a great grandfather. I love to keep my grandson while his mother goes shopping or something like that. She knows it and she allows me and my wife to keep the baby a few hours at a time. I play with the boy, take photos, and make videos.

In a very short amount of time, I learned how to:

1. shoot video sequences on my digital camera
2. edit the individual sequences on my computer
3. paste the edited sequences into one video
4. export the videos to YouTube
5. embed the YouTube videos into my various web pages
6. watch the videos on my iPhone

These embedded videos allow my  mother and my wife’s parents to see how their great-grandson is growing by the week. They enjoy that.

So what does this have to do with anything related to this blog?

I emphasize that I learned these various things quickly – in just a couple of hours. I was motivated, i.e. I had lots of energy for this task. Learning was fun. I also had a sense of urgency. I wanted to put the videos online as fast as possible so my distant relatives could see the baby.

I contrast this level of energy and urgency with some of the projects I worked while employed by the government. Progress in those was glacial (can glaciers move backwards?). When something new arrived, no one wanted to learn it; no one wanted to do it.

Are you a project manager? I urge you to either:

instill a sense of urgency in your staff

or

find people who have energy (desire) for the task.

Without these, you might as well be waiting in line at the Post Office.

by Dwayne Phillips

Author and consultant Ed Yourdon is updating his book “Death March.” He is working on the book online as a type of blog. You can participate by reading and commenting. The instructions for joining are here.

I have joined in the discussion. I like this type of thing – reading something written by a smart person and commenting. Some of my comments so far:

Types of Death Marches: One form of Death march is one where everyone hates to come to work. The office is toxic, people distrust one another, and everyone would rather be somewhere else. This atmosphere is usually created by a manager or several managers. Years of improperly handling disputes, dysfunction (and any other dis-whatever) have led to this.

People won’t leave because the pay is too good, the commute is too good, or they are simply insecure in their ability to find another job. This personal and widespread insecurity also adds to the death march.

Causes of Death Marches: When pointy-haired-bosses read about advances in computer technology and the newer collaborative tools in the airplane magazines, they figure that their people should be able to do twice as much in half the time.

Then there are the economic woes (higher unemployment) and outsourcing to other countries. The PHBoss tells the people, “there are lots of unemployed programmers out there who would be thrilled to be working on this (death march) project. Besides, I can always send this work to India.”

The (death march) programmers understand that this reasoning is probably true, so they put their heads down and trudge onwards.

Somehow, economic misery emboldens managers of death march projects.

I think that one of the causes of death march projects are death march projects. We work on a death march and survive, but we are exhausted. We need recovery time, so we come into the office in bodily form, but only as mind numb zombies.

We are now prime to be hit by the unexpected things you mentioned in the text. We don’t think ahead for the next thing that could surprise us, because we cannot think.

by Dwayne Phillips

Games can be great teaching instruments. Some people are able to use computer games as education tools. Computer games, however, are costly to create. Simulations of real life can be created with far fewer resources. I recommend two places where you can experience such simulations.

I just finished reading an article about education through games (see reference below). The authors exhort computer science and engineering schools to use video and computer games as tools for educating programmers and engineers. That sounds like a great idea, and the authors present evidence of its benefits. I, however, see one big problem:

It takes a lot of money, time, and expertise to make a good computer game.

I don’t have any of those resources. I don’t know of any universities that have an abundance of those resources.

I do know of another source of such educational games. Games are simulations, and simulations of real life are not difficult or costly to create. I write that with confidence as I have created many such simulations of real life.

Later this month (March 2009), several acquaintances of mine are running a week-long seminar known as PSL (Problem Solving Leadership). PSL is a seminar that was taught for many years by Jerry Weinberg and a number of colleagues. Weinberg is now running PSL a few more times with Esther Derby and Johanna Rothman. I highly recommend attending PSL to experience simulations. What you will learn from PSL will far outweigh its costs.

Another excellent opportunity to experience simulations is the Amplifying Your Effectiveness (AYE) Conference.  This occurs in November of each year. So you know, I led simulations at the AYE Conference for several years. Every session at AYE is centered about simulations.

Reference

“To Game or Not to Game,” Christiane Gresse von Wangenheim and Forrest Shull, IEEE Software, March/April 2009. pp. 92.95, http://computer.org.