This post by Charity Majors of Honeycomb popped up in my feed today, and really resonated relative to our somewhat in-bred world of process automation. She is talking about the need to move between software development teams in order to keep building skills, even if it means that you move from a “comfortable” position as the project expert to a newbie role:
There is a world of distance between being expert in this system and being an actual expert in your chosen craft. The second is seniority; the first is merely .. familiarity
I see this a lot with people becoming technical experts at a particular vendor product, when it’s really a matter of familiarity with the product rather than a superior skill at application development or even process automation technology. Being dedicated to a single product means that you think about solving problems in the context of that product, not about how process automation problems in general could be solved with a wider variety of technology. Dedication to a single product may make you a better technician but does not make you a senior engineer/architect.
Majors uses a great analogy of escalators: becoming an expert on one project (or product) is like riding one long escalator. When you get to the top, you either plateau out, or move laterally and start another escalator ride from its bottom up to the next level. Considering this with vendor products in our area, this would be like building expertise in IBM BPM for a couple of years, then moving to building Bizagi expertise for a couple of years, then moving to Camunda for a couple of years. At the end of this, you would have an incredibly broad knowledge of how to solve process automation projects on a variety of different platforms, which makes you much more capable of making the type of decisions at the senior architecture and design level.
This broader knowledge base also reduces risk: if one vendor product falls out of favor in the market, you can shift to others that are already in your portfolio. More importantly, because you already understand how a number of different products work, it’s easier to take on a completely new product. Even if that means starting at the bottom of another escalator.
Sandy – there are several great points in this post (and the linked one!).
This myopia is one of the reasons that while we started our business (BP3) focused on one process engine/suite, we never thought of ourselves as “just that.” We always had an eye toward other products and approaches and understanding them, and delivering successful projects to production with them. It’s why software vendors’ marketing materials aren’t the first thing you see on our site. Probably it has cost us some growth at times, certainly it makes relationships more complicated with our software vendors – as it does any time you have friends who are competitors – but I think for us that path was worth it.
A few other observations I would add:
1. Every time we’ve worked with a new software company with their own flavor of process engine/solution, the software vendors vastly over-value familiarity vs. expertise. They want you to know what is on a drop down on some property sheet buried in their product, vs. understand how to design a process that will work well given the design of their software and its architecture. It doesn’t matter what product we use, we deliver projects to production and create happy reference-able clients. The things that make for happy clients are the expertise things 🙂 The things that make for smooth implementation effort sometimes chalk up to how quickly you can gain familiarity but it is not the highest order bit.
2. there is real value in expertise + deep familiarity with a system. It is easy to discount that value, but having that person available who sees a snippet of log files and knows 3 different thing are wrong with your system, or who just by glancing at your work has a sense for where the major issues – these people are valuable and worth investing in if they’re on your team. (if they have deep familiarity, invest in the expertise to go with it, or vice versa).
3. I’m sure there was a third thing, there always is. Enjoyed reading this!
Scott, thanks for your insights — definitely BP3 is an example of taking the next escalator. 🙂
Deep familiarity with a product is definitely a requirement for design and implementation. However, I would argue that these are technicians specializing in that product, not senior architects that can understand the broader issues. I see a lot of vendors’ professional services people who can tell you about the specific dropdown item in their product, but have no understanding of anything outside their product area, such as how to connect it up with other systems that the client has.
“I see a lot of vendors’ professional services people who can tell you about the specific dropdown item in their product, but have no understanding of anything outside their product area, such as how to connect it up with other systems that the client has.”
you are so right about that- we see it, too. sometimes I’m really surprised and then I have to remind myself that we have a broader approach to the context, there isn’t just one golden hammer, and that means we’re aware of all those other options and design patterns etc.
I have to agree with your article. I personally had the same experience. I was the product manager of an inhouse developed ECM solution focusing on the construction industry. Throughout my career, I gained extensive knowledge in ECM concepts and modules but only how our system operates with limited market research. In the last two years, I started exploring in details top ECM solutions to widen my idea in this domain.
Cheers