Stories Told

Even a mediocre plan will work if everybody follows it

I have been astonished in my life by how few problems are truly unsolvable. I have also noticed that, most of the time, when a problem ends up not being solved it is for one of two reasons: people deny the problem, or they won’t work together on the solution.

I make software for a living. We have a saying in software development: There are two things you don’t want to know how are made – sausage and software.

There are any number of ways to make software. All of them involve programming, of course; it’s the core activity. But there are other jobs to perform, and the bigger the software being developed, the more people you need to perform them. It becomes necessary to organize the people and form work processes. The ways to do that range from loose and chaotic to structured but flexible to ponderous and formal. They all have their strengths and weaknesses; they all can work. I’ve made software in all of these situations.

Scenes from US 50One of my past employers sequestered its programmers in a room to hack code together as fast as they could. When they were done, a couple people would play with the product for a week or two in hopes of finding some bugs, which the programmers might or might not fix. Then we shipped it to five customers, who upon installing it invariably found that it failed spectacularly. When we fixed all the problems they found, we chose five more customers. We repeated this process until the software stopped failing, and then announced to the rest of our customers that it was ready.

At the other end of the scale, another past employer had such a heavy software development process that following it felt like slipping into a straitjacket. There were reams of documentation to write and keep with layers of approval at each step. I worked on a team that tested the software to make sure it did what it was designed to do. We had to take a screen shot of every test step, print it, and put it in a folder. At the end of a project, we had boxes and boxes and boxes of printouts, hundreds of pounds worth, that we would send to an offsite storage facility. This was in case our only customer, which happened to be the U.S. government, wanted to audit us.

Both companies are still in business.

Brick segment of old US 40/NRA third past employer carefully hired smart people and trusted them to know what to do. Because they hired well, this worked for a long time. But as the company grew, this approach became more and more difficult to manage. Product quality became a problem. A big part of the software was an accounting package, and in one fateful release the general ledger simply would not balance. This affected every customer, and to make a long story short, it took the company almost a year to fix it. Several customers quit us.

Too often it takes great pain to drive important change. This pain made us face that we needed more structure to deliver successfully. So we hired a consultant to guide us toward a better software development process. He showed us a way with just enough checks and balances that we could have greater confidence in our work without being too bogged down. We also hired a consultant to help the management team (of which I was a part) work more collaboratively. She taught us how to lead the company through this transition.

It worked. In the very first product release under the new process, quality problems fell off dramatically and we delivered on time for the first time anybody could remember.

The more important hire was the second consultant. The new methodology was good, but it wasn’t magic, and it might not have worked for us if we had not done a good job helping the team through the changes. You see, a few people didn’t understand why the old way couldn’t still work and still others thought our new process wasn’t going far enough. Our task was to overcome the resistance and get everybody singing from the same sheet of music, and it was the hardest thing we did. But we pulled it off.

It’s a rare organization that faces its failings and works to change. It’s a rarer organization still that drives change collaboratively.

The company with the ponderous process
fired me.
 I’m so glad. Read that story.

Standard
Stories Told

The pinnacle of my career

Not long ago I wrote about a time I was fired under some pretty stinky circumstances. And then there was the time I worked under the CEO who lied in court about having sexually harassed his assistant. And I still haven’t told the story about the company owner who went to prison. Fortunately, my long career in software development (going on 22 years) hasn’t always been such a bust.

I left the philandering CEO’s employ for a situation where the boss and I just didn’t mesh. Also, after having been a technical writer and editor for seven years I was starting to itch to make software again, like I did in college. So when a well-known local software company was hiring software testers, I applied. I knocked the interview out of the park and got the job.

The company made a large and sprawling product for an industry I knew nothing about, so I had lots to learn. Given my background, the first thing I did was reach for the manuals. Unfortunately, they were incomplete, inaccurate, and poorly organized – unusable. There was online help, but it was unnavigable. Nobody was ever going to use any of it to successfully use the product. My boss managed the technical writers too, so I marched into his office to complain. I wasn’t delicate about it. “This stuff is terrible! I can’t believe you ship this to customers! It’s an embarrassment.”

He leaned back in his chair and calmly said, “What would you do to fix it?”

“I would throw it out and start over,” I began. And then over the next ten minutes, off the top of my head I outlined a project that would create new manuals and online help that would actually help users not just use the product, but get the best value from it.

Three days later, he called me back into his office. “Remember that thing you said you’d do with the documentation? I am promoting you to the manager of that department. I want you to do exactly that.”

It was a bold move for him to take a gamble on me. I’d never managed people, and my project management experience was limited. What I didn’t know was that every year the company surveyed its users about product quality – and every year the documentation got the most complaints. My boss had been told to fix this problem, but he had no grand ideas. Then I walked in with a solution that sounded like it just might work.

Most of this story is just the nuts and bolts of the project – hiring and coaching staff, creating plans and schedules, doing visual and information design for the new manuals and online help, managing the project, reporting to management, and even doing some of the writing myself. The details would be interesting only to another technical writer. Much of this was new to me, but I had excellent support from a boss who needed to see his gamble pay off. He also helped me navigate the inevitable office politics, including another manager who kept trying to torpedo my efforts. Also, the program manager helped me master the project management tools we used, none of which I had ever even seen before. My team and I worked on the project for a year and a half. It’s not often a technical writing team gets an opportunity to do a clean-sheet rewrite like this, and they were all enthusiastic about it. I worked hard to clear their roadblocks, respond quickly to their concerns, and generally be a good guy to work for, and it paid off in the excellent work they delivered. When we were done, we had written over 3,000 pages and had created a seven-megabyte context-sensitive online help system.

I was invited to demonstrate the new online help at the annual user conference. 600 people flew in from all over the United States, and there I was before them on the opening session’s main stage. My presentation was the last of a series about new features in the product. When I finished, to my astonishment the online help received enthusiastic applause – and then one person stood, and a few more, and several more, and soon the whole room was standing and applauding. That moment remains the pinnacle of my career; I can’t imagine anything else ever overtaking it. The icing on the cake was when I overheard the VP of Sales say to my boss, “All the blankety-blank new features we pushed you to put into the product, and everybody liked the blankety-blank online help the best! The online help! You’ve got to be blankety-blank kidding me!”

I used to think I was just a grunt paid to trade the words I wrote for a paycheck. Through this project I learned just how interdependent everyone is at a company, and how everybody is important. Specifically, I learned:

  • If you want to see your great ideas implemented, they need to solve a big problem the company thinks it has. What problems does your company think it has? They may very well be different from the problems your company actually has. What great ideas do you have that you can frame in terms of helping solve those problems?
  • When you’re doing something you’ve never done before, find people who can coach you through it. I don’t care how far down the ladder you are at your company, your success helps determine other peoples’. Look for someone who both knows how to do the thing you need to learn and whose success depends in part on yours – that last bit motivates them to help you. In my case, it was my boss and the program manager.
  • Work for the kind of boss who clears roadblocks out of your way so you can be most effective. I now leave situations where the boss doesn’t help me in this way. It’s that critical.
  • Your success always depends on other people, so treat them well. In giving my team an exciting assignment and creating an environment in which they could focus, they happily turned out huge quantities of good work. Also, after we shipped the new documentation, I promoted every writer. They deserved it.

A footnote: That company went through tough times a few years later and so we all moved on, some for better positions and others (like me) because they couldn’t afford to pay me anymore. One of the writers who worked for me called me up one day about two and a half years ago, by which time I really had moved into software testing. She said, “We have an opening here for a test manager. I’d love to work with you again, and this is a good place to work. You really should apply.” I did, and I got the job. I found out later that just before my interview, she went to the VP and said, “He’s a great boss. You don’t want to let him get away.”

Sometimes the good things you do come back to you!

Doing quality work can pay off, too. Here’s a story of a time it really did.

Standard
Stories Told

Twenty-one years in the software salt mines

A personal anniversary passed quietly last Saturday. It was the 21st year since I started my career.

It may seem odd that I remember the day only until you know that I started work on July 3, making my second day a paid holiday. The office was nearly deserted on my first day. My boss regretted not having me start on July 5 so he could have had an extra-long weekend too.

And given that we seem to love divisible-by-ten and divisible-by-25 anniversaries, it may seem odd that I’m honoring this 21st anniversary. But I was 21 years old when I joined that little software company in Terre Haute.

I have now worked half my life in and around the software industry.

I taught myself how to write computer programs when I was 15. When I was 16, my math teacher saw some of my programs and praised my work. He encouraged me to pursue software development as a career. He began to tell me about this tough engineering school in Terre Haute.

My desk at one of my career stops

I graduated from that tough engineering school with a desire to find work as a programmer. Jobs were hard to come by that year, so when the only software company in town wanted to hire me as a technical writer I was thrilled just to work. And then it turned out I had a real knack for explaining software to people. I did it for twelve years, including a brief stint in technology publishing and five years managing writers.

I then returned to my technical roots, testing software and managing software testers. I learned to write automated functional and performance tests – code that tests code – and it has taken me places in my career that I could never have imagined.

I’ve worked for seven companies in 21 years. The longest I’ve stayed anywhere is five years; I left one company after just 14 months. I’ve moved on voluntarily six times, was laid off once, and was fired and rehired once (which is quite a story; I’ll tell it one day). Changing jobs this often isn’t unusual in this industry and has given me rich experience I couldn’t have gained by staying with one company all this time.

I’ve worked on software that managed telephone networks, helped media buyers place advertising, helped manufacturers manage their business, run Medicare call centers, helped small banks make more money, and enabled very large companies to more effectively market their products.

Some of these companies were private and others were public; so far, I’ve liked private companies better. Some of them made lots of money, some of them had good and bad years, and one of them folded. Some of them were well run and others had cheats and liars at the helm. Some were very difficult places to work, but those were crucibles in which I learned the most. Others have brought successes beyond anything I could have hoped for 21 years ago.

I did, however, hope for a good, long run in this industry, and I got it. But I’m also having a hard time envisioning another 21 years. Maybe that’s part of reaching middle age – indeed, many of my similarly aged colleagues, some with careers far beyond mine, have gone into other lines of work. I’m still having a lot of fun making software, though. I currently manage four software testers, two test automation developers, and five technical writers. I get to bring all of my experience to bear, and encourage my teams to reach and grow. I don’t want to stop just yet.

Standard
Stories Told

The butterfly effect

The smartest thing I did in high school was take Speech class.

Speech class, from the lectern

Speech class, from the lectern

I was thinking about that the other night as, just for grins, I scanned some old high-school photographs and uploaded them to Facebook. I took this photo from the lectern. The assignment was to give a sales pitch, so I dug out one of my old cameras, the Argus A-Four, and went off to “sell” it. The flashgun was busted, so when it was time to demonstrate the camera I just opened the lens up wide and snapped a couple shots. I’m lucky any of them turned out, grainy and dark as they are with their washed-out corners. I’m glad for them not because the school building is gone now, or because the kids have all grown up, or because they make me remember how the teacher (in the very back) sounded like a post-puberty Kermit the Frog. I’m glad for them because they remind me of how violently I shook the first time I stood there – even my voice trembled – but how effortlessly I spoke from there at the end of the year.

I operate very comfortably in my introverted skin today, but I didn’t when I was 15. I had a couple good friends, but that was all. I wished to banter easily with everyone, but I always stumbled and bumbled and felt embarrassed, and it hurt. It was easier to keep to myself. I even learned to stare at my shoes when walking between classes so I wouldn’t catch anyone’s gaze.

Nobody in Speech class was there because they loved to perform. We were all pretty much in the same boat of wanting to overcome our fear of standing before others. Because there’s nothing like common condition to build camaraderie, I made friends in class, especially with the girl in the sailor hat in the photo’s lower right corner. We passed sarcastic notes to each other all year as we listened to our classmates speak. The girl in the red with the ball cap got into the act sometimes, too. They both used to crack me up.

And of course nothing overcomes a fear like repeatedly facing it. I gave probably 20 speeches that year, although I remember only the “why I took this class” speech where my voice shook and this sales speech. But no matter; by the end of the year I could stand there and talk as though I was born with a podium growing from the soles of my feet.

Darn good thing, too. That year I taught myself to write computer programs. When the math teacher got wind that I had written a program that used a mathematical formula to draw any polygon on the screen (a big deal in the computing technology of the time), he asked to see it – and was excited enough about it that he asked me to demonstrate it to our Geometry class. I did it, but without having overcome my fear of public speaking in Speech class, I would have turned him down flat.

The math teacher asked me to write programs that illustrated other geometrical concepts, and I demonstrated them all to the class. At first it just felt great that one of my silly hobbies earned me some good attention. But then the teacher suggested that I could study this in college and do it for a living. It may seem astonishing now that the idea hadn’t occurred to me, but in the early 1980s software development was still an unusual career choice. His encouragement got me to apply to engineering school, where I studied mathematics and computer science, which led to my first job working for a software company. Nearly 20 years and five software companies later, there’s no other path I’d rather have taken. I can’t believe I get to do this thing I dreamed of at 15.

I almost didn’t sign up for Speech. Just seeing the box for it on the enrollment form made my heart splash anxiously. I figured I’d end up in a study hall for my spare period. But in the last two seconds before the forms were collected I impulsively marked the box for Speech, and then it was too late to turn back.

And they say the butterfly who flaps its wings in the Congo can cause a tornado in Kansas City.

Standard