Spotlight Series: Carl Brundage
This is Carl Brundage – experienced architect and the first volunteer for our new blog series – Meet a CTA! We’ve had him as a guest on our podcast before, but this time we wanted to read his story.
Starting out with Salesforce
My Salesforce origin story starts on a warm Summer day, in June 2014. A friend, Karen, had started a new role at a Salesforce Consulting partner. The company wanted to release an App Exchange app focused on eCommerce and she thought I might like a role leading product development. While it was a change from my prior job, both in terms of function and industry, I was excited to switch from a proprietary software stack to something with broader applicability – Salesforce.
On my first day, I was lead from the main office to an adjacent building. Making your way into this conference room required going through another conference room turned into a group work space and into a second, smaller conference room. It would be generous to say the room was eight feet by eight feet. It was one of those small rooms that everyone has to stand up in order for one person to get out the door. In fact, when the walls went up, they didn’t even try to account for the outlets.
Around the table sat my team – three developers – plus an empty chair for me. I quickly learned Neal Hobert, Sean Russell and Peter Knolle were not your ordinary developers. Back in 2014, there were only seven Salesforce certifications available. Each of them had six – Admin, Advanced Admin, Sales, Service, Developer and Advanced Developer. Oh, and by the way, Peter was also a Salesforce MVP.
As I settled in, their conversations turn to the factory-service pattern needed to implement global interfaces that would make the managed package Apex extensible for clients. Meanwhile, I am asking question like, “What’s this org thing you keep mentioning?” and “What’s all the excitement around the upcoming Summer 14 release?”
I think you get the idea about my sizeable Salesforce knowledge gap. In my eagerness to provide leadership to the team, it was important to demonstrate my commitment to Salesforce. Earning Salesforce certification seemed like a good way to validate my resolve to the team, our customers and myself.
The First Few Certs
Admin Certification seemed like the place to start. Now, this was during the pre-Trailhead dark ages. While there was lots of Salesforce content out there, it was not packaged up nicely. Knowing where start and what to trust was tricky. It often felt like drinking from a firehose. Finally, I settled into using the online trainings from Salesforce University as well as hands on practice in my own developer org.
With ten years of prior CRM experiences, the topics themselves were familiar, but the terminology new. I found the breadth of the Admin guide to be difficult. Despite multiple viewings of the ‘Who Sees What” video series and other resources, it was not coming together for me. To their credit, the team was very support, just like the Salesforce Ohana. Each of them patiently took turns answering my questions about basic Salesforce concepts. During one of our discussions, the suggestion to switch focus to the Developer certification was made.
The concepts for this exam made much more sense to me. I felt more confident in the required material and scheduled my first exam for mid-July. I think we all have that moment of trepidation when we click submit and wait to see the results. Good news greeted me, as I had passed. As was the tradition (at least that’s what they told the new guy), I brought in donuts to celebrate the success.
Things got better of the summer. We moved into an awesome new office down town. I also completed four more exams (and brought in lots of treats) to be 5x certified by September. Next, I looked at the two remaining options – Advanced Developer and Certified Technical Architect. It seemed like Advanced Developer might be a stretch but could be achievable with some work. So, I set an end of the year date to take the multiple-choice exam. Looking at Certified Technical Architect made me laugh. No, I thought, that’s not something I can do.
As this is a story about my journey to a CTA, what changed? Over the next few years, many new certifications were released. As I worked to earn each new one, my knowledge expanded into different areas of the platform. The spring of 2016 saw the launch of the designer exam series. For these, I participated in the beta program, taking and passing three of them in one week and the other three in another week. The preparation for the exams lead me into areas of Salesforce that I didn’t even know existed. Concepts like LDV, SSO, SAML, IdP entered my vocabulary, as well as knowledge on how to incorporate the technologies in solutions. Most importantly, I brought more wisdom to projects and delivered better results to clients.
The New #JourneyToCTA
During Dreamforce 2016, I attended a session by Suzanne Ford on the new journey to the CTA that debuted the now famous pyramid. Rather than the prior jump from a multiple-choice exam to the review board, there were a series of steps and checkpoints along the way. Based on my certifications, I would automatically earn System and Application Architect in February 2017 and be Review Board eligible. Suddenly, being a CTA no longer seemed impossible. Being impatient by nature, I set my sites on a May or June 2017 Review Board.
Fate, as usual, had different plans. As the new process was being established, there were a few more checkpoints along the way – a survey, discussion with an existing CTA, etc. So, my planned dates did not happen. However, reflecting on the experience I wasn’t ready. Thinking that passing a bunch of designer exams and then going right to a Review Board is not realistic. I hadn’t even studied an example Review Board scenario or given a practice presentation.
Over the coming months, Salesforce released additional resources that were very helpful. System Architect and Application Architect online courses provided a framework on how to approach solving real scenarios. Even better, there were walkthroughs of example scenarios and several to practice on your own. There was now an actionable framework I could apply to client projects as well as the Review Board. But, there was still more resources to be released and preparation that was needed.
Although I worked for Salesforce partners, the companies were small. Many of the larger organizations have formal CTA preparation programs with mentorship from existing CTAs, mock Review Boards and lots of support. I was mostly on my own, relying on friends for feedback. August brought an opportunity to attend a Salesforce lead review session/preparation class for partners in late October. While I had been intermittently preparing for the Review Board, it was time for dedication to the cause. I didn’t want to show up for this session unprepared. I wanted to put the best version of me out there.
The Truth About the Review Board
For anyone considering the CTA, it’s not a “well, I think I will do it” type of decision. You need devote substantial time and effort with the support of your company and your family. For me, this meant pretty much every free moment was devoted to preparation. Often this meant waking up at 5 am to review integration scenarios before the rest of the family was up and the work day started. Rarely did a night or weekend go by where I didn’t spend hours on CTA topics after running our four kids ages 3, 5, 7 and 9 to ice hockey and other activities.
Attending the review session was a great experience and provided three benefits. First, it refined my communication skills. Specifically, the need to accurately and concisely articulate technical information. For example, it’s not credentials that are passed with SAML, rather a token. Or, a workflow fires on a record change and sends a SOAP-based outbound message with session information for an ESB to call in to obtain additional information from a related object. Using the right words, without anything extra, was key to demonstrating knowledge and effective time management.
Second, it refined my presentation approach and artifact creation skills. While I could get through a scenario, I was unsure of the best way to present. Solutioning a mock scenario and presenting it to fellow attendees as well as current CTAs was invaluable. It provided insight into methods that worked and what to avoid. After the presentation, my approach had solidified. My communication style differed from most. I would not pre-draw all the artifacts on large sheets of paper. Rather, the first 15 minutes of the presentation would be drawing and explaining the system landscape, object model and role hierarchy. The remaining time would cover the solutions to each functional requirement, one by one. It’s important to mention that there is not a right way to handle the Review Board. You have to do what works for you, rather than trying to mimic someone else’s style.
Third, it made it painful clear the knowledge gaps I still had. Like many of us, Identity was one of my weakest areas. I could not clearly draw SAML or OAuth flows like the back of my hand. I created a study plan of what to cover before the board. While I had planned to only review all the Identity Designer exam material, the content of the exams was much more valuable when working through scenarios. Instead, I worked through all the material for every designer exam again before the Review Board.
The final outcome from the session was a confidence boost I needed. Andy Ognenoff, a current CTA and MVP, took a few minutes at the end of the class to say that he thought I was ready for the board. This got me over the self-doubt to schedule for the next Review Board in mid-December.
Planning for the Big Day
In the final push before the Review Board, I obsessed over replicating the Review Board during practice sessions. I had saved a few full scenarios for this final push by not looking at them previously. I bought a white board for home and practiced drawing out diagrams while standing up. Review Board sessions were scheduled at three times of day – 7:30 am, 10:30 am and 1:30 pm and lasted about four hours. I am sharper in the morning, so the afternoon session was out. I also can get grouchy when skipping lunch, which meant a 7:30 start was right for me. It also helped the Review Board would be in the same time zone as home. My practice sessions also started at 7:30 am, with a printed scenario, paper and pencils and a count-down timer. After building the solution, I would take a break and then stand up a present with the clock running.
The same attention to detail carried over to my onsite preparation. As winter was coming, icy conditions and flight delays were possible. So, I flew down to Atlanta early with an extra day to spare. My hotel was a few blocks from the Salesforce office, but I still practiced the time it took to get there. I planned out which restaurants and meals to have, avoiding options that would make me feel groggy in the morning. That extra day that I had before the Review Board was a vacation day, without checking work email. No work emergency was going to distract me from what was to come. I reviewed my weaker topics from my study notes, but not too much. I was also sure to have some fun, going out for a walk, checking out the holiday lights and enjoying a favorite, seasonal movie – National Lampoon’s Christmas vacation. While all of this may seem obsessive, given the amount of time and energy preparing for the Review Board, I didn’t want something avoidable to trip me up.
How It Went - The Presentation
Review Board day went mostly as expected. I did fail to account for Atlanta being further west than my home in Pennsylvania. This meant it was dark for my walk to Salesforce and registration, instead of daylight during my dry runs. The rest of the setup was spot on. I had a printed scenario like the examples provided. There were paper and pencils as well as a count-down timer and proctor. In a quiet room, the proctor’s tapping and typing on his tablet was distracting, but had to be ignored. I followed my approach of working to get the object model and landscape set and then solving the functional requirements. I left the two hours, with only one item circled that I didn’t have a solution that I was happy with. The presentation also went according to plan. I drew and explained my diagrams, then explained how to implement each functional requirement. I skipped the one that I was unsure of, then took a minute or two to compose an answer at the end of the session. I believe I had about 3 minutes left that was added to the Q&A.
A short break while the judges conferred gave me an opportunity to mentally assess if I had covered what I wanted. While I made recommendations for items like an org strategy, development approach and integration, but had not clearly stated a mobile recommendation. I expected questions on that topic and formulated my responses. I also ran through the identity flows again.
How It Went - Q&A
Then came the question and answer portion. I expected “how” and “why” questions. The “how” meaning I did not explain in enough detail how something works. The “why” meaning I did not sufficiently tie a solution back to requirements. I thought the questions were tough. Make that really tough. It quickly became apparent that I had missed something in my object model. There was an initial paragraph that I did not interpret correctly. It was not time to panic. I took a moment and studied the change and its impact on other areas and adjusted accordingly. Through the questions, I also found I mislabeled ownership on a child in a master/detail and corrected it as well. It’s okay to adjust during the Q&A, just be sure to not panic, understand the impact and make the change. Don’t go back and forth or your solution will become suboptimal.
How It Went - The Aftermath
I was very demoralized after leaving the Q&A. Despite a parting pep talk from Suzanne, I was convinced that I had not passed. Did I mention that the questions seemed really hard? It’s one area that I did not prepare for in-depth. The call home to share my impressions left me on the verge of tears. Not because I thought that I failed. Rather, I felt like I let my supporters down. My family bore the expense of the time and effort devoted to preparation. I wasn’t sure I wanted to put them through more. At this point, the only thing I could do was wait. I was going to enjoy the upcoming holidays with the family and not look at any CTA material.
After a two-week wait (that felt more like two months), I received a phone call from Suzanne with very exciting news – I had passed. I certainly was elated and happy to share the news with my friends and family. The congratulations from folks throughout the Salesforce Ohana, many of which I had not met before, was overwhelming.
Now I’m a CTA
Now that I am a CTA, what does it mean to me? First, it’s about confidence. I have conversations with customers that would not have occurred before. It makes me look at customer challenges and requirements through a different lens and ask questions that drive a better solution, earlier in the process. Next, it means a continued commitment to learning. With three releases a year, new acquisitions all the time (I’m looking at you Mulesoft) and a continually shifting technology landscape, there is no resting on what you currently know. Today’s solutions become tomorrow’s legacy and a CTA needs to always be in learning mode. Last of all, it means freedom. Freedom in the ability to shape your career in the direction you want it to go. That’s my story and I am excited to see where it goes next.