A long time ago, in blog-years, I wrote a page on Building Documentum Talent. I meant it to be something upon which I could build, but I haven’t. Well today that changes, at least for a day. I’m doing two things. I’ve revised that page some (and cleaned old/non-informative comments off) and I’m going to talk about turning your everyday Documentum resource into an expert in this post.
What Doesn’t Kill You
If you read the title, you may think that torture is involved in the “next” step. You would be right. Over the years, I’ve trained many resources that I’ve identified as having potential, and desire, to become good Documentum developers. That is one of my favorite things about new projects, teaching the joys of ECM and Documentum to young consultants.
Unfortunately, you can only train and prepare Documentum resources so much. You can train them and have them write Documentum applications, but they will NEVER become an expert if that is all they ever do. They may become a senior Documentum developer, but they will not become a Documentum expert. That requires a little more work.
Every ECM project, outside of the simplest proof-of-concept, will encounter some challenges. The next time you hit one that isn’t mission critical to solve yesterday, give it to a Documentum resource. Make them solve it. Make sure that they understand the symptoms and let them at it. Be a resource for them, rarely giving answers, but telling them where to find the information.
A few things to consider first…
- Have they taken, and absorbed, the Technical Fundamentals course? They should also have 4 years of IT experience and 1-2 years of Documentum experience. Use your judgement here to decide if they are ready for the challenge.
- Is the problem mission critical? At least for the first fire, you may want to keep the pressure light. If they’ve been through this before, and you feel they are ready, then go for it.
- Do they have privileges to open a case with Documentum? If not, make sure that someone can open the case and have them work the case. Put yourself on the monitor list for any updates so you can track the case.
The point is to make this a learning exercise, not actual torture. There are times that you have to throw that resource into the fire because there is no other choice. The goal here is to be sure that when that situation occurs, they’ve at least put out one “fire” before.
Nobody Expects the Spanish Inquisition!
Let’s be honest, Johnny Gee and I don’t know it all. There are parts of Documentum that he knows better than I do, and vice versa. Combined, there are parts that any number of Documentum experts out there (Lee Smith, Lee Dallas, and John Kominetz to name just a few) will know better. Documentum is just that big.
Why do we gain the respect of other the Documentum resources with which we work? Simple. When a problem is encountered, we know how to find the solution. We may not know the answer immediately (though sometimes we do), but we know where to look and/or who to ask to get those answers.
How did we learn how to do this? We where thrown into the fire. Most likely, we found ourselves in the fire with nobody to turn to for help. Maybe the acknowledged expert was busy dealing with a bigger fire, or on vacation. We rose to the challenge and learned from it.
At some point, we had more experience than those around us and we became THE PERSON to solve all the Documentum problems. We worked cases with support. We scoured the support site and developer forums when they were less helpful than now. We buried our head in obscure documentation and support notes. We pushed the unlabeled red button and held our breath.
After a while, we knew where to look, plus we knew a lot of things that helped us diagnose problems quicker.
This process never ends. I learned something yesterday. Lee Dallas gave me an answer and John Kominetz told me where to find the answer in the future.
So, find your resource that is ready and throw them into the fire. Just be around to pull them out if they need it.