steven pressfield

How to Deal with the TED Effect

Peter Cripps presenting , , ,

Nancy Duarte, CEO of Duarte Design and author of the books Resonate: Present Visual Stories that Transform Audiences and slide:ology: The Art and Science of Creating Great Presentations has written a great blog post about what she refers to as the TED effect. The TED effect refers to the impact that the TED conferences have had on all of us who need to present as part of our daily lives.

Nancy’s basic assertion is that “in public speaking it’s no longer okay to be boring”. In the years BT (before TED) it was okay to deliver boring presentations because actually no one knew if you were being boring or not because most people’s bar for what constituted a good presentation was pretty low anyway. In the dark years of BT we would all just sit stoically through those presentations that bored us to death and missed the point completely because bad presentations were just an occupational hazard we all had to learn to deal with. If nothing else it gave us time to catch up on our email or quietly chatter away to a colleague in the back row.

Now though everything has changed! For anyone that has seen more than half a dozen TED talks we know that if we are not engaged within the first 30 seconds we are ready to walk. Not only that if we felt you were wasting our time we go onto Twitter or Facebook and tell the rest of the world how boring you were. If however you did engage us and managed to get across your idea in 18 minutes or under (the maximum time of a TED talk) then we will reward you by spreading your ideas and help you get them adopted and funded.

As technical people software architects often struggle with presentations simply because they are communicating technology so, by definition, that must be complicated and take loads of time with lots of slides containing densely populated text or diagrams that cannot be read unless you are sitting less than a metre from the screen. But, as Nancy Duarte has explained countless times in her books and her blog, it needn’t be like that, even for a die-hard techno-geek.

Here’s my take on on how to deal with the TED effect:

  1. Just because you are given an hour to present, don’t think you have to actually spend that amount of time talking. Use the TED 18 minute rule and try and condense your key points into that time. Use the rest of the time for discussion and exchange of ideas.
  2. Use handouts for providing more detail. Handouts don’t just have to be documents given out during the presentation. Consider writing up the detail in a blog post or similar and provide a link to this at the end of your talk.
  3. Never, ever present slides someone else has created. If a presentation is worth doing then it’s worth investing the time to make it your presentation.
  4. Remember the audience is there to see you speak and hear your ideas. Slides are an aid to get those ideas across and are not an end in their own right. If you’re just reading what’s on the presentation then so can the audience so you may as well not be there.
  5. The best talks are laid out like a book or a movie. They have a beginning, a middle and an end. It often helps to think of the end first (what is the basic idea or point you want to get across) and work backwards from there. As Steven Pressfield says in the book Do the Work, “figure out where you want to go; then work backwards from there”.
  6. Finally, watch as many TED talks as you can to see to see how they engage with the audience and get their ideas across. One of the key attributes you will see all the great speakers have is they are passionate about their subject and this really shines through in their talk. Maybe, just maybe, if you are not really passionate about what your subject you should not be talking about it in the first place?

The Essence of Being an Architect

Peter Cripps architecture , ,

There are many skills frameworks out there that tell us what skills we should have for ‘doing architecture’. My company has (at least) one and I’m sure yours does as well. There are also organisations that specialise in creating such frameworks (check out the Skills Framework for the Information Age for example). Whilst there are some very specific skills that software architects need (developing applications using xyz programming language, building systems using a particular ERP package and so on) which come and go as technology evolves there are some enduring skills which I believe all architects must acquire as they progress in their careers. What I refer to as being the essence of being an architect. Seth Godin recently posted a blog entry called What’s high school for? where he listed 10 things all schools should be teaching that should sit above any of the usual stuff kids get taught (maths, chemistry, history etc). A sort of list of meta-skills if you like. Borrowing from, and extending, this list gives me my list of essential architect skills.

  1. How to focus intently on a problem until it’s solved. There is much talk these days about how the internet, the TV networks and the print media are leading to a dumbed down society in which we have an inability to focus on anything for longer than 30 minutes. Today’s business problems are increasingly complex and often require prolonged periods of time to really focus on what the problem is before charging in with a (software) solution. Unfortunately the temptation is always often to provide the cheapest or the quickest to market solution. You need to fight against these pressures and stay focused on the problem until it is solved.
  2. How to read critically. As architects we cannot hope to understand everything there is to know about every software product, technology or technique that is out there. Often we need to rely on what vendors tell us about their products. Clearly there is a danger here that they tell us what we, or our clients, want to hear glossing over faults or features that are more ‘marketechture’ than architecture. Learn how to read vendor product descriptions and whitepapers with a critical eye and ask difficult questions.
  3. The power of being able to lead groups of peers without receiving clear delegated authority. The role of an architect is to build solutions by assembling components in new and interesting ways. You are the person who needs to both understand what the business wants and how to translate those ‘wants’ into technology. Business people, by and large, cannot tell you how to do that. You need to lead your peers (both business people and technologists) to arrive at an effective solution.
  4. How to persuasively present ideas in multiple forms, especially in writing and before a group. Obvious really, you can have the greatest idea in the world but if you cannot present it properly and effectively it will just stay that, an idea.
  5. Project management, self-management and the management of ideas, projects and people. How to manage your and others time to stay focused and deliver what the client wants in a timely fashion.
  6. An insatiable desire (and the ability) to learn more. Forever! This job cannot be done without continuous learning and acquiring of knowledge. Everyone has their own learning style and preferences for how they acquire knowledge, find out what your style is and deploy it regularly. Don’t stick to IT, I’ve discussed the role of the versatilist extensively (see here for example). Be ‘V’ shaped not ‘T’ shaped.
  7. The self-reliance that comes from understanding that relentless hard work can be applied to solve problems worth solving. Belief in ones ideas and the ability to deploy them when all around you are doubting you is probably one of the hardest skills to acquire. There is a fine balance between arrogance and self-belief. In my experience this is not an easily repeatable skill. Sometimes you will be wrong!
  8. Know how to focus on what is important and to ignore what is not. If you have not heard of Parkinson’s Law of Triviality take a look at it.
  9. Know who the real client is and focus on satisfying him/her/them. There can be lots of distractions in our working lives, and I’m not just talking about twittering, blogging (sic) and the rest of the social networking gamut. Projects can sometimes become too inward focused and lose track of what they are meant to be delivering. We live in a world where numbers have achieved ascendency over purpose. We can sometimes spend too much time measuring, reviewing and meeting targets rather than actually doing. I love this quote from Deming: “If you give a manager a numerical target, he’ll make it, even if he has to destroy the company in the process”. There is little merit in a well executed project that no one wants the output from.
  10. Use software/system delivery lifecycle (SDLC) processes wisely. SDLC’s are meant to be enablers but can end up being disablers! Always customise an SDLC to fit the project not the other way around.

If all of this seems hard work that’s because it is. As Steven Pressfield says in his book The War of Art:

The essence of professionalism is the focus upon the work and its demands, while we are doing it, to the exclusion of all else.