So you want more about how to build that awesome enterprise Tableau service? No? Oh. Well tough – I’m gonna crack some more knowledge eggs on yo ass. That’s what the kids say these days isn’t it?
This time, it’s a big one. How to build a team to support that Tableau environment. As with most of my posts there are many ways it can be done but I’m going to describe what I’ve got in place. And it’s working pretty well even if I say so myself. Ner ner…
This post is going to concentrate on people-related aspects of your support team, rather than technologies. There may be another post on the way about that depending on whether anyone bothers to read this one other than Mrs Ninja.
Before I kick off, I am aware that most of these IT service posts don’t have the sexy factor of all those other cool blogs about Level of Detail (LOD) calcs, viz design or those games that people keep creating in Tableau. BUT – if you want to get Tableau to take off in a massive Enterprise then these are the things you’ll need to consider. Get one of them badly wrong and your dream could become a nightmare. So I don’t care if you don’t think it’s glamorous.
I’m gonna assume that you’ve already been through the aggro of fighting for precious headcount and that you have what you have. Hopefully that will be a good few people, more likely it will be n – 1 where n = the bare minimum needed… You’re just gonna have to accept that – you’ll never get enough bodies. If you work somewhere that gives you tons of people – give me a call…. (just kidding boss).
Where you gonna put them?
A few options here. We’ve located the whole Level 3 (see later for L1 / L2 / L3 roles) team in London. The main reason for that is that I’m here, so is my manager and the infrastructure is also in London. That gives us better oversight as we get this thing off the ground.
You may wish to consider splitting your team across regions if that is the company strategy. This can give advantages that you have close to 24 hour L3 coverage. It’s great if you get an towards the end of UK time, and are able to then hand off to your USA team, who then run with it and resolve while you’re enjoying forty winks.
In the future the demands of your service may determine where you locate additional people. Much of this may be down to your company strategy, where there may be a preference for lower-cost locations as opposed to paying the big bucks to people to come to London or New York etc.
But you should also be mindful of where your service usage is growing. Using our Custom Admin Views (post on it’s way about them) we can see exactly what regions our Server is being hit from and where our Desktop users are located. If you see adoption in a particular region going through the roof then maybe you should consider recruiting in that locale? We got a tremendous response from our Singapore user base when we went live. They LOVE a bit of Tableau. But when they are online, we are asleep so they get delayed response to queries. I should probably put someone out there to give them better service.
It’s not all gravy though. Managing remote teams is difficult and takes a lot of organisation.
I’m sure you get the drift. You may not have much choice in location, but then again you might…
Typically large organisations will have a standard Information Technology Infrastructure Library (ITIL) model of support roles and responsibilities. To summarise.
- Level 1 Support – Detects and registers incidents. Can apply basic remediation but more likely to escalate to Level 2. Level 1 also performs incident triage and communication to affected user base.
- Level 2 Support – More skilled technicians with access to your production environment. Can often solve incidents and manage appropriate user communication. L2 also assist us with Tableau Server upgrades and failover tests etc.
- Level 3 Support – That’s my immediate team. We have break-glass (non-standing) production access to assist if L2 can’t solve the problem.
It’s really important to get this working well. An efficiently functioning L2 will come to be your team’s wingman, taking the pressure off your engineers. We’re lucky to have a good L1 & L2 setup, so only approx 10-20% of incidents ever filter all the way down to my L3 team to fix. L2 can usually deal with most.
Your L1 & L2 teams will tend to operate exactly by the book, so make sure they have appropriate process and documentation to allow them to succeed. They’ll also probably be supporting more applications than your precious Tableau Server so bear that in mind. Yes some people actually work on other applications not just Tableau – the fools.
What’s Your Service Model?
This is a topic that can make or break your service. As far as I’m concerned the only option for a big organisation, where you’ll never have enough people is to go Self-Service.
That means – my team doesn’t create visualisations for anyone. Users don’t submit tickets to us for us to create their vizzes. Why?
- Context – Users know their data best. They know how it hangs together.
- Volume – My team wouldn’t be able to handle the sheer volume of requests coming in and that would lead to a slow service.
- Agility – So many tools at big organisations are mired in red tape, delays and bureaucracy. Not my Tableau service. We’ve cut through all of that crap to give users a tool that they can use as they wish, get results and get into production fast. What’s the point of giving someone an agile tool and then making life hard for them to get results?
- UX – I love it when a user thinks they are not technical enough to use Tableau. I tell them to go and try it and come back in a day if they are still stuck. I find they come back in a couple of weeks instead, having had a blast. If we just did the work for them, then they wouldn’t get that magical UX that we all love, and they’d think Tableau was just another tool. So I want them to do it themselves, and get that brilliant realisation that they’re using a fantastic application.
So we make sure users know this is a self-service model, and a true Data Visualisation Centre of Excellence. Check this post for how I constructed our CoE. I’ll be doing another post later on how this service model hangs together.
In summary, because we don’t create vizzes or datasources for users, we have time to concentrate on the extra value items that differentiate us from other IT services.
Your Team’s Roles
So what type of Tableau work will your team need to cover? We kinda bucket our tasks into the following groups
- Engineering – Building, customising and integrating our beautiful Tableau Server with other systems. Upgrades, tuning & generally being nice to it.
- Training – Delivering our World Famous training syllabus, Dr Sessions and all the other goodies detailed in this post.
- Consultancy – Helping users with visual analytics, issues, performance, or anything else they want.
So you’ll have to decide if you want each person in your team to be able to cover the whole spectrum of tasks, or do you want to have specialists? I’m lucky enough to have a cracking team, where my girls and guys can swap between any of these buckets with relative ease. It’s still cool to dedicate one person to user work and the other to engineering for a time though, but be aware there may be an impact when one is on holiday.
We have chosen to keep the training programme operated by one person though, as this has allowed us to build up a more consistent programme that can be tweaked and refined.
So because we empower users to create their own content, we can dive head first into all this juicy work. It’s interesting for us, and users love it.
Adding The Gloss
Some other activities my team perform as part of our service. I class these as the glossy items as I don’t see any other IT services doing them. And the reaction we get from our users is phenomenal.
- Makeovers – We pick a viz, download it, make it loads better, send it back to the user with some notes on what we did and what they can do to better understand why we did it. Always a winner. Who doesn’t like their work being made better for free? Needs sensitive communication though as we don’t want these to be seen as a criticism of someone’s work.
- Competitions – We’ve got a weekly challenge competition going on and we periodically do other larger viz-offs. We get Tableau involved in the firmwide Hackathon events and offer swag or dedicated time from the team as prizes. We also encourage users to get involved with things like IronViz.
- Interviews – Our series “Agile BI talks to…” is proving popular. Basically an internal version of the “2 minutes with…” interviews that we do on this blog. Users love a chance to sell themselves so we have a queue of people wanting to take part.
- Champions – This is an internal version of the Tableau Zen Master programme. It is great for building engagement, encouraging competition and driving up standards across your user base. We currently have 2 Champions but I know there are several users who are desperate to be recognised as a Champion. This is a 2-way initiative, Champions sell and evangelise our service and in return we give them extra insight into the product, vendor etc.
- Proactivity – Using our Custom Admin Views (wait for post on those please) – we can tell when users are having a bad experience with Tableau – usually down to slow performing visualisations. So rather than have them complain, or suffer in silence, we can reach out and say “We think you might have a problem, let’s fix it”. This usually blows them away. I’ve had comments back like “This is the first time I’ve EVER had an IT team come to me and tell me I may not be getting the most out of their tool – I usually have to complain first – it’s incredible!”.
- Tableau Touchpoints – Again, using our Custom Admin Views – we can tell who is engaged with our service. And we can tell what rank they are, and where they work. So I spend a lot of time reaching out to these people (the more senior the better), and making sure they are fully aware of the services we offer. I’ve packaged it into a standard experience called Tableau Touchpoints. Told you I was into branding…
- Polls – Simple. Think of a question, put it to a fun vote. We have one on the run at the moment called “What is your favourite chart type?”. Gets people talking and interacting. Sometimes it gets heated. But it always gets people clicking on your community page.
You’re Certifiable Quint!
Try and get your team certified. You want to be seen as the experts then you need to wear the badge. While certification certainly isn’t a substitute for on-the-job experience, it does give that air of confidence to your users. It’s also fun to do.
Senior management will also like to demonstrate to the business that your Tableau service is manned by highly skilled, vendor certified technicians. So more of a branding exercise but still very much worth doing…
For more info on Tableau Certification check this out.
Monitor Your User Base
One of the things that tends to happen with Tableau is that *some* of your users will totally fall for the tool. Just like I did and many of you out there. These are people you should be aware of as they are heading down that path to wanting to make Tableau their whole career.
Keep an eye on users that are spending lots of time with the tool, have seriously engaged with your mission or that have been demonstrating great expertise. They could be potentially interested in moving to work for your team. I get asked regularly by my user base if there are any jobs going in my team. That’s obviously cos I’m an amazing boss and we have it totally going on – who can blame them. It’s got nothing to do with Tableau…
But seriously, rather than going out to market and risking getting the wrong person in, the answer to your resource issues could be right under your nose.
Freedom of Expression
I think it’s really important to allow your staff to express themselves. Data visualisation is a creative art, and allowing your team a free mind is critical to their creativity, enjoyment and success.
I make sure my team know that I’m all for them blogging internally & externally, interacting on social media, building contacts and going out to our user base proactively to help. If they see a viz on our server that they think they can improve then they just go for it. If they want to dive more into a particular user’s requirements then just do it. Wanna write a blog – do it already!
This applies to contractors & consultant staff also. I want consultants to leave having developed into more able technicians from having worked with my service – I don’t regard them as hired gun resources to squeeze work from, they are valued contributors to our mission. I find that consultancies really appreciate this approach and it has led to us building some great relationships with consultancies and individuals alike.
I’ve heard you even have to give your team days off. They’re called “holidays”. Yeah I know, it’s a legal thing apparently. Won’t catch on.
Freshen it Up
I actually operate a model where I swap out consultants every 6-8 months regardless of how well they are doing with us. I do this because it is useful to get a fresh perspective on our environment, with each new person bringing something different to the table. I also do this for the benefit of the consultant themselves. No-one wants to be stuck in a single role for 18 months, so I like consultants that work for me to work hard, learn lots, then take those skills away to their new roles. Again this is really appreciated by the management at consultancies as part of our strategic partnerships.
The Human League
You know what users hate? They hate it when they have to submit a ticket or email to some faceless system, that gets picked up and processed by someone they’ve never met, in some region thousands of miles away. It feels, well, inhuman.
Not in my team. We’re all about being as human as possible. My team all have their individual profile pages on our community site. They have blogs. They have photos and backstories of their career and interests. They advertise their social media presence. They are contactable and approachable. People know who they are, what they look like and what makes them tick. When you deal with my team you are getting a proper service, from real people that you know care.
We get much better user engagement like this and as a result my team has gotten to know some users really well.
Change & Incident Management
Ah everyone’s favourite subject. So Tableau is great right, but it’s still only a piece of software. And as such you’re gonna get issues. So you need to handle them correctly.
Firstly, make sure you’re utilising Level 2 support for your changes and handling your incidents. This will take so much heat off your Level 3 team. L2 should be able to do all of your paperwork, manage the communications to your users, and even perform the majority of standard changes like upgrades and config changes.
We always make sure we over-communicate on changes and incidents. We involve power users and get them really ingrained into what we are doing and why we are doing it. Your power users will love to know why something broke, what Tableau are doing about it and when that fix will be implemented because they want to really understand the application. Often they come up with good suggestions as to what you can do to help prevent a recurrence. So get them involved.
I’m not going to go into too much detail on this, there’s a ton of ITIL related reading you can do. The message is – you can get a lot of positives from handling a negative situation well. Show empathy to your users for the impact they have experienced, show you care, don’t hide anything and be totally transparent.
A Big Thank-You!
To give great support you have to have great people. People that are skilled, passionate and dedicated. People that care about the service they provide and your mission. If you don’t have great people then don’t mess about – get someone else. You’ll be the one judged by users and management, so there’s no room for sentiment.
I’m lucky. I’ve had really great people. So a big thanks to Jake, Carl, Andy, Emma, Jonathan & Dave for helping to build and run our service!
OK that’s it for this one. There may well be an update to this post as it’s such a huge subject that I’m sure I’ve missed some things.
Now if you’ll excuse me my team seems to have gone to the pub… Err guys? GUYS???