Tableau on Tour Keynote Speakers – Some Suggestions

Gallery

This gallery contains 32 photos.

Hi all, I love the Tableau Conference. But I also have a lot of fun at the smaller “Tableau On Tour” events. In particular I love the keynote speeches. We’ve had some crackers recently, with particular recent favourites being Tim … Continue reading

Empowering Your Tableau Users With Makeovers & Proactive Support

Hi all,

More on building that dream Tableau Centre of Excellence function. I’ve previously posted about how to structure your support team and ways to build user engagement with “Tableau Champions”, this post focuses on how you can use Tableau’s introspection capabilities to deliver a more proactive support function.

What is proactivity?

The traditional definition of proactive is as follows.  To me it means means seeing into the future and Screen Shot 2016-08-07 at 21.21.00getting to an issue before it even happens. In the world of IT Support, proactivity really is the Holy Grail, meaning the difference between a good support function and an amazing one. But it’s super-hard to achieve, especially in the complex enterprise level setups that have multiple break points. You can almost never prevent something from breaking, no matter how good your monitoring is.

What you can do is add some proactivity into the way your team operates by identifying when your users are not getting the best from your service. In Tableau Server world we have the ability to spot the following and much more.

  • Slow Tableau visualisations
  • Consistently failing extracts
  • Stale content

I won’t go into how to achieve this, it’s the subject of a future post. But I’ll point you in the direction of these 2 posts that should get you on the way. Go check out Custom Admin Views by Mark Jackson and Why are my Extracts Failing – by Matt Francis.

I get my team to scan our admin views, to identify those users that in our opinion are not getting the best experience they can from Tableau. If we see someone who might be experiencing consistently slow visualisations, or have regularly failing extracts then we give them a call. Often the users won’t even have a complaint. But our message is “We think you’re not getting the best experience possible, and we want to make that happen”.

screen-shot-2016-11-17-at-21-17-13The initial reaction is often surprise. “I’m ok, I didn’t raise an issue” will be a common response. But then once we’ve worked with the user, and improved their experience, you’ll find they are blown away. You may even get a call from their management!

You’ll find this kind of service is very rare in most organisations so if you can deliver it, even sporadically, then you’ll be regarded very highly.

Makeovers

This is pretty simple, if a little time-consuming. Browse the Tableau content on your server. Spot something that doesn’t look great – it might be slow, not compliant with your best practices, or just fugly. Download that content, and give it a makeover. Make it look great, maybe add some improved functionality, make it nail best practices.

This is one of my team’s favourite activities due to the reaction of the user / client. They LOVE it. It really creates a sense of engagement, the user feels that your team actually really cares about them. We’ve also had our Tableau Champions participate in Makeovers which is even better as it saves my team some cycles.

Be careful though, some user content might be confidential and the user may not appreciate an admin poking around in their data. Also, remember that by doing this you are implying a criticism of their work, so handle the communication with care and sensitivity.

Also ensure that you don’t just change stuff and then drop it back on their laps. In a self-serve model like mine users develop and support their own content so it is crucial the user knows what you’ve changed, how you’ve changed it and what benefits you feel the modification brings. Pull them and their manager into a call, run through what you’ve done and then hand it back over to them to run with it.

These have been very successful in my organisation. Users truly appreciate the help and my team has fun doing it.

So there you are, a couple of tips for adding that gloss to your Tableau support service.

Cheers, Paul

Building user engagement with Tableau Champions

Hi all,

More on building an enterprise Tableau Centre of Excellence. That’s pretty much all I know about hence why I seem to be writing about it a lot…

This is a short post about an initiative that is proving to be pretty successful at my organisation, we call it Tableau Champions.

images

We are the Champions!

We’ve based this loosely on Tableau’s own Zen Master initiative. For those that don’t know, Zen Master is effectively a title awarded to members of the community on a yearly basis. For more information see here – http://www.tableau.com/ZenMasters

 

What makes a Tableau Champion?

We award the Champions badge to users that demonstrate

  • Passion & enthusiasm for Tableau & data visualisation
  • Support of the Agile BI service at my organisation
  • Skils in Tableau & visual analytics
  • Willingness to share & assist other Tableau users
  • Involvement in the Agile BI community

Even amongst a huge user base like I have, it is easy to spot users that demonstrate these characteristics. They will become your trusted advisors, providing great feedback and helping you iron out the bumps in your service.

 

What’s in it for a Champion?

Here’s what my team does to help Champions

  • Build Tableau skills & contacts
  • Increase internal profile across the org & gain stature as a Tableau SME
  • Increase external profile
  • Exposure to extra product information & roadmaps
  • Contribution to the development of the Agile BI service
  • Great collaboration opportunities across the firm

 

 What’s in it for my service?

And in return Champions help us by

  • Makeovers & dissemination of Best Practices
  • Publicising events & webinars
  • Blogging on Agile BI community site
  • Host local user groups
  • Champions help local users evolve Tableau skills
  • Driving better understanding of visual analytics & Tableau

 

So it’s a mutually beneficial scheme, with Champions effectively acting as an extension on my own team. Win and indeed – win.

One thing I noticed was the way the Champions initiative immediately started to raise the bar in terms of user interaction with Tableau at my org. No sooner had I posted the first blog announcing our initial Champions, then I had multiple emails from other users saying “I want to be a Champion”, “What do I need to do to get this recognition?”. I could even tell that some users were a little miffed not to have been selected. I then saw these users upping their game, posting more, interacting more, trying to be noticed. We’ve seen this with the Zen Master scheme eliciting exactly this kind of response from the external community.

So there you have it. We love to empower our users. And we love to reward those users that have become hooked on Tableau like we have.

Cheers, Paul

Tableau Server – all about the… Backgrounder

Hello everyone.

You may know me as a Tableau Centre of Excellence manager. That can involve a lot of paperclip pushing skills, with the real work being done by my excellent team (thx @jakesviz & The Information Lab). But I do try and get down and dirty with my lovely Tableau Server environment to keep my skills fresh. Obviously I don’t mess with it – @jakesviz gets pretty protective about his Server.

This series of posts is my attempt to shed some light on the internals of Server. Note there are many more experts in this field than me (Craig Bloodworth, Mark Jackson, Jen Vaughan, Tamas Foldi, Mike Roberts, Angie Greenhaw – to name but a few) so please do comment if anything is incorrect here. Maybe you guys could help me evolve this post?

What is the backgrounder?

The backgrounder is a process that runs as part of the Tableau Server application. As the name suggests, it handles background tasks such as refreshing extracts, running subscriptions and also processes tasks initiated from tabcmd.

Here are the backgrounder processes. The .exe file and the .war file. The WAR file is a Web Application Archive, and contains all the necessary components and resources needed for a Web Application such as Backgrounder.

On a clustered environment you’ll find these files in D:\Program Files\Tableau\Tableau Server\worker.1\bin (may vary slightly with your installation).

28-01-2016 14-07-52

Other files related to the backgrounder.

Template (.templ) files – These files TBD

28-01-2016 14-13-09

There are also a few .rb files in D:\Program Files\Tableau\Tableau Server\worker.1\tabmigrate\db\migrate.

And we also have a .properties file which contains all the config entries relevant to the backgrounder. It also has almost all of the other stuff that you’d find in the main workgroup.yml file which is odd. I’d  have expected it to be just the backgrounder config.

backprops

Here is the location of the backgrounder log files

backlogs

Here are 2 instances of backgrounder.exe running on my server (from Task Manager).

28-01-2016 14-01-08

 

Can I mess with it?

Backgrounder can be configured. There are several settings present in both workgroup.yml and backgrounder.properties. Workgroup.yml is the master config file, and it populates the backgrounder.properties (and other .properties files) when a ‘tabadmin configure’ is run.

I don’t know what all of these do (yet) and the only one I’ve ever edited is ‘backgrounder.extra_timeout_in_seconds‘ which sets the max time in seconds that a backgrounder session can run for. Tableau kills off the session if this threshold is reached. Useful for forcing users to optimise their extract times!

I also pay attention to the ‘backgrounder.vmopts‘ parameter, as this defines the size of the java heap space for this component. All components have a vmopts setting and I’ve had to increase them on occasion due to out of memory problems.

You may also want to change the ‘backgrounder.log.level‘ if you need more debug info, although Tableau logs are chatty enough for me.

If there’s a golden parameter in this lot that you get value from then let me know in the comments.

backgrounder.deploy.dir: D:/Program Files/Tableau/Tableau Server/data/tabsvc/backgrounder
backgrounder.external_cache.concurrency_limit: 10
backgrounder.external_cache.enabled: true
backgrounder.external_cache.num_connections: 1
backgrounder.external_native_query_cache_disable: true
backgrounder.extra_timeout_in_seconds: 1800
backgrounder.failure_threshold_for_run_prevention: -1
backgrounder.jdbc.wg.connections: 8
backgrounder.jdbc.wg.idle_connections: 4
backgrounder.log.dir: D:/Program Files/Tableau/Tableau Server/data/tabsvc/logs/backgrounder
backgrounder.log.level: info
backgrounder.native_api.log.level: info
backgrounder.out_of_date_schedule_minutes: 240
backgrounder.ping_dataengine.millis_to_wait: 5000
backgrounder.ping_dataengine.num_retries: 24
backgrounder.ping_services.num_retries: 10000000
backgrounder.ping_services.time_to_wait: 5000
backgrounder.purge_directories.directories: ""
backgrounder.querylimit: 7200
backgrounder.restart_interval_in_minutes: 480
backgrounder.restrict_serial_collections_to_site_level: true
backgrounder.search_index_verification.enabled: true
backgrounder.sheet_image_api.max_age: 240
backgrounder.sleep_interval: 10
backgrounder.sort_jobs_by_run_time_history_observable_hours: -1
backgrounder.sort_jobs_by_type_schedule_boundary_heuristics_milliSeconds: -1
backgrounder.timeout_tasks: refresh_extracts, increment_extracts, subscription_notify, single_subscription_notify
backgrounder.tomcat.threads: 4
backgrounder.urlprefix: backgrounder
backgrounder.vmopts: -XX:+UseConcMarkSweepGC -Xmx512m

Note that Tableau Support don’t like you to edit config files manually, they recommend that you use the tabadmin set commands to change any parameters. They might have to change that recommendation when we see Tableau Server on Linux.

For more about .templ, Ruby & properties files check out this from Tamas Foldi.

 

What are the problems with the backgrounder?

Here are some of the things that can be problematic with the backgrounder.

  • Single Threaded – This means the backgrounder process can only run one thread at a time, a thread being a set of executable instructions that a process can perform. The upshot of this is that your backgrounder works through a queue of tasks one-by-one.
  • Latency – Due to the single threaded nature of backgrounder, you may see delays or ‘latency’. For example, if you have one backgrounder, and 2 tasks for it to perform at 2am, then task 2 will have to wait until task 1 has finished. If task 1 takes an hour then task 2 won’t start until 3am. This can be annoying for users that expect their data to be refreshed by a certain time.
  • Resource Intensive – The backgrounder can consume a significant amount of processing power (CPU) and input / output (I/O) on your server. This is dependent on the type of task it is performing. It’s not uncommon to see a backgrounder node consuming 100% CPU.
  • Other Stuff – The backgrounder process also does other stuff on Tableau Server that isn’t concerned with extract refreshes. For example – reaping extracts, checking disk space, synching Active Directory groups, rebuilding the search index etc. Bear that in mind when building your system. In reality these tasks don’t take up too much resource but they do take some and you should be aware.

 

Isolating the backgrounders

A common configuration in a clustered environment is to dedicate one of your worker nodes to the backgrounder processes. This means you can dial up the number of backgrounders and let them do their stuff without worrying about any impact on other processes. This is one of the most common performance recommendations from Tableau support.

You can also get a lot of info out of the Postgres DB relating to backgrounder usage and performance. Nelson Davis has posted a guide to getting started here.

 

Improvements I’d like to see

Ok so here are a bunch of improvements I’d like to see to the topic of backgrounders and extract management. I know some of this will drop in upcoming releases and some of these problems have been solved with custom solutions at some customer sites.

Alerting – Tableau Server doesn’t alert (email / IM / SMS) when a task fails. This means you’ll need to set up external monitoring to detect issues. I know Tableau are on this though so expect to see it in an upcoming version. Some people in the community have also coded their own solutions to this problem but it really should be native functionality.

Control per site – We segregate our dev / test / prod user environments using sites , all on the same server. We run 8 backgrounder processes on that server, which are shared across the tasks on all sites. As an administrator I’d really like to be able to bind backgrounder processes to specific sites. For example, 2 backgrounders on each of dev & test sites, then the other 4 dedicated to the production site. That would ensure production tasks always have enough resource to be able to execute on time.

Control per process – I’d like to be able to stop / pause / mess with individual backgrounder processes easily. It is possible – see this from Toby Erkson, but it would be good to have this as part of an administrator console or something.

Control per type / size / pattern of extracts – It would be good if I could dedicate specific backgrounder processes to particular extracts based on their characteristics. In particular I’d like to allocate one backgrounder to all the extracts that take less than 1 minute to complete. Or even use this to reward users that show diligence with their extract management by dynamically prioritizing incremental refreshes or extracts that have a low failure rate.

Better metrics – I’d like to see exactly how much CPU is taken up by a particular backgrounder process or task / schedule or per project. This would be useful for chargeback.

Dynamic reprioritisation – I love all my users. But in particular the ones that take good care of their extract refreshes. I’d like Tableau to be able to dynamically increase the priority of tasks that complete quickly, are incremental and that have a low failure rate. The message being, if you want your stuff to get the best slice of available resource then help us out with best practice.65

Disable run now – We’ve had some issues with the “run now” option that allows users to kick off an extract refresh on-demand using the UI. In particular we’ve seen some trigger-happy users bring our server down by hammering on the run now option multiple times. I’d like to disable that or maybe throttle it somehow.

Better guidelines from Tableau – The documentation from Tableau isn’t great in this area.

05-05-2016 13-09-11

I have an 8 core 128GB server and  run 8 backgrounders with no capacity issues. And I know of other organisations running way more than that. According to this doc I should be running between 2-4. That would be some serious under-utilization of the server. I’d like to see some clearer recommendations, maybe taking into account the variety of use cases that I’ve seen in other big enterprise deployments.

 

OK that’s all for now. This post could have been more detailed but I figure that I’ll get some valuable inputs from the community that will help me expand it. Actually in the time I was writing this, Mike Roberts was doing the same – check his post for some excellent info.

Cheers, Paul

 

How To Set Up Your Tableau Server Environments

Hi,

Guess what this post is about – yes TABLE CALCULATIONS…. haha. No chance. Talk to Jonathan Drummey about those. This is of course yet more info that I hope will help you guys set up a dream Enterprise Tableau deployment.

Today we are gonna talk about Environments – i.e. what Tableau environments should you create in your organisation to give your team the best chance of success and keep your lovely users happy?

As always, I’m not saying this is THE way to do it. There are tons of great setups out there. I’ll just tell you what we have. Feel free to suggest better methods in the comments.

 

Environments for your users

This section is concerned with environments that you will provide for your Tableau users to do their work. Typically this will follow the standard Information Technology Infrastructure Library (ITIL) environment definitions, but there are a few things you can do to add extra options for your users.

These are the environments our users have at their disposal:

  • Production – The main business & user facing environment. Content published here is authoritative, follows best practice (hopefully) and is actively supported.
  • Testing – aka UAT. Generally used for final testing of uploaded content
  • Development – The environment where content is first shared as part of the development process.
  • Scratch – An extra environment for content that doesn’t need environment management. E.g. User wants to temporarily share content with a couple of colleagues.

Providing these environments gives users crucial options and flexibility. Your Tableau service will most likely serve many different business areas and teams, each with different practices for content development and release management. Some teams will rigorously follow Systems Development Lifecycle (SDLC) processes, creating content in development, promoting to User Acceptance Testing (UAT) and then eventually to Production. Other teams are totally happy to change content directly in Production, as and when they feel like it.

Crucially we don’t mandate what our users do, it’s a self-service model and so long as they follow their own due-diligence and governance procedures then that’s cool with me. The important thing is that we give them options to work with Tableau in the way that they want. If they break anything then they know it’s down to them.

The scratch environment is an interesting concept. It started with good intentions but realistically not many people are using it. So it looks like we might bin that.

Note that we use Tableau sites to segregate our environments.

 

Environments for your team

This is different from the above user-facing environments. These are the environments that your team uses for the service you provide. Obviously all this costs money in terms of hardware procurement and usage, depending on the spec you choose.

  • Production – Main environment that serves your users. In our environment this also includes the UAT, Development & Scratch sites for users – but we class it all as production. That might seem odd, but remember that many teams will be development teams, and to them the development site / area is their equivalent of production. So if the development site is down then they can’t work.
  • Disaster Recovery (DR) – For use in the event of a Production outage that can’t be easily restored. Exact same spec as Production. Totally identical, so that config can be restored and this server can be used as Production. You’ll need to make sure this environment gets the same upgrades as your Production environment.
  • UAT – This is UAT for my team. If we want to make a change to Production, it gets final testing here. This environment is also the exact same spec as Production to ensure an accurate test. If it fails here then it’s likely to fail in Production as well. We use UAT for testing maintenance releases, config changes and other potentially disruptive non-Tableau related changes to the server. Additionally, we make this environment available to users for a couple of weeks UAT prior to releasing new versions to production.
  • Engineering – Lower spec than prod & UAT. For testing the latest available release from Tableau. That is likely to be a higher version than production. Is useful for spotting bugs in new versions or confirming that bug-fixes work.
  • Beta Test – We are proud to be part of Tableau’s pre-release testing audience. We use this server to test releases in the Beta programme. Lower spec than engineering. To the point that the server only just meets the minimum requirements.
  • Alpha Test – We use this to test the alpha releases or any extra work we may be doing with developers at Tableau. We love to be involved in the genesis of new functionality.

So that’s what we are lucky enough to have. It’s not perfect but it allows us to give our users a ton of flexibility in how they use Tableau, and also my own team always has a place to test new releases, plan upgrades and help Tableau with their pre-release programmes.

Interested to see what the community has in terms of environments. Let me know in the comments. Remember there are a load of other posts on this blog about Enterprise Tableau considerations.

Cheers, Paul

A Tableau Server Admin Toolkit

Hello again,

Here’s another post for you Tableau Server admins. Now Tableau Server runs on Windows. One day I’m sure those fine Tableau devs will release a Linux Server(!). In fact they’d better hurry up or Tamas Foldi is likely to beat them to it!

But Windows it is so we have to deal with it. This is a short post which provides some links to useful utilities that every Tableau Server admin should have in her or his arsenal.

Disclaimer – I’m no Windows Server Admin. If you are, or if you know of great alternatives to these tools then feel free to offer your professional solutions in the comments.

 

Baretail

baretail_thumb_1

Baretail

One of the most annoying things with Windows is the absence of a native ‘tail‘ command unlike UNIX. So if you want to see what Tableau Server is up to when you’re working on it then use something like Baretail to view the log files as they get updated.

The basic version of Baretail is free. It’s easy to use and does the job. It’s also a single executable file so no need to install. I use it a lot.

Screen Shot 2016-02-16 at 12.16.15

Who knew config changes caused worker re-installs?

I’d recommend tailing tabadmin.log every time you log onto your server, regardless of whether there’s an issue or not. You’ll learn a ton about the regular behaviour of the application. See this example screenshot here. I didn’t know that every time you hit OK on the “Configure Tableau Server” GUI then the Primary server goes off and uninstalls the tabsvc service on each worker and then re-installs it. Interesting to know that, and picked up by tailing tabadmin.log with Baretail.

 

Process Explorer

procec

Process Explorer

Chances are you’re all familiar with Windows Task Manager which is the native utility used for viewing process activity on your server. Trouble is, it’s pretty basic and hasn’t evolved too much since it first came out.

 

 

procexp1So instead I use Process Explorer. Has a lot more functionality and is very easy to use. In this screenshot you can see how the tabspawn.exe process has started a number of other processes, whereas the webserver (httpd.exe) runs independently and not under the control of tabspawn.

 

Xperf

xperf

Xperf

Xperf is a handy tool for logging all sorts of detailed operating system metrics. We’ve used it to analyse behaviour of Tableau Server processes in terms of CPU utilisation, memory use, disk and other process behaviour.

Not a tool that you can leave running on your system though as it generates shed loads of output and will burn your disk space pretty quickly. So use sparingly.

 

Fiddler

monitoring-http-traffic-with-fiddler2

Fiddler

Fiddler is a cool application and really useful. It’s primary use is to capture information from programs that use http. I’ve used it to spot issues with the webserver on the Tableau Server or to analyse some of the protocol information for various web sessions on the server.

For example, there was an issue with SSLv3 as per this article. Tableau support ensured us that Server would use the TLS protocol instead, but we had no way of knowing for sure. We used Fiddler to analyse the http traffic and confirm the protocol that was being used. Nice.

 

Wireshark

I like Wireshark. But then again I like anything with shark in the name. I’m a serious shark fan.

wireshark-24

Wireshark

Simply put, if you want to see what’s going on with the network on your Tableau Server then fire up Wireshark. It’ll tell you a lot of info including highly detailed network packet information. It also has pretty nifty colour coding for different packet types which makes usage easy for non-network folks like me.

 

 

Perfmon

42940-ms_perfmonWindows Performance Monitor is another handy tool. It collects a whole load of system metrics such as memory use, CPU etc and creates handy data sets that can be easily visualised (with Tableau of course!). In fact perfmon data is one of the first places we look when diagnosing root cause of issues.

 

JMonitor

I’ve never used this tool, but it comes recommended by a Server admin pal of mine. Glen from Interworks knows as much about everyone’s least favourite OS as anyone I’ve ever met. He’s also a Tableau Server expert so that’s a good enough recommendation for me.

So there you go. A handful of utilities that hopefully you won’t have to use too often. Of course the best way to not have to use these is to avoid issues in the first place. You can help yourself with good Tableau Server monitoring and by ensuring you take backups.

Cheers, Paul

How to Build a Tableau Support Team

Hi

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.

 

Some assumptions

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…

 

Support Levels

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.

More info on these roles and responsibilities here.

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!

quint

Quint was certifiable, just not in Tableau

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

1000509261001_1231344818001_Bio-Biography-Jackson-Pollock-LF-FIX

Let your team express themselves (with data, not paint)

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

human-league

We’re only human…

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???