Adam Gonnerman

When I was in 6th grade, way back in the 1980s, an odd educational fad swept into the rural school district where I lived. Suddenly we found ourselves being put into groups on a daily basis for our various subjects. Whether it was science, history, English, or social studies, we were told to find groups or to count off and form groups around numbers, then do whatever assignment there was. I hated it. Always there was at least one who was highly motivated and took charge, one or two who helped with whatever the leader(s) said was needed, and a slacker or two. I hated being the primary one pushing to get things done, and I also despised being the lazy member. You would think that a person could simply decide not to be lazy, but apparently that's not how it works. In some groups I simply got the feeling that everyone else had a job to do and there was no place for me, and that my contribution wouldn't mean anything. Still, I felt guilty every time it happened. This dynamic plays

Jeff Geerling (CC BY-NC-SA 2.0) It's been said that "if all you have is a hammer, everything looks like a nail." That's a cognitive bias called the 'Law of the Instrument,' and one that I've encountered in the workplace a number of times. It might sound familiar to you as well.  The worst example I can give is of the time I worked in a division of a company that used Power Point for pretty much everything. All reporting took place through Power Point slides, which is fine for high level presentations but not great when you need to get into details. Not long into my employment I was told emphatically that I had to create a 'detailed project plan' in Power Point. On one occasion I joined a meeting to discover that the person running it had used a one slide Power Point deck for the agenda. It was as if no one could imagine there being a different way to work. Honestly, I don't know how it gets this bad in an organization. That it becomes a hidebou

One of my great aunts worked for 40 years at the same company, retiring in the 1960s. Such longevity is practically unheard of today. In my experience, there is good and bad around someone being at the same company for more than a few years. Having been through a few reorgs and layoffs at companies, I am not often surprised any more at who gets the boot (including when it's me). More often than not being laid off isn't something to take personally. If you've been laid off as part of a larger reorg, it generally just means that there was a perceived redundancy or an 'opportunity' to shift work around and save some money. You are just a name on a row in an excel spreadsheet, and on that same row is your title and salary. Still, it is a little shocking to me when someone with years of experience with the company, and a solid reputation, is shown the door. It really shouldn't be surprising, because it really comes down to that salary. Someone who works their way up

Listening to a podcast recently I heard a project manager say of himself that he is often given the project that are "already on fire." I cringed, because I have made that comment myself quite a few times. Too often it was in interviews that I made the boast. It's not really that remarkable for a project manager to be handed a project on fire and asked to make something of it.  There are many reasons for a project to be "going south," and it's going to show time, cost, scope, and possibly, ultimately, quality. One such project for me was a cloud migration. A major data center was being shut down and all the services hosted there had to be migrated to the cloud. When I got involved it was already badly behind schedule, and extra cost had been incurred in renewing the lease on a data center's space while also paying for cloud services. What had happened was a project manager had laid out a very solid plan for doing the migration in waves. It was going to i

The tone on the call was dour and gloomy. The international team I was leading through an Agile transformation had completed its third sprint, and all three were 'bad' in terms of work completed. A senior VP was on the line with me, the co-product owners, a couple of teams leads, and one or two others from the business. We meticulously talked through the various reasons why things hadn't gone to plan, referring often to the retrospective notes that I'd compiled at the end of each sprint with the team. Chief among our problems were story point estimates that were too optimistic, 'emergency' work that came in, and extra work finding its way in without being accounted for. As I've indicated, people weren't happy. And then, it occurred to me that the group wasn't seeing the bigger picture. "Let me ask something," I said, "would these issues have come up if we hadn't changed anything?" Long pause. I asked again: "If we had not

It was really a pretty large group we gathered for an introduction to Agile, and none of them were software developers. This was several years ago now at a major media company where I had been recently promoted to program manager. A senior scrum master was assisting me with the training portion for the archivists who were part of my newly-formed program group. They were going to be part of an Agile transformation that would range from them through the streaming partnership team and on to broadcast engineers. And, importantly, almost none of them had ever heard of Agile before.  Some might wonder why we even bothered with an Agile transformation for such a group. The answer is that 1) we weren't forcing it on them, 2) we really believed it would help, and 3) the PMO was answering a call to help the entire organization become Agile, if possible. It turns out that Agile practices, Jira, and a bunch of librarians combines marvelously. It was something of a wonder how well and quickly t

In the world of project management, which has been my professional area for over 10 years at this point, I learned very early on about the difference between grade and quality. The PMBOK Guide, the central tome of project management, defines grade in part as "a category assigned to deliverables having the same functional use but different technical characteristics." Clear as mud, right? Quality, for its part, refers to conformance to requirements and fitness for use. To explain the difference, let me tell you about my food dehydrator. November of last year (2021) I brought some pears back from my trip home to Missouri. Realizing that I couldn't eat them all, even baking two pies from them, I ordered a food dehydrator so I could save some for later snacking. I found one online with nearly 5 starts and plenty of positive reviews. It's a straightforward device, which can sit on my kitchen countertop, and which has a few racks so layers of fruit can be dried at the same t