What really matters
In my humble opinion, there are two things that really matter:
1. You, and the skills, knowledge and experience you can bring to bare for the benefit of your client, and
2. Your Client, and the value they can derive from your services
YOU
What is your ‘value statement’? what can you offer now, and into the future? You may be an expert in one of the frameworks or methodologies listed above. Is that good enough? Do you really think that every client issue can be fixed by your expertise, and that that is the only way it can be addressed?
Future-proof yourself by broadening your knowledge. Become a ‘T-type’ person. This means that you have depth in one area, and have foundation knowledge of others. Know where the other frameworks kick-in/overlap. Have the ability to apply more than one perspective to a problem.
If you're an ITIL expert (for example), I would recommend you include foundation level understanding of DevOps, Agile, Testing, Security
and Lean, as a minimum. As each of these disciplines are expanding (see previous postings in the series), there is greater overlap in the areas they address. ITIL expands into non-IT. DevOps, into all things IT, Agile applicable everywhere. The overlaps increase. You need to be able to appreciate these overlaps. So as to draw from several where needed.
As an example, if the client’s issue is that they are not getting the customer feedback, you can draw from ITIL, DevOps, Agile, Lean and others. Each has an approach to such an issue. Offer your client the versatility to look at options.
And now the ‘T-type’ person should be looking at becoming a ‘π-type’ person. Have a backup area of deep knowledge. Expertise, especially very technical knowledge, can become quickly out of date. I still consider myself to be an expert programmer in Cobol. Not a great demand for this skill anymore.
This approach, of being a ‘π-type’, can future-proof yourself. When the next big thing comes along, you need only study the basics, and relate it to your current knowledge. This is how I took on the Sire Reliability Engineering role. It is very technical. I will not be an SRE, but I do know what they are expected to do, when best to use them and how they can be expected to employ Service Management (ITIL) practices.
17