Manager Turned Leader. From Tangible to Intangible

Written by Jeff Geiger

Late in 2009 a good friend and mentor of mine was Program Manager across a whole suite of projects that were transformational for our customer. I was a meager tactical Project Manager leading the cutover portion of the implementation of new custom software our customer had developed in the age when the software was still being delivered via CD and installed on a client computer. We had hundreds of people to coordinate with dozens of different brands of computers and they weren’t even owned by a customer of mine. They were owned by the various companies the individuals worked for affiliated to our customers.

Coordination was difficult and complex, much like an orchestra, under the leadership of my good friend as well as the Vice President of the IT organization at the time, we were successful. It was interesting because some key things at play led to our success. None of which were the paperwork I pushed as a Project Manager. All of it was intangible. 

The VP was a charismatic man who later shared with me the story of his journey. While from appearances you might gauge that he went to a prestigious college and had a line that was straight and true, reality couldn’t be further from the truth. I don’t know all the details, by any stretch, but I do know that he wandered in his twenties, figured things out in his thirties, and by his forties, had hit his stride and had become the charismatic man he was.

Under his leadership and over about 5 years, the IT organization laid the foundation for something truly transformative that is now in the rearview mirror. All their systems were antiquated and complex. A sales system that was built on VB and MS Access as well as a severely customized ERP system that, like many other ERP systems, was modified so heavily to be like the system that it replaced as well as to fix inherent problems in the software because it was an early release.

Through at least two of those five years, I have witnessed the changes and absorbed as much as I could, resisting the wisdom that came at first. Under the leadership of the VP, my friend and mentor took command of the entire program of projects and there were a whole host of players on that team that ultimately got us where we needed to go. We had what felt like the most true teamwork I had witnessed to date. Everyone (or most everyone) had a clear vision and was pulling in the right direction.

With everyone at their oar and pulling in cadence, we went live (albeit not without some challenges) and supported the new system. There was some celebration, but the funny thing was that the team didn’t need that. They were so focused on the process and the things that needed to get done, that they didn’t pay attention to the score, let alone that they had won the game!

A few months went by and we were coming out of hyper-care and my friend and mentor pulled me aside and told me that he had to step down and that they had collectively decided that I was the one to take over the remaining several objectives in the transformation. We had only accomplished the first “domino” in a series of important and complex efforts. Immediately, I was honored and delighted, but then fear took hold. I had never done anything close to this magnitude. I didn’t show it but expressed my concern to the VP and to my friend.

Both, to their credit, and I have come to learn through the course of several subsequent projects I have had the chance to be in their shoes and witnessed in me something that they could rely on. Something they could trust. Something intangible. Frankly, I wasn’t sure what that was, because I was so used to getting things done with the tangible leading the charge.

Up until that time, I was successful in running small and mid-sized projects, architecting solutions, leading integrations, leading teams of developers, and on and on, but, how I succeeded was through the use of what I felt was common sense methodology and templates. I managed event to event, deliverable to deliverable. During this phase of my career, I was so focused on filling out templates and facilitating events that everything seemed to take care of itself. It did, but it wasn’t transformational and at times it was arduous and frustrating to the people on the team. It wore people down. It wasn’t rewarding. I mean, who likes being forced into process and paperwork?

In this program, I took over as Program Manager and was also Project Manager of a couple of the projects contained within it. I believe there were five or six projects in total. During the program, I recall an interaction I had with one of my teammates who I had several points of conflict with prior that was terribly frustrating. I thought he was difficult, abrupt, and abrasive. One day, I walked into his office with my checklist in hand and was following up on some missing or late deliverables. He was not only managing the Business Analyst team but also the offshore and onshore developers. About 15 to 20 people.

In my zeal to get the items checked off my list, I asked him status. He looked me square in the eye and said “We’re not doing it. It doesn’t add value, so we’re not doing it.” He wasn’t angry. He wasn’t being cocky. He just said it a matter of fact. I tried pushing back, quickly realizing he wasn’t backing down. I thought to myself, “How can he do that to me?”  “How can he choose not to follow the rules?”  After all, it is in the methodology and it’s on the list of deliverables!

I walked away a little angry and frustrated. I let it sink in. I pondered it for a bit, maybe a day or two and then I realized he was right. I don’t even recall what it was on the list that he declined he or his team did, but I struck it from the list of deliverables. Over subsequent weeks and throughout the program, I reviewed the list myself and trimmed the fat. I listened to him and the team and I found ways to cut out exorbitant amounts of time that could be spent on building, testing, and supporting what we were rolling out instead.

During the ensuing years, I’ve been blessed to be able to participate in efforts building J.Geiger Consulting as well as work in the field on several important projects and each was a step into further learning the intangibles. The program that I was first hit upside the head with the stark reality that paperwork and process aren’t the end all be all continued for a few years with subsequent go-lives of software to include front-end sales software, engineer-to-order-software, automatic drawing creation, and multiple phases of that software. Inevitably, the program had to come to an end…But they always seem to come around again. More on that later.

When I was looking for my next engagement, I ended up interviewing with who was to become a new mentor. We met in person in a small conference room and I don’t remember the questions in detail, but I remember being in that uncomfortable position where I know paperwork and procedure yet I also know there’s more to it. He had an even more different take on things. He was a pragmatist who believed in motion. To successfully implement, you need to keep moving. To keep moving, you need to take action.  The best action to take is to have the Minimum Viable Product (MVP) of a system or program and get into Systems Integration Testing (SIT) or whatever you call it as soon as possible. That action moves projects.

I didn’t think I did well in the interview, but apparently, he also saw in me something that he liked. Much like the leaders of the prior organization, he saw something special in me and I cannot tell you how much I now appreciate that. It is because I was able to plow new ground with people I hadn’t met before, lean on my old habits, and try new things. This client was also embarking on a Digital Transformation (before that was a term) to set the stage for an eventual major system upgrade. The client was significantly behind the times because it sold products via printed catalog when buyers are now so accustomed to making purchases using the internet.

Over the next couple of years, I was able to take what I knew with procedure and process and begin to explore how the intangible can make all the difference. We were a few months into the project I was assigned to as part of a larger program and the CIO had realized things across the program were not moving fast enough. He brought in an expert coach and we put in place Agile methodology.

With the advent of Agile concepts following Scrum, we were able to increase engagement, increase our speed, and invigorate the team. In only a few short months, we were pros at running in an Agile environment. There seemed to still be some residual waterfall project methodology left behind but the new life it breathed into the program and company was amazing. This was an implementation of packaged software with an agile process. It was still somewhat of a square peg in a round hole, but it worked to change the culture. The whole experience with Agile is a topic for another article.

I was stepping from the boat to the shore! It was a great transition from deliverables and events to purpose and the intangibles being the driver! The project went live with different phases over about a year and a half. It was successful.

Finally, in 2018 I had the opportunity to rejoin the customer first introduced above, and fulfill the vision of the charismatic VP and of my friend and mentor. The vision was to pull huge customizations and suites of functionality, that had no business in the ERP, out. We had set the dominos in motion during the projects in 2009 - 2013. Now, in 2018, the company finally had the appetite to take on a major ERP upgrade.

That’s where going from tangible to intangible came full circle for me. I started on the project, essentially, as an errand boy, willing to do anything and take on any of the things that were causing trouble. From my start to an eventual successful go-live, it was almost three and a half years. That seems to be a long time for an upgrade, but in all honesty, it took as long as it had to. They had to go through it the way that they did because it was necessary. Armchair quarterbacks can argue that point, but it just had to take how long it had to take.

There was a point in the project where I realized that there was no end in sight that scope was only understood at a fifty thousand-foot view and that not everything was understood and being tracked. That’s when I took the tangible to the intangible and could put into practice all the things that I had learned over the prior eight years.

The first thing we put into practice:

Break down the work and assess where we were. We took all areas (this project was broken out by area silos not by process stream – that’s a subject for another time too!) and broke them down into anywhere from 5 to 15 sub-processes they need to support that functional area. Then we assessed on a grade scale, A through F, how we fared with Configuration, Development, Reporting, Data Conversion, Cut Over Readiness, Testing, and User Preparedness.  This bubbled reality to the surface!  A and B were shades of green.  C was Yellow, D was Orange and F was Red. Visually, it was a real eye-opener!

The Second thing we put into place:

You need a process to log, measure, and manage your issues. It doesn’t matter the tool, but you need to log your issues and incomplete work, prioritize it (Severity and Priority), and work it out. Actively working on issues for every member of the team needs to be top of mind. Severity is a measurement of “how big of a deal is this” and priority is a measurement of “how should I behave relative to this”. Severity drives priority, but something that is highly severe might not be the most important thing to work on right now.

The Third thing we put into practice:

Burn down the work and track it. You need to get things “Done”. To do that you need to define “Done” and work towards that across the team. You need to track it and make it visible with the team getting done on things and getting them behind them. 

One thing I have found is that it is difficult to get people to understand what “Done” means.  Furthermore, you can take something and break it up and do the most important parts of it and leave the remainder to a point in the future, maybe never. After all, you can keep working on anything to perfection. You’ve heard it before, don’t let perfect get in the way of good enough.

The fourth thing we put into practice:

There were complaints from the team that we had too many meetings and that there was no time to work on issues. How we fixed it was we reworked the schedule as follows:

Bi-weekly Steering Committee meetings where we started reporting out to them but eventually, had the steering committee members report out to their peers. (the merits of this is another subject for a future article).

Weekly all team meetings with report out by area leads. This put the responsibility for burn down and getting things “done” on the individuals responsible for each functional area.

Weekly Technical meetings. These meetings were where it was outside of business process and we could focus on the blocking and tackling of building systems and software.

Because we did this, we were able to streamline the meetings and give back time to the individuals to focus on the work and do working sessions. We utilized this during the build phase only and once we got into testing, the meeting cadence changed to meet the intense needs of testing and fixing with twice-daily check-ins. The main thing is that leaders should be aware of where their team is spending their time, especially in meetings, and be prepared to rethink and adjust as time goes on. The natural tendency is to add meetings and never to cancel them. Before you know it, everyone is in meetings all day with no time to do actual work.

The fifth thing we put into practice:

Detailed, script-based, testing while using the issue system and active management (and burn down) that we already had put in place. The inventor of scripts was based on an assessment done earlier in the project where teammates had done a net change assessment. That net change assessment ended up feeding our test script inventory AND our training preparations. It allowed us to focus on the most important things, where things were different. In testing it is important to do things according to a script, assessing the script coverage, but also allow for what I termed “off-road testing” where end users can go off script and test according to their day-to-day operations and things that aren’t in their Standard Operating Procedures.

Doing these several things helped transform the project and get us pointed toward the ultimate objective which was the daunting task of implementation with zero impact on revenue.

Putting the five things in practice mentioned above, allowed our team to get into a rhythm from executive leadership down to all the team members responsible for the execution of the details. Had we jammed in paperwork and process (deliverables and events) and forced the issue, it would have taken at least six months longer and could have increased the chance of failure.

Instead, we capitalized on the passion the team had for two things. First was their passion for the company and the product. The second was their passion for replacing the aged ERP system. Many of the people on the team had been there when it was originally implemented twenty years prior while some had come in later years and had to provide care and feeding. It is not unethical or immoral to capitalize on people’s passions! Far to the contrary. We were able to get to a successful go-live, improve people's careers, and help them put an aged albatross into their rear-view mirror.

When we finally had decided to go live and had done all the due diligence preparing for it (testing, planning and practicing cutover, risk assessments, etc.)  leadership waited with bated breath as go live approached and hesitated to celebrate for fear of failure that never came. They were afraid to “spike the ball”. Instead, the team stayed focused on supporting after going live, resolving rather quickly the issues that naturally came up with such a huge transformation. Before we knew it, people were starting to roll off the project or transition to other duties and other initiatives. This success allowed them to go on and do other things that had been put on the back burner for so many years.

The number one thing I learned through that process is the old saying that with the right “why” people can accomplish any “how”. Without realizing it, we were focused on the “why” and “what” and let the “how” fall into place with simple things. So, my suggestion to anyone doing seemingly complex or difficult things is to make sure you understand the purpose and internalize it. Second, make sure that everyone knows the objective (what you need to do and at what time with what budget). Then, once you and your team have the purpose and the objective, let the team help determine how to get it done.  Sometimes simple is more important than formal (using Excel to track project tasks vs. MS Project, for instance).

The journey from being so focused on the tools you’re using to being focused on the people that are doing the work is rewarding, if you let it. It starts with being able to let go of old assumptions and ends with building trust with your team.

I encourage you to think about how you can change your perspective from being driven by documents and procedures, deliverables, and events to being driven by purpose and the intangibles of purpose fueled by trust, resolve, and dedication.