Lessons From The Office: Intro

As I mentioned before, this past year my company has undergone a major re-organization. During the six months that Trevor was with us, we gradually reviewed our management structure and internal processes and made improvements across the board. There were a variety of lessons that I learned during this time, lessons that were sometimes learned the hard way.

As a manager with various responsibilities over the years, my principles and my approach have certainly evolved. I compare it to my early days as a professional programmer. I still have a few screens in our flagship software that I designed and I shudder to look at them, knowing the visual flaws and the fact that these screens are almost completely useless.

In the same way, I can look back at my early management style and I can only be grateful to have had so many chances to learn and develop at my company. Heck, I currently handle a lot of the project management duties in my role as Director of Implementations but this is actually the fourth (!) time that I have been in this position.

Just for fun, let me assess the four times that I have been Project Manager.
1) The first time, it was sometime in my second year with the company. We didn't know what we wanted from the role except for a nice Gantt chart, which I never did. There were no goals, no specific responsibilities and no tangible results. I didn't have a clue about what to do. In fact, the only thing that actually happened during this time was that I gained an interest in software project management. I started to read various industry websites and blogs, so I gradually developed a theoretical philosophy about the role and about software designs in general.

2) The second time, we made Project Management into a formal job. This was about a year and a half after I was officially designated as PM, as I vaguely recall. I had to evaluate competing priorities, get input from my bosses, organize work for the programmers and report on our progress. We made a lot of progress during this time regarding this role. After about a year, though, I resigned those duties for two reasons. First, I was given certain responsibilities without the authority to accomplish them. Second, I needed to figure out how to standardize our processes for getting input and for reporting the results and, try as I might, I never did figure that out. In fact, we're still trying to work that out but thanks to Trevor's recent help we've come a long with that recently. When I resigned, those duties were promptly assigned to someone else.

3) I stepped back into the role soon afterwards for a third time for less than a month. That was a silly mistake on my part since it was mostly a response to an urgent need that we had. As I saw it, I still had the problem of not having enough authority so I only requested the right to do one thing, which was review and organize any incident that we assigned to coding. Not that I would decide what went into coding, I just needed to get the related paperwork done to keep things flowing. That sole new process fell apart with the next urgent thing that we had to do and I once again stepped out of the role and went back to full time programming.

In retrospect, I was an idiot in my approach. I framed the problem as a matter of trust and authority, when it could have been framed as a minor procedural aid. I saw greater underlying issues than the superficial problem and I tried to wrestle with those rather than fulfilling the immediate needs. Good times for me, those were. Even if I was justified in my observations, which is questionable, I still had a long way to go in learning how to create healthy change.

4) The fourth time, I stepped back into the role after Steve and Rebecca left our company. The duties for Project Management at that time had grown until it required two full time staff that devoted a majority of their time to these duties. Steve, in particular, worked lengthy hours and even worked from home just to deal with the high volume of incoming development requests and administration work. With their help, we made great strides in the technical requirements of our support software.

Once they left, I simply stepped into their shoes and did the minimum work required to keep the ship moving. While Steve and Rebecca had a very thorough knowledge of everything that was happening, I knew that I could not replace two full time staff by myself so I did what we needed to get by and, not surpisingly, we had plenty of items that went into never-never land.

It was only with the recent re-organization and the new procceses and meetings that we have really made this feasible in a practical way. Our weekly BAM! process now provides the chance to get expert input on all incoming requests. Our versioning system and Product Roadmap meetings provide the means of regular progress updates. We're actually accomplishing more with less work, which is amazing to me. And while I believe that Project Management is a skill just like programming is a skill, and I know that it isn't just a cog in the machine that anyone can fill, we have standardized the role fairly well and it is much easier to accomplish now.

So on that note, I'm going to begin a series of posts that I'll complete gradually, highlighting the principles that I have learned over the years. There are an awful lot of them so rather than try to design an entire essay series, I'll just shoot from the hip a bit more than I usually do. Sometimes they are based on observations of others, more often they're based on my own flawed experiences. And yes, I have given my blog link to all of my co-workers and directly to my bosses so I'm not trying to hide this, as tempting as that might be.

(And ten bucks says that these lessons can be applied equally to churches as well...)