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.
Word of Pie 
I am flatered to be mentioned here.
I have found there is a singular quality that seperates the expert from the merely competent. Curiosity. Its not enough to know how to fix it – there has to be a desire to know why it broke in the first place. Most people are content (emphasis on the 2nd syllable) to just get it running and pick up the next task in the inbox. When you find somebody that has initiative to go looking for root cause on their own you have a potential winner.
LikeLike
Thanks Lee. You have hit the “desire” aspect of the role. If they don’t have that, then they are not the ones to be focusing on for growth.
LikeLike
I will take Lee’s statement one step further and say that one may have “desire” to learn about the technology, but its “passion” that keeps us here for the long haul. You dont become an expert overnight and when the passion dies, the desire disappears as well. Sounds like a marriage eh 🙂
LikeLike
Well…though the post smacks of Been There ..Done That..its cool because u guys hv really been there and done that 🙂
LikeLike
Good post. But your “into the fire” theme hits on something that is not at all unique to Documentum. I experienced it here when I was rolling out the Stellent new consultant mentoring program. I see it still at Oracle whether with consultants, partners or Sales Engineers.
The thing that makes the difference is an attitude (it’s been tagged as passion above too).
It is the difference between hitting a problem and *always* asking someone to fix it/solve it for you and hitting a problem and diving in to figure it out (with help/pointers/advice etc).
The thing that makes a good expert for any system is a willingness and attitude that *owns* the issue and seeks to discover and understand the answers for itself.
LikeLike
Billy, thanks. You are correct that this post applies much more broadly than to Documentum experts, but I thought of that after I hit “Publish” and decided to just leave it as is.
As for the attitude/passion/curiosity…you are correct. The problem is that I know it when I see it. When I see it, off into the fire the person goes.
LikeLike
Point taken and infact that is something many mentors are even doing… I have been involved in mentoring associates on Documentum and grooming them to a level where they can deliver on their own with minimal/no help.
After initial mentoring, if they are really put on some small projects/assignments, it really helps…
I might be talking a bit out of context so I leave the decision to you to accept or reject the comment. However I would like to share some of my observations on the outcome of the efforts put in mentoring :
1) New IT entrants(fresh IT graduates) are the ideal candidates for grooming(looks difficult but thats my observation)
2) One having a strong application programming background understands the concepts very fast but quits also with the same pace
3) The kind of assignments(say customization, tbo/sbo/, product deployment and using out of the box) that one gets play a major role for deciding how long one would stay with the product.
4) Grooming should be done in all areas may it be administration, web framework or ECM and Documentum basics
5) Some means (other than certifications) of tracking ones’ knowledge is very much required (especially to know where one resides in the bigger picture)
I thought to share above points as these might play a crucial role when we are really looking at the benefits after the mentoring efforts
Kind Regards,
Ashish Srivastava
LikeLike
Also brings to mind character traits called work ethic / diligence. Both easy to say and but only proven by actions when in the fire…
LikeLike