Rotate

Please rotate your device.

Our website uses cookies to ensure you get the best experience while you’re here.

Swirl

Wisdom from a Veteran Consultant

By: Bill FitzPatrick

Smiling senior mentor supporting young intern showing achievement result online on computer screen

How I Became a Consultant

I saw an ad in the Sunday Boston Globe (that was how you found jobs back then) for “Bored Accountants”. Well, I was an accountant and I was definitely bored so I figured I was qualified. That was over 30 years ago, and I have never looked back.  Here are a few lessons I learned the hard way.

Don’t be afraid of mistakes, and if you make one, learn from it.

When I began my career, the rules of software development were still being formulated and developing software was considered an engineering task, but a structured development process was needed.  I believed developing software was more of a creative process.  I would sketch out what I wanted the software to do and then develop the key components to create the “golden thread” to see how the components would work together.  I filled in all the intermediate, remaining parts to drive toward the final product.  I learned not to be afraid of mistakes, but to learn from them as they can often contain more value than successes.  I also learned not to shy away from an area considered specific to a type of role, but to learn from all aspects of the business.

Presentations should be simple and straight to the point with a focus on solutions.

Early in my career, I was project leader on a major release of special concern to a senior executive.  I put together a detailed project plan highlighting all the potential issues and resource requirements for us to review.  I proudly presented my detailed project schedule with a thump on his desk.  He looked at it, flipped through it, and quickly tore it in half and threw it in his wastepaper basket.  He said it was my job to figure out how to get the work done in the required time, and I was being paid to provide solutions not problems.  From this mistake, I learned that executives don’t want details and they don’t want problems.  They want straight forward concise information and recommended solutions that they can act on.

Make sure you understand all facets of a problem before creating a solution.

A large consulting company performed an analysis of my client’s product offerings, and the result was a simple grid where the columns were products and the rows were the environments.  The result was a relatively simple grid of 50 or so nodes.  This was used to advise the executives in making product decisions and show the level of complexity in supporting various configurations.  Using this grid, several key decisions were made at the beginning of the year.  However, during the year we began to feel the strain of these decisions and I decided to revisit this grid.  I performed a detailed analysis of all the operating systems involved and the related release levels.  The simple grid exploded from 50 nodes to several thousand.  Since the primary cost driver for a software company is support not development, the result was an immediate change in strategy and a drive to limit the number of supported environments.  The problem was that an incomplete model was built that over simplified the real life situation.  A half-baked analysis can be far worse than no analysis.

Know your role in a meeting and make sure you are completely prepared.

At a design session with the subject matter experts and the sponsoring executive, I expected to provide technical expertise.   After the group gathered, the senior executive gave a brief, welcoming speech and introduced me as the meeting facilitator.  I was taken by surprise; I collected my thoughts and formulated a strategy for how to structure the meeting.  I was sweating pretty hard through the meeting, and when it was over, the senior executive ensured I understood that I was never to come into a meeting unprepared again.  I learned the hard way to clearly understand your role and to be well prepared.  I consider a meeting successful if it ends early, goals are met, and everyone leaves with the feeling that they have succeeded.  If the purpose of a meeting is to make a decision, complete enough pre-meeting work so that the decision is already apparent and the only real purpose of the meeting is to confirm that decision.

Work hard but have fun.

Enjoy your work. A good attitude, like a bad one, can be infectious. So if you are going to spread something it might as well be something that makes people feel good.  If you are asked  how you enjoy your work, respond truthfully that you love working with the people, that the company is a good place to work, and that you look forward to coming in each day.

no-headshot

Bill FitzPatrick

Consultant

More posts from this author