Graduating in 2016?

We love hiring graduates!

We hire a lot and we’re getting pretty good at training them…

Over 50% of our company joined us straight out of Uni. This year we have had 7 graduates join us in Development, Test and Project Management. Some of the developers we hired as graduates 10 years ago are still with us , including two of the computer scientists we first met at Bristol University, who are now Sitecore MVPs (an award given to only 0.53% of the Sitecore certified ecosystem).

So why do we love grads?

What’s not to love – They are intelligent, motivated, on message with the latest trends and they are able to soak up the information and training we provide them with. We take a mentoring approach to graduate development. Working with more experienced guys on live projects they are given real world problems to solve in a supportive environment. What better way to learn your craft.

We are kicking off our Graduate recruitment for 2016 now with the following events:

  • Bristol University, ‘Engineering and IT careers fair’ – October 21st.
  • Birmingham University, ‘Software, system and emerging technology careers event’ – October 22nd.
  • Silicon Milkroundabout – Sunday 15th November (not just for grads – but we met some great graduates there at the last event).

Come and say hello to me (and some of the team). If you can’t make any of these events feel free to drop me a line for an initial conversation about the roles on 0117 932 7700 or alternatively send a copy of your CV to:

More events to follow……

How Not To Demo

Recently, I was asked to demo a system that we are building for a client to some stakeholders from across the business. The demo would be delivered by me remotely, although the stakeholders would all be in the same room.

Simples. I’ve been managing the project ever since development had started (actually earlier than this, as I was involved in the ‘scoping’ phase as well), so I knew the system inside out and back to front.

I also deliver demos to the key stakeholders on a weekly basis, so I had no qualms on delivering a demo to a slightly wider audience.

‘Yep, no problem” I responded, “Just tell me when and I’ll set it up.”

And that was that. I put it to the back of my mind.

A couple of days later, it was time for the demo. I dialled in and introduced myself to the room at large. I then asked the facilitator at the client site to open up a browser and go to a particular URL, which would then display my screen to the room (I was using an online screen sharing program, and they were having this projected onto a screen in the room).

After the facilitator confirmed that everyone was there and they were ready, I began. I started by showing some of the latest features my team had been developing and explaining how they worked.

I talked.

And talked.

At one point, I had to talk to cover up the fact that I was waiting for an email to be sent to me via the system.

At other times, I was talking simply because I couldn’t hear anything happening at the other end of the line.

I was flying through the demo and after about 15 minutes, I realised that I had gone through parts of the system that I had expected to take twice as long to present. Was I going to fast? I posed the question to the audience.

“A little” the reply came back from someone in the room, “This is the first time I’ve seen the system so I’m struggling to keep up”.

It was as though someone had poured cold water down my back. What?! I thought the participants all knew about the system? Why didn’t they tell me that I was demoing to people who had never seen it before?

Hang on, did I ask?

I tried to keep calm. I backtracked, and went over some of the previous functions in a little more detail. I explained some of the background to the decisions we had made and what we were trying to achieve.

The demo came to an end. Silence.

“Well, that’s the end of the demo” I pronounced, “Does anyone have any questions, or are you all fast asleep?”

That at least got a couple of laughs, and negated my fear that everyone had left the room in boredom.

The facilitator then spoke up;

“Thanks Chris, that was great. I’ll handle any questions as we’ve got some other stuff we need to discuss here anyway, so thanks for the demo.”

“Oh, no problem” I responded, “thanks for your time”. I hung up.

It then struck me. I had absolutely no idea of what those ‘participants’ thought of the demo. I use the term loosely as they hardly participated at all, it was just me talking for most of it.

All sorts of thoughts were running through my head, how could I have not checked who I was presenting to before-hand? Did they follow anything I said at all, or did it go straight over their heads? I had made all sorts of assumptions going into the demo, and I was coming to the realisation that at least some of those assumptions were wrong. I had dropped the ball in spectacular fashion.

“What I need”, I thought to myself, “Is some feedback on how that went”. I couldn’t speak to the participants face to face, this wasn’t possible due to the distances involved. Phone calls to everyone that was in the demo wouldn’t be terribly efficient. Perhaps some sort of survey would get me the answers I need?

So that’s what I did. I used an on-line tool (Survey Monkey, which proved to be quick and simple to use), to create a basic survey . I sent off the link to those persons who were in the demo. Within a couple of hours I had a number of responses and plenty of data to start to analyse.

It wasn’t as bad as I thought.

As it turns out, only one person hadn’t seen the system before and they appreciated the fact that I went back to explain some of the features in more detail.

Another participant explained how the order in which I presented the functionality confused them, something that could easily have been solved by showing another part of the site first.

The other participants all thought the demo was well delivered and the pace of it was fine. The biggest issue appeared to be the projector used in their meeting room, which was a little blurry, plus the glare from the sun coming through on of their windows.

All in all, it could have been much worse. But I learnt a number of things from this little escapade;

  • In future, I need to check the equipment that’s going to be used as well as have a practice run through, this will ensure that things run smoothly on the day
  • Always find out who I’m demoing to. What is their knowledge of the system like?
  • Try to get my audience engaged. If I want feedback at the end of the demo, then I need to keep the attention of the participants.
  • I’m going to try and get feedback from as many demos as possible in future. This is invaluable in improving my deliver mechanisms for future demos.

If you ever find yourself having to deliver a demo. Don’t make the same mistakes I did. Why not read my handy guide for avoiding the major pitfalls.

How Effective Are Your Demos?

For those who have read my recent experience with undertaking a demo, you’ll know that sometimes you feel like they could’ve gone better. This is my simple yet effective guide that may help you avoid some of the usual pitfalls;

Feedback is important. Especially so when it comes to software development. How does the new functionality meet the expectations of the stakeholders? Does it ‘feel’ right? Does it positively impact on the customer experience? We need to know the answers to these questions to determine the value of any newly developed function.

There are many ways to gather feedback, but chief amongst our arsenal is the ‘demo’. A simple yet effective tool when done right, you get a bunch of stakeholders together (either on site or remotely), and present the new functionality to them. They can then freely discuss what you have shown them, allowing you to gather their thoughts and feelings on whether any further changes are required.

Demos can be extremely powerful, they allow us as the facilitators to guide the stakeholder’s thoughts onto particular areas of a system or site, to consider certain scenarios or UI enhancements. But, do we use them effectively?

We’ve all attended poor demos in the past. You can picture it; the stuffy room, filled with people from all areas of the business, some of whom have only passing knowledge of the subject matter. The monotone voice, droning on. The demo bounces around, showing different pages and functions so quickly that you have no idea what is going on. Or perhaps the facilitator is focusing on something that you know in detail already, and you’re being taught how to suck eggs. You lose interest, allowing your mind to wander. Your eyes glaze over…

A boring presentation

Sounds awful doesn’t it? It’s a waste of your time, the facilitator’s time and the business ultimately sees no value.

Now consider this, how many demos have you given that play out as described above? You sure? How do you know?

If you want to be sure, then follow this guide for delivering great demos and getting that all important, quality feedback;

Step One – Know who you’re delivering to

Who is coming to the demo? What is their background? Do they understand the system in-depth, or have they hardly seen the system before?

The content of your demo needs to take into account the knowledge held by the audience. There is no point going into technical detail for an audience that has never seen the product before, Similarly, don’t waste time demoing basic functions to people who know the product inside out. It’s not always possible, but try to keep the audience limited to those with a similar level of knowledge. You can then tailor the content to fit. These leads us on to point two.

Step Two – Limit the audience

When inviting you audience, consider what you are trying to achieve. Do you really need to invite someone from marketing to a demo of backend systems? Does QA need to be involved in a demo focused on user experience? Try to keep the audience limited to those who will have something to offer in terms of feedback, those whose opinions matter. Don’t invite loads of people; the more people there are, the less likely it is that your audience will feel confident to ask questions or provide opinions.

Step Three – Keep to a predetermined scope

It’s obvious really, but know what you want to demo and what you want to get out of it from the stakeholders. Don’t let your audience get side-lined onto a completely unrelated conversation. If needs be, you can always arrange for a separate meeting or demo to discuss any unrelated issues. Keep your audience focused on the task at hand.

Step Four – Have a run through before-hand

Again, a simple yet effective step. Practice what you intend to demo. If possible, use the same equipment and/or software that you intend to use on the day. Deliver the demo to a colleague; can they understand the information? Was your delivery clear and concise, or were you mumbling? Preparation is key.

If you are doing the demo on site, make sure the room you are delivering in is big enough, has the right number of chairs and has the equipment you need. There is nothing worse than wasting the first ten minutes of a meeting trying to get the projector working.

Make sure you consider different delivery mechanisms. Does it have to be done using a PowerPoint presentation or could you use something more creative or unusual? If it helps engage your audience, then give it a go!

Get creative with your demo deliveries!

Step Five – Gather feedback on the demo

Probably the step that most often gets overlooked. Just because you delivered the demo successfully and got some feedback, it doesn’t mean that it couldn’t have gone better. Try to get some feedback on the demo itself. You can do this in any number of ways, from chats around the coffee machine to asking the audience at the end of the demo. Personally, I have used online questionnaires to great success (Survey Monkey is a free, simple, yet effective tool). Keep in mind that some people don’t feel confident enough to make their opinions known in front of others (particularly if there are loud, brash or opinionated members in the audience), so sometimes you will get honest feedback only by approaching these people on their own or allowing them to answer anonymously.

All of these steps are simple enough, but they will help achieve that ultimate goal of getting useful, valuable feedback.


Is it true that those that can do, and those that can’t teach?

George Bernard Shaw famously wrote in his play Man and Superman: “He who can, does; he who cannot, teaches”.

I’m a ‘doer’ – no doubt about it. I’m motivated by getting things ‘done’. Give me a ‘to do’ list or ask me to do something and I’m your man (well woman). I’m not good at delegating (‘if you want something doing well, do it yourself’). I can’t bear to see people stuck for ideas or be indecisive so I’ll jump right on in there with solutions (often too quickly) – every time. Ask me about my plans for the future – I can’t tell you that – don’t you know I have this big to do list which is taking all my time up, I’ll think about the future tomorrow.

However my doing tendencies are completely at odds with the role of Manager I find myself in. Like many managers I’ve ended up in this role because of experience, years of service and the assumption/belief from superiors that because I perform well in a role that I’m qualified to manage others doing that role.

I know I’m not alone – thousands if not millions of managers out there are ‘doers’ – given the choice they will focus on the tasks they need to do and spend little time focusing on the people they’re managing. Perhaps the saying should be ‘Those that can do, can’t teach’.

Teaching (or coaching) is going to require me to learn a lot of new skills. I’m going to need to learn to take time to plan ahead, focus on the future and involve others in my plans. I’m going to need to work on how I provide positive and negative feedback to my team (as opposed to praise or criticism). I’m going to need to fight my instincts and delegate and catch myself before jumping in with solutions or answers. I have to give them space to fail (safely) and be there to pick them up when they do. Most importantly I’m going to need to take the time to take an active interest in my team, listen to what they have to say and find motivation in seeing others get things done well.

Now I know what I need to do, how do I go about it? Maybe if I can create a ‘to do’ list……..

Thanks to Marty Brounstein author of ‘Coaching & Mentoring for Dummies’ for the distinction between do-er managers and coaching managers