Part 9 of Robert Wing’s personal
#JourneyToCTA

This section describes and assesses various steps I took to prepare for the CTA board. I’m skipping details of the knowledge sources (Trailheads, help, documentation, etc.), as these are well covered elsewhere.

Most Effect Study Techniques

Part 8 of Robert Wing’s personal
#JourneyToCTA

Salesforce Certified Technical Advisor Test Q&A

After the presentation portion was a much needed 20-25-minute break. This provided a chance for water, restroom break and a snack.

I used this time to think back through what I had covered during the presentation and if there were points I wanted to particularly focus on correcting during the Q&A. The Facilitator explained that while I was doing my review, the judges were reviewing their notes to organize questions generally in the interest of my doing as well as possible on the test.

I was brought back into the room and the Q&A started. The questions followed a common cadence:

• Question starting specifically from a point in the scenario
• My answer
• Clarifying points, quite rapid and pointed
• Clear closure of that question and on to the next one from a different judge (this was my insistence on getting them to agree I’d answered the question or not)

Part 7 of Robert Wing’s Personal
#JourneyToCTA

Even Professional Presenters Can Improve

I found the presentation portion to be the most difficult part of the test. I like to think of myself as a professional presenter and I like to tell a good story with well-prepared and relevant supporting materials. One that presents functional solutions in the form of processes for actors, data in the form of lifecycles, and technical requirements in the form of benefits realized and problems avoided against solutions. This simply was not possible.

The problem was that;
(a) there wasn’t time to prepare suitable artifacts to support that,
(b) telling a story like that it’s tough to make sure you hit every requirement, and
(c) I was plowing through a long list of complicated and intricate requirements items, items that I only partially memorized.

How I Could Have Done Better

In hindsight I was probably too tough on myself trying for too smooth of a presentation. Watching the provided example of a good test by another CTA he had a number of pauses in his presentation while he organized his papers or thoughts just as I had; that’s likely the nature of the beast here due to the time pressure and magnitude of what’s being covered.

Part 6 of Robert Wing’s personal
#JourneyToCTA

The Fastest 45 Minutes EVER

There was about 20-25 minutes between completing the prep time and starting the presentation. I just sat down and rehearsed the presentation in my head and anything I’d need to voice-over to what I’d been able to draw.

The Facilitator got me and brought me into the conference room for the presentation and Q&A. I introduced myself to the judges. During this period I had an opportunity to arrange the room how I wanted it before the presentation timer started. This turned out to be a training-class-focused room and the initial setup wouldn’t have worked well for me with a lectern on one side of the room.

• I moved the flip chart papers around to where I wanted them.

• I tested the PC I would be presenting with to make sure slides and document changed well and I understood how the AV system worked.

• The room had a training-style layout where it emphasized standing at a lectern and presenting slides on the projector. I don’t lecture from lecterns and most of my work was going to be with the flip chart papers I prepared earlier plus white board, so I had a minute or two to figure out how I was going to handle the room.

I then presented my solution for the 45 minutes allotted. The judges took notes and checked reference materials as I was presenting. This was a bit different than my usual presentations where the audience is more interactive, but not altogether unlike an RFP presentation where the vendor is permitted undisturbed time to present their solution and the customer take notes.

In part 7 I’ll explain how I discovered my greatest weakness along with lessons learned, so you don’t make the same ones.

About Robert Wing, CTO, aMind Solutions

I’m a manager and architect focused on early-phase software product and project delivery.  I focus on building the right things, building them correctly, and delivering them reliably.
As a partner in a ~100-person consulting and software business I do a bit of everything – marketing, negotiation & selling, estimation, planning, contracting, solution design, technical design, project management & governance, etc. – with a focus on being “the product guy” and “the details guy” amongst the partners.

Part 5 of Robert Wing’s
#JourneyToCTA

Highlighting for Success

I had a specific highlighting plan for the scenario, to help avoid misses. I brought my own highlighters and this worked very well for me.

I created the presentation before reading the scenario – it didn’t have anything scenario-specific in it – I knew what all of these would be based on the practice scenarios at a high level – topics, guiding principles, assumptions (most of them anyway).

I read the scenario from the start through the functional requirements, highlighting as planned, then drew:

• Actors & Apps artifact
• Systems & Interfaces artifact

Next I read the rest of the scenario highlighting as planned, then created:

• Role hierarchy artifact
• Data model artifact
• Entities, Sharing, and Owners artifact
• Salesforce licenses on the Actors & Artifacts artifact created earlier

I then went back through the scenario front-back and for each item:

• Noted key-word solution hints next to each item in the margin to help guide me when presenting
• Cross-checked that solution against my artifacts and corrected any misses or errors

This left about 5 minutes at the end to check it all over and look for misses and mistakes and empty spaces, and to write fast notes to remember to cover on things I’d be presenting without benefit of backing artifacts.

I was able to create the artifacts I had planned to create within the time limit, and got value from most of them in the presentation.

Welcome to Part 3 of Robert Wing’s personal
#JourneyToCTA

Test Taking Action Plan

The practice scenarios had all followed a reasonably common structure, and I optimized my plan as best I could to match these with a summary, actors, current systems, functional requirements, record visibility + SSO, reporting requirements, process & system & organizational challenges.

My strategy was to create 6 artifacts to bring into the presentation, one per flip chart paper for the diagrams.

Next in the series I will outline those scenarios I had planned for, but were dropped to conserve time.

About Robert Wing, CTO, aMind Solutions

I’m a manager and architect focused on early-phase software product and project delivery.  I focus on building the right things, building them correctly, and delivering them reliably.

As a partner in a ~100-person consulting and software business I do a bit of everything – marketing, negotiation & selling, estimation, planning, contracting, solution design, technical design, project management & governance, etc. – with a focus on being “the product guy” and “the details guy” amongst the partners.

Part 2 of Robert Wing’s personal
#JourneyToCTA

Ok you’ve done all the prep, getting good sleep, staying off your phone, wearing comfortable clothing. Now here is how your test taking day is likely to go, based on my experience

Who You Will Meet

A Facilitator will greet you, take you around, explain everything, facilitate logistics, and probably a bunch of other stuff I didn’t even notice. The facilitator will be the main person you will interact with.

While you take the test, the Proctor will sit with you. I had expected them to take away my phone and watch and shut me in a room, but how it works is they sit in the test room with you. Yes, they made me take off my mechanical watch.

Three CTA Judges will evaluate your solution presentation and perform the Q&A.

Taking the Test

The Facilitator met me in the lobby and brought me upstairs for a quick brief on what would happen before the test started. I had 10 minutes to kill with the opportunity to use the restroom and grab any beverages or snacks from the break room.

We went to the conference room for the scenario prep and met the Proctor who was going to sit in the room with me throughout the test.

When I was ready, and it was open to me to declare when that was (within reason I assume), the Proctor handed me the test with one hand and pressed the start button on the timer when my fingers touched the paper. Timing was very precise.

I worked intensely on the scenario for the 2 hours allotted. The timer buzzed and it was hands-down. The Facilitator gathered up all the artifacts and took them to the presentation conference room which was separate from the prep conference room; I wasn’t allowed to move them.

In my case, I did the prep on a Mac but had to present on a Windows machine because someone else was going to use the Mac for their test. The Facilitator used great care to not accidentally lose the files while moving it all around.

The Test Scenario

Obviously I can’t go into specific details of the requirements, but it was HARD; distinctly and materially more difficult in three specific ways than the practice scenarios I had done.

1. It was on the long end of the 7-9-page-plus-title-and-contents expectation set. This doesn’t sound like much, but it adds up when you’re under the clock.

2. It was objectively at least a third more difficult than any of the practice scenarios I’d done in terms of the total number of moving pieces and interested parties and processes and problems to solve.

3. Comprehensive domain expertise was needed to tell the entire story of marketing. From suspect to prospect, sale, onboarding, delivery, support, upsell and cancel lifecycle of the customer. The direct requirements of the scenario were just complicating details of that cycle. The practice scenarios provided more help here to make the presentation easier.

In Part 3 I will cover my test taking action plan. Stay tuned.
Or start here to read the entire series.

About Robert Wing, CTO, aMind Solutions

I’m a manager and architect focused on early-phase software product and project delivery.  I focus on building the right things, building them correctly, and delivering them reliably.
As a partner in a ~100-person consulting and software business I do a bit of everything – marketing, negotiation & selling, estimation, planning, contracting, solution design, technical design, project management & governance, etc. – with a focus on being “the product guy” and “the details guy” amongst the partners.