Ominlab Media’s Stefan Gillard on how to build a high performance team

Building a high performing team is a challenge for many CIOs with a myriad of factors to consider – such as managing personalities and skills, and benchmarking and assessing performance.

Without a high performance team to support you, projects could fall behind schedule, grow beyond budget and sprawl out of control.

Speaking at CeBit in Sydney, Stefan Gillard, general manager – technology at Omnilab Media Group shared what he has learnt building and delivering a greenfield digital animation and effects facility for film director George Miller of Happy Feet and Mad Max fame.

The facility is currently being used to deliver a $100 million project in the next 2.5 years — Happy Feet 2 – and consists of around 360 staff and 6000 CPU cores churning through $2 million worth of power a year.

According to Gillard, the facility, which is also expected to generate about a petaflop of data – is the largest super computing clusters in the southern hemisphere.

1. Be clear about your role: Lots of people ask if I’m a CIO, GM of technology – but I’m actually technology agnostic. I really don’t care of the types or forms of vendors I work with, the types of systems I design, the process that is created to deliver what I do. I’m about delivering business value. It’s my role to deliver a business outcome – in my case, delivering a pipeline for a studio.

In this case business value is measured by delivery on time: if there is a $100 million project to be delivered in three years’ time there is another $100 million on the back of that in marketing a distribution and merchandising. That date cannot move.

2. Six degrees: I Like to hire people I have worked with before. If I haven’t worked with them, then I like to have a recommendation through someone I know who has worked with them before. The reason behind that is the known quantity. People who have to build a new team often use recruiters and try to express what they are trying to achieve, but it is a step removed from the team that is actually physically going to do the work.

3. Assessing candidates: Word gets around that I ask strange questions. I always make a point of meeting with candidates, I put it to them that they are not interviewing for this job, but the next one. It is really important for me that from the outset I have an idea of what their succession plan or career path will be. It is pointless to hire for a junior or even mid or senior role if you don’t consider where that person will be in three years.

What that also does is put the candidate on the back foot If they can’t think of a response to that question then that’d a flashing light that this person hasn’t thought of where they are going in their career, maybe this isn’t something serious for them.

4. Use the Force: I used to work for a training team who developed high performing teams. One of the tools they used in calibrating and assessing candidates is psychometric profiling. That gives you a greater sense of what the mechanics and relationships going to be like when you throw these people into a pot. One way to quickly get a sense of what a person will be like without putting them through a test, is to ask them: “If you were a Star Wars character, who would you be, and why?” That tells me which quadrant they sit in: are they analytical, direct, amiable or expressive? If someone says they are R2D2 then I probably have a pretty good engineer on my hands and someone can get a job done and not feel the politics of a place. If I have a some one more personable, like a Chewbacca or a C3PO, then I have someone who is more amiable and who can bring about team functional effectiveness.

Page Break

5. Running the gauntlet: When building a technological team I never have the final say on an appointment. It is key for me that everyone I hire I develop a mentoring based environment in which people have the ability to be developed. We have a process called Running the Gauntlet in which the final interview for a person, no matter how senior, is with the juniors in the team. If the juniors come back to me and say they don’t like his style, he wasn’t willing to respond to my question about how they have developed people in the past, then they don’t get a wave through. Some may say that’s na?ve, but I have never been let down by that approach.

6. Organising the team: A technology team is no different from any other high performing team. It is comprised of individuals with specific skill sets. It is always important to take the time to map out what you are trying to achieve. What skills, what the succession plan is, and how you are going to make yourself redundant in a short period of time – there is a finite window of where your involvement [in the project] will take place.

In creating Dr D, the process was a two phase one. Phase one was: whiteboard it, plan it, architect it, build it, then implement it. Phase two was handing it over to a group of individuals who would be responsible for the ongoing maintenance and management of the systems.

I built the team with two sides – one representing the RD team – sys admin, engineering staff and RD – and the other for service delivery. One is responsible for coming up with products and services, and the other is responsible for delivering them back into the business.

Someone says they need a new shader library so they can make feathers look more realistic, so the RD team then comes up with and designs the code base for that and it will be pushed out to and implemented in the business. The service delivery team is responsible for bringing the rest of the organisation up to speed on how they might use that tool set.

7. Make yourself redundant: How do I step out of the business? By having core, key measurements in place on how we deliver business value on a project up to the hand over point. What gets measured gets done. Whether it’s systems, process or infrastructure everything needs to be measured so that the client knows we are bench marking against it, it also keeps the guys on their toes. That includes fiscal so all my guys are aware of the budget process. I put all my technical team through finance 101 so they understand the cost of capital, the variances of choosing one technological solution over another, and that extends having the juniors and sys admins and the help desk understand that if we buy something there is an associated cost to deploy and support that infrastructure.