We all have the same goal, a smile on the face of our users. We try to get as many features to our users as possible. Unfortunately, we often try to figure it out as we go. We don’t have time to research the topics at hand thoroughly. Often Trial & Error is the easy way to go at first but leads to negative consequences in the long run. The negative consequences of Trial & Error lead to slower project progress and worse quality. In my opinion, we should stop being Trial & Error Novice but become Meisters of #studyBeforeYouDo.
This article explores the negative consequences of Trial & Error but also shows a more healthy way forward at the end.
This article is part two of a two-part series on the changing role of Salesforce Admins. Part one: ‘#AwesomeAdmin: Time to Reconsider the Role Salesforce Administrators Play?’ written by Paul Ginsberg covers the history and change within the profession of Admins over the last year.
Part three deals with “Why Admins are already architects without knowing it” and will be released in the next weeks.
Table of Contents
- Trial & Error Novice
- Trial & Error as the way to go
- Excurse: Agile vs. Trial & Error
- Downsides of Trial & Error
- Meisters of #studyBeforeYouDo
- Strategy: #studyBeforeYouDo Meister
- Thank you
The article is my personal opinion at the time of the writing. I understand there are many reasons to do something one way or another.
The article relates to the average, the 95%, Salesforce projects. In these projects, we build something done before. I understand, that there’s a small percentage of super innovative projects where we do something nobody has done before. The following does not apply to these super innovative projects.
Trial & Error Novice
Your partner and you walk into a restaurant for a special night out. You have been planning that evening for quite some time. After careful considerations, you place your orders. The waiter takes your orders but informs you: “Our cook never made these dishes before, but don’t worry, she will figure it out.” After an hour you are still waiting, when the waiter finally lets you know: The cook has it now figured out, mostly. Unfortunately, he failed to create parts of one of the dishes. The other dish got cold in the meantime. Since you are very hungry, you eat it anyway. The waiter hands you the bill informing you, that since the cook needed to do more research the dish got 40% more expensive.” That sounds unacceptable for a restaurant, doesn’t it? Nobody would ever go into such a restaurant.
Trial & Error as the way to go
If you replace the restaurant with a Salesforce project, that starts to sound very familiar. We always try our best but often enough we don’t have all the required knowledge for the task at hand. Sometimes we are open with our project partners about our shortcomings, sometimes we aren’t. Despite our lack of knowledge, we try our best and somehow make it work. Honestly, sometimes it even feels great to be the Queen of Trial & Error.
I’m although guilty of Trial & Error. Too often I’ve been there. Just last week I skipped a (very short) guide “How-To to create second-generation managed packages” and started coding right away. My guess was, I figure it out as I go. It can’t be that hard.
You all know how the story ends. Instead of spending an hour reading the documentation, I wasted a day trying to figure it out. After failing over and over, I gave up and start over. Less than an hour after reading the guide, everything was set-up successfully.
Once again, I became a Trial & Error Novice. There was a perfectly good recipe but I chose to ignore it. My excuse was: “I don’t have time for reading documentation”. But honestly, I was just too lazy.
And one more time, Trial & Error held me back.
Excurse: Agile vs. Trial & Error
In my opinion, Agile and Trial & Error mean not the same thing. Agile means we don’t know what to build but Trial & Error means we don’t know how to build.
In our Restaurant Trial & Error means we don’t know how to properly cook some potatoes while agile means we try a new combination of potatoes with mashed pees and chilly.
Or in Salesforce speak, agile means we don’t know what label of the button should be yet. We will define that later. Trial & Error means we don’t even know how to build the button in the first place but try to figure it out somehow.
Downsides of Trial & Error
Dave Massey and I came together and realized: Trial and Error cause five main problems. It forms bad habits, it makes me inefficient, creates fear, produces bad quality, and at the end makes for unhappy customers.
Forms bad habits
The worst thing about Trial & Error is that it is a breeding ground for bad habits. While figuring something out I often find by accident a way how to make something work. I don’t actually understand why it works, all I know it gets the job done. Since it worked once you will keep on doing it the same way going forward. That’s how habits are formed. Maybe the thing you accidently discovered is far from optimal or very inefficient, you will likely never know.
If you study before you work you can learn best practices from others and hopefully not fall into bad habits.
As in my story most of the time we start working immediately because it feels faster. I’m too busy to read the documentation, I’ve to get this done now. Yes, reading the documentation and maybe even practice along as well as taking notes costs time. I think the initial investment always pays off. Trying to figure it out while I go makes I read the documentation anyway, the difference is I miss some steps, make mistakes, and get stuck. Often I have to re-do it again anyway.
If I’m honest to myself the most efficient way of doing something is: Do the trailhead module, read the documentation, practice, take notes, think about the implementation and only then start working.
There’s a certain feeling when I need to do something I’ve no idea how to get it done. I sleep badly, I’m nervous and start to sweat. Throughout the whole project, even after go-life, I’m in a constant state of fear. I think our customers can also recognize that fear and become fearful themselves. Some customers react the opposite way and try to use our insecurities against us. Both, pushy as well as fearful customers, lead to bad project outcomes.
“For me, it’s one of the most uncomfortable things I can think of” is as Kid Jansen puts it in his great Video.
This feeling of fear might be the main reason that I became CTA. All the training I got in my #journeyToCTA made me more relaxed in front of the customer. This in turn makes my customers more relaxed during the project.
Using the Trial & Error method I often enough don’t fully understand why something works (or doesn’t). Therefore, I can’t judge if the thing I built is of good quality. Other times I know that it’s of bad quality, but since I don’t know any better can’t do anything about it. Furthermore, during the Trial & Error process, I try lots of stuff and often am too scared or lazy to clean up after myself. This leaves behind a lot of useless or even harmful stuff.
If we learn before go and maybe even practice, we can produce so much better quality. This will lead to cleaner implementations, fewer bugs and better, long-lasting solutions.
All of the above and so much more creates unhappy customers. Starting from the bad quality over the higher price to the insecure consultants we have a recipe for disaster. Best case the project gets done somehow but for sure is not built according to best practice in the most efficient way possible. Worst case the project completely derails.
Often, we think the customer wants us to work in the Trial & Error mode. We claim we do it to be done quicker, but I think that’s an excuse. I’m pretty sure no customer will refuse a one-week delay in the project start to give the consultants time to brush up on their knowledge. And yes, it costs the company money to train employees but an unhappy customer is much more expensive.
Meisters of #studyBeforeYouDo
In Germany, we have a three-tier system for most professions, including cooks. Not all restaurants follow that system, but the better ones generally do. You start as a novice, after that you become an apprentice. Only starting from apprentice, you are supposed to be running a kitchen. If you go even further, you become a Meister. Being a Meister shows your professionalism and allows you to train novices yourself. I think in the Salesforce world we could do something similar.
Translating the concept, I suggest each level relates to a specific Salesforce topic like Sales-Cloud, project management, or APEX development.
You just started to break into a field. You do Trails for that field and get the first experience. You can’t yet work on projects independently and need supervision from an apprentice. Your goal is to become a (Certified) Apprentice.
You become an apprentice once you have all the necessary Trails and did the Certification. Additionally, you have a bit of real-world experience. You can work independently but still can benefit from a Meister being around.
After you got your Apprentice status you continue to study. On top of theoretical knowledge, you are in exchange with other Meisters of that field. You always keep up with the latest developments. You can guide and teach others in your field. Your customers can fully trust you to their every project a success.
Strategy: #studyBeforeYouDo Meister
Unfortunately, there’s no shortcut to becoming a Meister. But with some effort and practice, you will get there, one step at a time. The following is my strategy to become a Meister for a field.
1) Assessment & Transparency
The first step is, to be honest with yourself and the people around you. People often tell me “you fake it until you make it”. I don’t like that approach. I don’t want to fake it, I want to be honest to my customers, my colleagues, and myself. Assess the task ahead of you: Do you feel comfortable solving it? Communicate the assessment to your colleagues and stakeholders. In an agency context, please develop an adequate strategy with your company about transparency around your assessment. Once you made your assessment transparent, you develop a plan on how to close your gaps.
2) Professional learner
To become a professional learner you need to get into an efficient habit of studying. Important is to find a way that allows you to learn timely, efficiently, and successfully. Find a way that allows you to take a topic like Field Service Lightning and learn it within 14 days (timely), in 40-80 hours (efficiently), and to the delight of your customers and colleagues (successfully). Make sure you find a way that works for you. Once you found something which works for you, standardize it.
If you like inspirations, Kid Jansen’s video is a great way to start.
3) Apply and share knowledge
While you learn for the task ahead of you, take notes. Notes make it easy to apply your new knowledge. I find sharing knowledge a great way of solidifying newly gotten knowledge. You can share your knowledge not only with your colleagues but also with your customers. This will allow you shine as a trusted advisor.
As with everything in life, practice makes perfect. Studying is something you can learn like everything else. The more often you do #studyBeforeYouDo the easier it becomes. At some point, it just becomes part of your job and you don’t have to think about it anymore.
And with that, I summarize this long post. I hope I gave you some inspiration on how to become a #studyBeforeYouDo Meister instead of a Trial & Error Novice
This post was a collaboration and many people helped. Special thanks to Lilith Van Biesen, Neha Nagori, David Masse, Paul Ginsberg, Sergey Erlikh and Kid Jansen.
Comments are closed.