A school district in Maine has (accidentally?) created an excellent learning program for its high school students.

The Portland, Maine school district is issuing laptop computers to some high school students for use in school. The computers are loaded with censorship filters that will keep the students away from social media web sites.

This may be the best education program I have seen in years. Imagine, you give teenagers computers and tell them, “We have software on these that tells us what you are doing. There is nothing you can do to escape our oversight.”

The school district has just turned on these teenagers.

The kids are going to dig and study and practice and learn and learn and learn until they hack their way past the adults’ software filters. These kids are going to learn more in this weekend exercise than they have learned in years of formal school programs.

The kids will learn so much that I have to wonder if the school district created this situation on purpose. Did some adult actually figure out a way to challenge the kids and turn them on?

Some well meaning adult may have created a situation actually believing that the kids wouldn’t try to break the censorship tools. That interpretation is hard for me to believe, but since a government body is involved, that is probably the truth.

Why don’t we have more engineers and computer scientists? Maybe, for better or worse, we don’t have enough “tough” people.

I have recently read of a shortage of engineers and computer scientists. I have my doubts about this shortage, but enough people are declaring it that there may be some truth to it.

One question I see asked is, “Why don’t people take online programming courses and fill these open jobs?”

The answer is, “They don’t want programmers, they want people with degrees in engineering or computer science.”

Aha! So that’s it – credentialism (or something like that).

Engineers and computer scientists take two years of calculus, one year of chemistry, and one year of physics in college. Those are difficult courses. Passing those courses requires an amount of toughness or fortitude. Taking online programming courses, while not trivial, does not require the same toughness or fortitude.

Note, I wrote “for better or worse” in the summary at the top of this post. Being “tough” may not be a good thing. It could simply be arrogance, and we could tolerate a shortage of arrogance.

Nevertheless, companies look for people with degrees in engineering and computer science. They look for people who have worked their way through difficult courses. We have yet to find another way to equate something to that difficulty.

We are open to suggestions.

Answer questions in the same forum at which they are asked. If possible, answer questions immediately. Failure to follow these usually leads to suspicion, and that is the death of organizations.

Does anyone have any questions?

Yes, speakers feel obligated to say this. I am not sure why, but there is something that just pulls this question out of people.

Okay, so you ask for questions. Someone raises their hand and asks a “tough question.” That is a question that you may not want to answer now or don’t have an answer now or just don’t know what the answer is (what is the square root of 13)?

Here is point 1:

Answer questions in the same forum in which they are asked.

Speakers often miss this point. They respond with, “That’s a good question. Let’s talk about it later after the meeting.”

This answer is often heard as, “How dare you ask that question here and now. You are trying to embarrass me. I’ll fix you later.”

The answer is often also heard as, “I don’t want to tell all these people the answer to that.”

This leads to point 1.a.:

If you ask for questions, answer them.

This leads to point 1.b.:

If you don’t want questions, any possible questions, don’t ask for them.

Unanswered questions or questions passed to some other, less public, place lead to (among other things):

suspicion

There are few things for the life of an organization that are worse than suspicion. People stop trusting one another. When trust is gone, just close the door and turn out the lights because it is all over.

There is, however, at least one other way to delay a question to another place. Tell the asker, “I don’t have the answer to that. Will you help me work on the answer and distribute the answer to everyone here?”

Give this response only if you mean it, only if you have the time to work with the asker, and only if you can arrange a way to distribute the answer to everyone present.

Preserve the trust that exists among the people.

When you say or hear a negative statement, add “up until now” to erase the negative.

These magic words come from author and consultant Jerry Weinberg. They are great erasers.

Here are some examples:

• I am not a good writer…up until now
• I stutter when I speak in front of people…up until now
• I eat too much…up until now
• I don’t practice enough…up until now

And here are some examples of what to say when you hear a negative statement:

• We don’t follow our employees’ careers enough…up until now
• We don’t talk to people enough…up until now
• We don’t advertise well…up until now
• We don’t care…up until now

You could become a hero be tossing in these magic words in meetings.

One more thing. Funny, the negative statements tell us what to do. They are the solutions to our problems. Think about it.

One measure of project stress is the means to which you go to hide from people so that they cannot bring you bad news.

I used to hide in the men’s room. Actually, I had to go into a stall, close the door, and sit on the toilet in the men’s room. This was ten years ago. In many ways, this was the worst project in my life. In many ways, this was also the most educational project in my life, but that is another post for another day.

Needless to say, this was a bad project with lots of stress. If I went for a walk in the hallway, someone would find me and give me more bad news about the project. If I went to the cafeteria and sat in a corner, someone would find me and give me more bad news about the project. If I went outside and stood in the sun on a hot day, someone would find me and give me more bad news about the project.

The stall in the men’s room was the only place to hide. No one ever knocked on the stall door and said, “Dwayne, I just spoke to so-and-so and he has some bad news.”

Hence, here is a measure of project stress:

Where do you go to hide from more bad news?

Think about it.

Taking from Seth Godin, what kills large organizations is that people don’t know what other people are doing. Managers at the top level are responsible for these problems.

Seth Godin has a recent post on his blog that I love to hate or hate to love or something. He highlights a problem in large companies – people don’t know what other people are doing. Godin’s post is about what a person does when they see a problem in their company’s product, but they don’t know who to tell about the problem. They don’t know which person is responsible for that product.

The problem is not unique to companies and corporations. Non-profit and community volunteer groups have the same troubles. The group becomes so large that a person doesn’t know who in the group is accountable for something else.

Godin understands the problem well and he knows who is responsible – the senior managers. These senior managers set the direction of the organization and hire employees or bring in new members. They determine the structure of the organization that allows and prohibits communication.

Technology to the rescue. Well, sort of. Organizations have web sites and blogs and such. These devices are places to hold the information that can answer the titular question, “Who does that?”

Of course, some person needs to keep updating those sources of information so that they are current. Again, the senior managers are responsible for that happening.

You might object that the senior manager eventually becomes nothing but a librarian, i.e., someone who points to sources of information. Yeah, that is about it. That is the job.

Sometimes the world changes and you have to alter your product in what may seem to be an evil way.

Samsung recently announced that they are including WiFi in their higher-end cameras. I can see some of the engineers and scientists at Samsung wincing in pain. Excellence in cameras is about lenses and mirrors and geometry. WiFi? That is RF communications. What does that have to do with a camera?

The world changes; paradigms shift.

Cameras no longer capture light on chemically treated surfaces. It is now about charge-coupled devices and processing on computers. The lenses and mirrors are still there, but the user is carrying a computer image capture device. The data captured (data, not photons) are sent to a computer. You can use wires or you can use wireless, but you have to move the data.

Paradigm shifts are not new. The mechanical wristwatch changed to a digital wristwatch. Springs, gears, and levers were replaced by integrated circuits.

People who understood wristwatches, however, knew that wristwatches are items of jewelry – not time pieces. The jewelry fashion designers said goodbye to their mechanical engineer colleagues and welcomed the chip makers and computer programmers. They tolerated the changes so they could continue to design fashion jewelry.

People who understood cameras, and still understand computer image capture devices, know that the reason behind the camera is to record a moment forever. They have to say goodbye to the chemists and hello to chip designers and computer programmers.

Paradigm shifts tend to bring necessary evils, and those necessary evils sometimes take funny forms and have unfamiliar faces.

There is a trend lately for young male programmers to act like fraternity pledges. This is just the last in a long line of dysfunction in computer science.

The percentage of female computer science graduates and professional programmers is declining. It has been in decline for several decades. There is much speculation about the causes, but one recently cited cause is the “brogrammers.” These are young male programmers who act like fraternity pledges. They don’t act like drunken college boys, they act like want-to-be drunken college boys.

And sometimes we wonder why women don’t flock to this.

Where can we start? Let’s start with the programmers themselves. Perhaps they didn’t have the advantage of the parents that I had. I had two brothers and no sisters. My only regular interaction with females was with my mother. If I didn’t behave well, I got a knot on my head courtesy of my father’s knuckles. After leaving home, the idea of treating a woman poorly never entered my mind.

Now let’s move to the persons who supervise young, male programmers. These are sometimes known as supervisors and sometimes as managers. Young, male programmers do what their managers allow them to do. The managers are supposed to be a little more mature than the persons they manager. It seems that this no longer holds.

<rant>I am disgusted when I hear about brogrammers and the like. Such should not be tolerated.</rant>

Once you refer to some person as “boss” and other persons as “employees,” all is lost.

I saw this post a few days back about the boss’ greatest fear. They don’t want the employees to catch them on video. There might be something in the video that can harm them.

Let’s back up a few steps. I think the boss’ greatest fear should be:

Some persons are called “boss” while other persons are called “employees.”

I worked in the U.S. Federal government for over 25 years. I attended countless gatherings where we discussed supervisors and employees. I was always confused about this because it seemed to me that supervisors were also employees. I mean, they were paid by the same taxpayers and worked for the same U.S. government. How did they stop being “employees?” These “supervisors” were supervised by someone else. In fact, everyone in the Federal government has an official supervisor except the President.

Still, people insisted on separating everyone into two groups: supervisors and employees. These people insisted on pitting these two groups against one another.

That is what I see as the problem with this boss and employee thing:

It creates two embattled groups.

Whatever happened to, “we are all in this together” and “we all have one mission” and those things? Were they just a bunch of silly sayings from and for naive persons like me?

Take care with the language we use at work. Are we all working together or not?

The number of people on a project influences the management practices that will succeed. An easy-to-remember heuristic is the breakpoints at 3 to the n power.

Yes, that is mutters with a “u.” As the size of a team on a project increases, so does the muttering. This implies that what works for a team of one size may not work for a team of another size.

It should be no surprise, although for some it is, that increasing the size of the team increases the patterns of miscommunication, misunderstandings, disagreements, arguments, and general muttering. Communication methods as well as other methods break when team sizes grow and shrink.

When should the methods change? At what team sizes do they break?

One heuristic for the breakpoints is using the number 3 raised to its powers. I learned this from author and consultant Jerry Weinberg. The breakpoints are:

1, 3, 9, 27, 81, 243, …

These numbers aren’t exact breakpoints, but they are close enough and since they are powers of 3, they are easy to remember. Moving from one size project team to another (say from 3 to 9 or from 27 to 81) breaks most management methods. The methods that worked at one level don’t usually work at the next.

Jumping two levels, e.g. from 9 to 81, breaks almost all the working methods.

There are various ways that the different size levels manifest themselves. In this paper, I will only discuss one – the communication patterns (also from Jerry Weinberg).

The communication patterns can be illustrated as follows:

—-

# of people – communication pattern

1 – self-knowledge

3 – knowledge of intimates (like spouse and children)

9 – knowledge of teammates (we may not know their intimates, but we know “about” their intimates)

27 – we know their names, but not their birthdays or where they live or who they love

81 – we recognize each of them as belonging to this organization, but we don’t know all their names

243 – many of them are strangers, most of them, in fact

—-

In the 1-person project, I know myself and what I am doing. This is simple enough.  I’m not concerned about anyone else on the project and  how I communicate with them.

In the 3-person project, I know the other two people quite well. I may know the names of the people with whom they have intimate relationships like their spouse and children. We communicate well with one another because we “almost” know what one another is thinking.

In the 9-person project, I know the other eight people well. I know personal information like if each person is married or not and has children or not, but I don’t know the names of these spouses and children. We communicate well with few words.

In the 27-person project, I know the first and last names of everyone on the project. That, however, is it. I may know three or four of them quite well, but the rest are really strangers to me. Communication is slow as I have to explain everything with almost exact terms. We don’t have a common slang or figures of speech.

In the 81-person project, I recognize people’s faces. I would know it if a stranger wandered into the offices. The people on my sub-team are familiar to me. We communicate well, but the rest of the people are strangers. We spend much of our meetings introducing one another. At least we should spend time introducing one another. Otherwise we seem to have a lot of misunderstandings that causes mistakes and wasteful rework.

On larger teams – well, those really aren’t teams. Most of the faces in the group are recognizable, but I know the names of only a few.

Some people struggle terribly when they lose the intimacy of moving from 3 to 81 people. The struggle is because while they like the work they love the people. Being “techies,” they may not realize or will not admit that they love the people. They may not realize what has happened when the intimacy is gone.

They know something is missing, but cannot identify it. The project just seems to be “going to hell in a hand basket” or something.

For example, a couple of years ago my organization was doing some proof-of-concept work with a contractor. There were about ten people involved in the work with three or four in my group and six or seven from the contractor. The proof-of-concept work succeeded wildly, and management funded a large project to take advantage of the new technology in a full-scale development project.

The number of people involved changed. We still had three or four people in my group, but the contractor’s cadre grew quickly to 60, then 70, and finally 100 people. We jumped two levels in the 3-to-the-power-of chart (9 to 81).

The communication pattern changed drastically. One person in my group, Jim, was struck particularly hard by the change. Jim would sit in our group’s meetings and complain about the  drop in service from the contractor.

“Something is wrong with Susan (a counterpart at the contractor),” Jim lamented, “She used to answer the phone before the second ring. Now I always get her answering machine, and sometimes she doesn’t call back until the next day. By then I am away from my desk and we play telephone tag.”

Susan was still hard at work, but the communication pattern in her office had changed. She now met with groups of people to ensure that everyone knew what they were supposed to be doing. She no longer sat at her desk all day ready to answer the phone.

Jim had lost the close attention of a colleague via the quick phone call. E-mail and other asynchronous communication worked much better in the new project, but Jim didn’t realize that and didn’t want to change. He longed for a return to close attention. (See Footnote)

Changes in the size of the project are common. You may work with teams that are the same size all the time; I don’t. At this time, I work with project teams of 100, 50, 20, 5, 2, and 1. I am in constant flux and, until I realized what was happening, I was in constant confusion. At least now, I better understand what is happening to and around me. The communication patterns in these different projects with different team sizes differ. I could try to force one pattern on all the sizes. The result, however, would only be frustration and failure. Instead, I adapt to the communication pattern that fits the team size. The result is less stress, more success, and more enjoyment.

I urge fellow project managers and team members to try three things:

(1) draw upon your good experiences with teams,

(2) understand the size of your current team, and

(3) think about what communication pattern fits.

Try to recall good experiences with teams on past projects. What worked for you? What did you enjoy? How many people were on that project? Where was your team on the communications pattern example given earlier? Was your experience similar to the relationships given in that example?

Examine your current team and the current project. How many people are on your team? Are you in the same power-of-3 as you were on the earlier, enjoyable project? What communication pattern are you trying to use on the current project? How is it working?

Think. Are you trying the same communication pattern you used on that earlier project? How is it working? How do you feel? What might work better? What might improve how you feel?

I sat in a meeting for a new project yesterday. Four of us worked together to initiate a product that will allow several hundred people spread around the world to communicate about requirements. Four people communicating about how several hundred people will communicate; that jumps several powers of 3.

At first, we were trying to design a product that would have people communicate the same way the four of us around a single table were communicating. After a few moments, we saw that this wish would create frustration among the hundreds of people instead of closeness.

We settled on using different approaches for the different situations. I think that was a wise choice.

Footnote:

This project is an example of how success may lead to failure. The proof-of-concept project succeeded. This spurred an avalanche of funds and an exponential growth in the number of people involved. Had most of us not changed our patterns of communication, the large development project would have failed. Success (on the proof-of-concept) would have led to failure  (on the development).