Working Up

by Dwayne Phillips

Small projects are great for new engineers. The new engineers learn so many different aspects of building a system on a small project. I used to think that; I no longer do. Instead, I think that small or smaller projects carry with them a curse that can ruin an engineer or programmer or manager.

On larger projects, one person cannot do everything. Hence, the larger project will employ:

• Project manager
• Systems engineer
• Subject matter expert
• Contract administrator
• Hardware designer
• Software designer
• Hardware builder
• Hardware tester
• Software programmer
• Software tester
• System integrator
• and so on

When all these different people are present, it is obvious that these different skill sets are employed.

On a small project, you probably have

• One person in charge
• One hardware person
• One software person

These three people do all the tasks done by the longer list of people above. Each person dord a little of this for a while, then a little of that for a while, and then a little of some other thing for a while.

So, what’s the curse? I mean, the small project looks like fun. A new person will be able to experience many different things. What’s wrong with that?

For about the first half of my career, I worked on smaller projects. It was great. Then I attempted to work larger problems. I failed miserably. I couldn’t do everything in the schedule required. I just didn’t “scale” well enough in that I couldn’t work 24 hours a day five days a week.

“No problem,” I thought. “I’ll just bring on some more people just like me, and the group of us will aggregate to the necessary number of hours.”

That didn’t work. I needed specialists to complete the larger project. Part of the curse from the small project meant that I didn’t know what type of specialists I needed. I didn’t know what a systems engineer did. I didn’t know the difference between a software designer, a software programmer, and a software tester. I had done those three tasks all by myself before, or at least I thought I had. Maybe I had, but then maybe I hadn’t. One day I met a professional software tester. She spent most of a week trying to explain to me what real software testers did for a living. I struggled to understand because I had never seen a real software tester work. That was part of the curse of the small project – I had not seen real specialists do real specialized jobs.

On small projects, everything runs together. One person does a dozen jobs switching mindlessly from one to another. The key word is “mindlessly.” The one person, me, doesn’t understand what is happening as it all seems natural. Besides, mindlessly working on anything is fraught with peril. The mind should be fully engaged at all times.

Let’s start to make a list here, a list of what comes from the curse of the small project.

• I didn’t understand what specialists did.
• I didn’t understand what specialization was.
• I didn’t understand how well specialists did their special jobs.
• I didn’t understand how to scale work.
• I didn’t understand how to work with people who had special skills.
• I didn’t understand how to work with people who had different backgrounds.
• I didn’t understand how complicated things were with a bunch of people working together.
• I didn’t know how much I didn’t know.
• I wasn’t nearly as smart as I thought I was.

That is enough of a list for now. I’m reliving too many bad memories from my early attempts at large projects. The side affects of the curse of the small project are lingering with me more than I realized.

At this point in the post, I should recommend something – something that will make the reader’s life easier than what I lived. Here it is:

Let a new engineer or programmer or manager work a couple short, small projects. Explain to them the many different roles they played on the small project. Quickly move them to a large project with a large number of diverse specialists. Ensure that they see and understand the roles of the specialists and how much each specialist knows about their specialty. Ensure that they understand that they don’t have the skills and expertise that the specialists have.

Maybe the new person will know what they don’t know.