Life as a TAM.... my unbiased take on the many hats that come with the job
As day 5 winds down in my new role as a sr devops engineer for Toyota Racing Development I was reflecting and wanted to write down what it was like on the other side. My promotion to customer as they say was not a decision i took lightly but ultimately it was made because it is what is best for my family. Not being on call for the first time in almost 15 years is also "very nice"(borat voice). In this blog, I wanted share my unfiltered experience as to what it was like in my two years covering one of the worlds largest auto manufacturers.
The Job itself
AS an AWS tam your primary focus revolves around a few areas depending on your customer and their cloud maturity. Most regional TAMS have a book of many clients to which they cover, some can be hands off, some can require more engagement. As a TAM in the strategic org you could cover one or two very large accounts. In My case I covered everything Toyota. This meant me and my team of 3 covered every Toyota business unit which ends up being like 8-10 separate accounts as each BU has their own workloads and cloud maturity.
As TAM your primary focus is being a customer advocate for your account. You get to wear many hats: Consultant, Escalation manager, incident commander, executive liaison, professional push backerer(the guy or gal that says no), the most important being a customer champion. Throughout my two years I spent a pretty good amount of time on the phone with customers on escalations. These uncomfortable conversations are difficult but end up being some of the best you have with the customer due to trust. Building trust is a huge part of being a TAM and sometimes that gets done in those firefights. Maintaining customer temperature might be the biggest part of the post sales process and that is definitely something you need to be ready for.
In my unbiased opinion, business reviews are where the tams shine and build the most trust. The primary focus of these is to go over cost, support, and security analysis providing recommendations. I helped my customer save millions of dollars by presenting facts and data that they had access to but didn't know how to ingest. Financial operations are key when you are talking scale and small areas of muda (waste) can add up. Using graviton saves in cost and performance and is pretty easy to move to. Business reviews can often be the most intimidating due to the audience which is targeted towards leadership/management. Just remember that you are delivering high value content and to be confident in your recommendations.
Workshops and office hours
Workshops are fun because it gives you a chance to either run or, bring in an expert to run a group event. These are normally targeted for enablement and some of them are actually quite fun. As a tam when you are teaching something it forces you to learn things at a different level. These types of engagements can be hard to get scheduled with the customer and you will sometimes have issues with setup/prepping the class. Overall though these were my favorite as you either hone or learn new skills.
Office hours are held normally on a weekly, bi-weekly, or monthly basis depending on the customer and their needs. As things start ramping up i imagine these will start being more towards the weekly side with TAMs, SAs, and GAMs, camping out in a conference room. Be prepared to field questions about cases, spending snafus, and other random aws issues that they might have. I also used this time as a chance to go over any issues going on with operations such as cases being opened with wrong severity or lack of responses from those who open the cases. This is something you will see and have to manage, sometimes requiring executive escalation. My best experience was exposing the knuckleheads during business reviews to the leadership team and that fixed it pretty quickly.
"AH fuck- Everything is on fire--- " Me December 7th last year as im getting out of my Deer Blind on being paged for this event. This is part of the job that cant be predicted and is what it is. TAMS are put in a very difficult position as we have no access to actually fix the problems and can only deliver what information is given. I think the big thing and biggest improvement with NDA wording, is know timelines and when things will be back up. A couple of my customers got hit hard and could not implement their DR because apis were shot. Not having time tables makes it hard to set time contracts which is a key element in incident management. During these times you really feel the pain that your customer is going through so be prepared mentally for that. I had to take a pretty good break a few weeks after the December incident because of the stress. Like marshawn said, take care of your mentals and your chickens.
###Giving back to the business
This type of work is normally TFC or hiring work. I chose TFC just because i love builder experience and wanted a ticket to reinvent. The AWS hiring process is very unique and I enjoy sitting in loops. It can be demanding time wise but the overall process is awesome, something I highly recommend. I also would recommend joining a TFC in whatever is your wheel house. Like i said earlier, I joined the Builder Experience one because I love helping developers build fast and also love Fault Injection simulator which is part of the BeX. This also gives you access to other customers as you get to field specialist requests. I enjoyed talking to other customers, seeing what their workloads look like, and understanding their problems. You also get to present alot in a TFC if that is something you like to do.
Overall I really enjoyed my time at AWS as a TAM. I got to work with some of the smartest people in the world on some of the coolest tech. I def recommend giving the job a shot if you are looking to get into the account management side. Every customer is different so there is no one right way to TAM, I just did my best with the cards I was dealt. Hope this article helps those that are interesting in Technical Account Management. Cheers mates!
A few weeks ago, I wrote about My lessons at AWS, learn from my mistakes :). give it a read :D