When in the last 15+ years someone asked me how to become a senior consultant, I answered: “Get hired as one.”
I meant it as a joke as there are enough companies out there searching for senior consultants. Why? Get maximum value out of a person and client. Assign a senior on a project, charge for a senior. Sometimes you only needed to understand how HR works to be hired as a senior consultant. The proceeding is known throughout the industry, even customers know that the senior consultant they pay for is not necessarily worth the money. Today it is not unusual that customers demand to evaluate a consultant for a few weeks. This is for once to see if the person fits into the team, and to see if the rate is justified. Hint: some senior people are junior, but their engagement is good enough to ignore this to some degree.
While the above behavior is still valid (search for wild west and SAP), in the last years I saw a change happening. I call it the Competence by Title Principle. It’s like the Dilbert Principle. In case you do not know the famous Dilbert Principle: “Under the Dilbert principle, employees who were never competent are promoted to management to limit the damage they can do”.
With the Competence by Title principle, I mean that people who were never competent are promoted to positions where they create maximum damage.
It is not that the person has no knowledge at all. They may have deep knowledge in another topic area. Take a BI consultant being promoted to Machine Learning consultant. Because his manager finds no better assignment, or it sounded like an interesting area. Reasons don’t matter. Now the BI consultant is now not only working in a new area, but also has an outbound function: consultant, evangelist, advocate, director, visionary, VP, etc. It’s part of the job function to show others what the software can and to convince them to use it.
Now to the shift in the last years that makes this dangerous. Everyone knows that you cannot be an expert by just printing expert on your business card. Everyone. Except for one person: the person named to be an expert.
For instance, let’s take the junior consultants that were hired 10+ years ago as senior consultants. At least most of them knew that they weren’t senior. They tried to learn fast and to limit the damage they can do (sometimes). The competence by title people, they believe that they deserve the title. They believe they actually know what they are talking about. That preparing a demo, tutorial, PowerPoint, meeting makes them experts.
Hint: No.
Preparing or demoing a tutorial or presenting some slides does not make you an expert. Real world experience does. Show your scars you earned while implementing a solution end to end at a customer, creating a business plan, justifying the costs, implement, put into production and maintain a solution. That kind of experience makes you an expert. If you do not know the troubles customers and partners are facing day in, day out while working with a solution, you are not an expert. Not knowing this, not having this experience makes you a lamer: unable to understand the consequences in real world.
Where do the experts come from? Software companies sometimes miss a trend. Even when they are located a Silicon Valley or have a global presence. For instance, machine learning or artificial intelligence isn’t new. I learned it in university 20+ years ago. And even then, it wasn’t new. But a company may have missed the. To have experts for a topic available, it takes time. Years. If a company missed a trend, they need to hire experts. If not enough experts want to join, you get creative.
How to spot one of those “experts”?
They are titled experts by a software company for a specific product, but are not part of the product team? They do not know whom to contact at the company to give back feedback? Do not have access to the project board and backlog for the product? Prepare and give trainings that lets the product shine, but are not going into the nitty gritty details? Ignore basic real-world scenarios for SSO, maintenance, roll-outs? For open source products: No commit rights on the project in GitHub/GitLab? What about pull requests, tickets? Provided some useful features? Run regular community events like Meetups? When a demo goes wrong, can they fix it on their own fast?
In all cases: do they have real-world experience, or are they just sit at their desk or travel around the world? Remember: It is not easy travelling a large part of your work time and be fully assigned to a full lifecycle project to gain expert knowledge. Not saying that it’s impossible, but not easy.
The above list is not complete but gives an idea how to spot those experts. Remember: there are real experts out there: working for/at customers. Sometimes working for years or decades on a topic. They know it inside out. They may even have worked on a topic before a vendor found out about it and decided to hype it. You can find at customer events, presenting their lessons learned and battles fought and lost and won. You can find them at a software company, but it is not easy. And if you do, most probably in the product team when they are working closely on real world scenarios together with customers. Rarely demoing some scripts.
What does the competency by title principle means for you? You want to be an expert? Earn it. Being promoted as an expert by your employer, have it on your business card, means nothing. Get some reputation, fill your CV with projects, a lot of projects. Get some scars. Show them with pride. At one point in time, people will recognize you for what you have achieved in projects, and then you are an expert. Until you reach that stage, your expert level is nothing else than a name tag on your business card.
