Working Up

by Dwayne Phillips

What do you do with a person who isn’t doing their job, but seems to do other things?

Fire him. He admits he doesn’t know how to do all the things you want him to do. He admits that he just doesn’t learn fast and will take along time to do the things you want him to do. It is simple, fire him.

But he has been on the team for ten years … so…

There is some value in a person’s ability to make everyone else feel good. There is some detriment in a person causing other persons to work harder all the time. This isn’t easy, is it?

The weak link is weakest at some thing.

There are always other things.

Gee. The textbooks said this project management gig wasn’t that difficult.

by Dwayne Phillips

Most of us have been through our formative years. How about doing it again?

The formative years are…

• we walk in new
• we soak in things
• we are growing without realizing it

This may be high school, may be college, may be our first job, may be our first professional job. We look back on it and wonder how we make it through to some level of competence.

And now here we are. Can we enter Reformative Years again or re-enter those formative years?

Do we have the energy? Do we have the desire? Can we stand the possibility that we aren’t yet fully formed, fully competent, or fully full of life?

Let’s jump in.

by Dwayne Phillips

Someone on the team needs to be a little farther away from the problem than the rest of us.

Once upon a time…a team of engineers and such had a major design review in Florida. The team didn’t live in Florida. The head of the team, thoroughly enmeshed in the details of the system being built by the team, decided to hold the review at the earliest possible moment.

The persons who scheduled that were close, very close to the problems of the project. We couldn’t delay that meeting a single moment, we had to do it as soon as possible to gain every day of schedule possible. Push. Push. Push.

The week chosen was spring break for local schools. Lots of people were going to the Orlando tourist attractions. The flights to Florida were booked. Members of the team were flying through Denver to reach Orlando with two stops in between. Rental cars were all gone. It was all a nightmare.

The team needed a team member who was not so close to the problem. The team needed a person who could sit back, look at the calendar, and say, “Yes, but…” And that team member needed to have a strong-enough voice to have the rest of the team listen.

I write this blog post from the comfortable table of a coffee shop a million miles away from the slings and arrows of project work. What do I know? Well, I was on that team of engineers who were told to make plane, hotel, and rent a car reservations in Florida during spring break. I raised my hand and pointed to the calendar. My warnings were ignored as I was the type of person to sit at a coffee shop table a million miles away from the slings and arrows of project work and mention local school calendars and tourist travel and such.

Please, assign a person to your team who sits a distance away at coffee shop tables and ponders the tedium of life.

by Dwayne Phillips

Which way is your team facing? When? Why? Consider a few options.

If we are all facing the same direction…we can’t shake hands, that only happens when we face opposite directions. We can’t see what is sneaking up behind our colleague, again that only happens when we face opposite directions.

If we are facing opposite directions…we can’t move in the same direction, that only happens when we face the same direction. We can’t see a common threat approaching, again that only happens when we face the same direction.

Which way do we face? Which way do we have our team face? The team members seem to already know the answer: Each individual changes the direction each is facing often. The total affect is what the group needs. Too much direction from “the leader” often makes a mess of this.

What does the leader do? Ensure that the leader doesn’t make a mess of this.

by Dwayne Phillips

A review of one of the fundamentals of systems engineering. We create and manage budgets of key technical performance measures.

System engineers work with technical budgets. Examples:

• size
• weight
• power
• attenuation
• memory use RAM
• memory use disk
• time to complete an operation

We are building a smartphone. We are told to keep total weight under X. We allocate so much weight to the case, so much to the screen, so much to the battery, etc.

As the design progresses, we monitor the weight estimates for the designs of the components of the system. The screen folks are a little over, but the battery folks are a little under. We juggle the budget allocations and watch closely.

The prototypes have been built. We are over budget, i.e., over total weight. Where can we cut. We go back and forth among and within the different component teams.

And at the same time we have a budget and allocations for the amount of power the different components draw. We have to test and monitor those allocations. The processor is drawing less power than allocated. That is okay sort of as the screen is drawing more power than allocated. We keep juggling the budgets of the different pieces.

Sound familiar?  Then you have been performing one basic function of systems engineering.

Never heard of this? Perhaps you should explore the field of systems engineering.

by Dwayne Phillips

Someone who had a big influence on my life has passed away.

“The Mote in God’s Eye.”

Star Wars was in theaters, and everyone was enthralled. The science fiction community tried to fit in with Luke, Han, and the rest, often in vain. Every science fiction commentator had their own list of, “Now that the movie makers have the technology and the movie go’ers have the appetite, these are the science fiction books that should become movies.”

The best seller by Niven and Pournelle appeared in many lists. I had to find out what it was. I devoured the book.

Aha! That was why science fiction fans were happy yet disappointed with Star Wars. That was the example of real science fiction—fiction with science and humanity blended expertly. I wanted more and found it with more by Niven and Pournelle.

A couple of years later, the personal computer revolution was on us. Byte magazine was the monthly chronicle of how much technology changed at a frantic pace. Jerry Pournelle had a long column in every issue. That was the guy who co-wrote those great books. How could one person do all that? And what Jerry wrote every month was maddening. How could a person bungle through all those machines? And why give them names like Lucy and Linus. Those were machines!

Time flowed through my life of marriage, births, deaths, jobs, and changes. The constants were the pace of computer progression and my enjoyment of writing.

The Internet arrived. One day I did a random search about writing professionally and Jerry Pournelle popped up again. He had a long essay published no where but the Internet. “You want my job?” asked Jerry. “Write 10,000, or some unheard of quantity, words as practice.” He went on with excruciating detailed advice that I found to be true in the ensuing years.

And Jerry Pournelle had this daybook thing on the Internet. He wrote and wrote and wrote, and all I had to do was show up online and absorb. He knew politics. He knew warfare. He knew education. He knew history, gosh did he know history. He knew humanity.

From 2006 through this month, I read jerrypournelle.com and Chaos Manor. I finally figured out that, as he said, “he did a lot of foolish things (with home computing) so that I wouldn’t have to.”

Jerry had a brain tumor and lived through radiation treatment. His empty-nester dog died. He went to the opera. He went to writer’s conferences. Apple computers moved from the fringe through the mainstream. Barack Obama was elected. Donald Trump was elected. Bouts of the flu came and went.

Then this last week, his son wrote, “I’m afraid the Jerry passed away.”

It has taken me about a week to put hands to the keyboard and write more words. Perhaps that is my tribute to Jerry Pournelle. I’ll write more words. Maybe one day I can have his job. Maybe no one will ever have his job.

by Dwayne Phillips

Jugglers know this. Managers and builders should know this. Let the little things fall without over reacting.

Jugglers have to do this. They may be a bit off balance, so they let a ball fall to the ground.
An alternative is to over react and reach for that one ball and lose focus and drop all the balls and …. everything goes downhill quickly.

Hence, good jugglers learn to let one or more of the balls fall to the ground. They don’t reach. They don’t stretch out of shape.

The lesson(s) for project managers and builders of systems?

• Learn to let something drop
• Maintain your equilibrium
• Keep moving on the bigger thing

There are always bigger things. We sometimes are so involved that we fail to see them, and we let a little ball wreck everything and everyone.

by Dwayne Phillips

Can’t think of anything to write about? Back to freshman English.

It was one of the first classes I took in college. I took it the summer after high school graduation. It was a writing class, I guess it was called English Composition or something. We had a great teacher for this seven-week summer couse. His assignment:

Write something in a notebook everyday.

He would collect and read through our notebooks periodically.

One of his frequent reminders, I won’t call it a college lecture as it was too practical, was that there were always plenty of topics for our daily writing. Just flip through the newspaper. We didn’t have to read any articles, just look at the ads.

For example, today on the Internet, the annoying ads show me…

• an abandoned cruise ship
• Apache Spark

Okay, so I can write an essay about the cruise ship industry or about how we discard really useful things or how we can use discarded things to help people around the world or how we seem to love floating on water. Then the Apache thing…why is it that computer geeks use such awful names like Apache or what in the world does “spark” have to do with what the software actually does or why is it than they want three-syllable names for everything or why can’t they just speak plain English?

And then there is an ad about the best ads of the year. Gosh. That one goes on forever.

And then if I am not interested in the ads, I can actually read news stories from the top newspapers from all over the world.

Nothing to write about? Really?

by Dwayne Phillips

Freedom of choice robs us of excuses. Of course we are free to choose to ignore this.

Most of us live in a world of abundance and wealth. Come on folks, admit this is true.

We have the freedom to choose much of what we do.

It is unfortunate, but we often choose to do something that brings us troubles. Rats. What is wrong with us? We must be human or something.

Hence,

We do what we like to do and avoid what we don’t like to do.

No duh on that one. Still, we avoid the consequence of the above. Given we do what we want and what we like, these luxuries rob us of excuses.

I weigh too much. I didn’t sleep last night because I ate too much at dinner. I’m tired because I stayed up too late watching something entertaining.

I chose to do those things. I chose to indulge. Rats. No excuses available. I can’t blame my pain by pointing to something or someone else. I’m the only one standing in the mirror.

Of course all this choice gives me one more choice. Let’s call it the “Ignore all else choice.”

I can choose to ignore the obvious results of my choices that led me to this pain.

There. Nice to have a choice.

by Dwayne Phillips

I review an old, and seemingly forgotten, technique for building systems in which we fully describe what a system will be and do.

Once upon a time in a galaxy far, far away…

Maybe not that long ago, but still…there was a technique for building systems wherein we wrote the user manual first. Today, we could write the FAQ page or make the YouTube video first, but you get the idea. Then, we built the system to match the user manual (FAQ page, YouTube video).

Of course, there was a lot of back and forth. Sometimes the system simply could do what the user manual stated (at this time). Sometimes the system could do more than the user manual stated. Adjustments occurred daily on all sides. Still, there was a target—something visible that we tried to reach.

Folly? I think not. And no, a story card or whatever is not the same. Start by creating a full-fledged piece of documentation that requires time and effort. It may surprise all of us what thoughts come to mind in creating this. Then, work hard to make it a reality.