Discovering My Greatest Weakness

November 6, 2019by Robert Wing

Part 7 of Robert Wing’s Personal




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.

A better pattern would have been to just plow through it as best I could vs. trying for a smoother delivery, arranging and interpreting questions to make the points I wanted to make in an orderly fashion.

I practiced to just be silent while shifting to the next topic or question rather than ‘um’ or saying something stupid and having to backtrack; that seemed to work reasonably well.

This just followed the old presenting rule-of-thumb that, silence may be imperfect but is much better than stupidity.

Lessons Learned

#1 Better Time Utilization

What I did wrong was first present the topic in an orderly manner, then loop back and tie it to the questions. This was too slow.

You have to present to the scenario, but you do not have to present it in sequence. Although presenting them in sequence is easier for you and for the judges if you can make it work.

What I should have done is answer them in a sequence that made sense to me and provided an orderly SINGLE flow through the major content areas against the question.

This would have permitted me to cover more ground in the and less spill-over into the Q&A. Cost would have been taking the time to very formally “now we’re on X.X.X.X” with each item vs. going in sequence but I think that would have worked better than what I did.

#2 Put the Timer Where You Can See It

Viewing the timer from where I was presenting would have heped prioritize the last 10 minutes of the presentation. I would have allowed me to hit more of the specific requirements around delivery, deployment and governance before time ran out.

#3 Present Assumptions in Each Area

Ditch the intro slides on assumptions and guiding principles. They didn’t add value commensurate with the time spent preparing and presenting them.

Only include the assumptions that change the solution to the scenario. They need to be that important for it to be worth burning cycles on them. These worked best directly with each requirement where the assumption related to, when I ended up re-stating them anyway.

 Another 2-3 minutes in prep and 1-2 minutes in presentation to cover specific points in the scenario.

Presenting the assumptions with each area worked better anyway. Ex/ “here’s the best solution for reporting based on assumptions ___”.

Next in Robert Wing’s personal #JourneyToCTA, Part 8, Solution Q&A

About Robert Wing, CTO, ArganoaMind 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.

Robert Wing