What's a TAM and why might you want to be one?

A TAM is a technical account manager, but what does that even mean? The IT industry has latched into the idea of a TAM, and many companies offer TAM as a subscription. Maybe you're curious about whether your business needs the services of a TAM, or perhaps you're considering if you might make a good TAM. Either way, this article is for you!

When I considered joining Red Hat as a TAM, I can say that the whole concept was a little fuzzy. Would I be a glorified help desk staff member? Am I working tickets? Didn't I spend my entire career trying to move out of a support role? And, while technical support is a vital part of any enterprise, I was ready to grow... why would I go back? Well, in this article, I'll try to demystify the position, and maybe it'll help you decide if you'd like to be a TAM or employ one.

[ You might also enjoy reading Security when you're suddenly remote. ]

Different companies, different TAMs

I want to start by stating that not every TAM role is the same. Every company that's decided to offer TAM as a service does it slightly differently. Some TAMs are closer to a support role, while others are more on the advisory side. I've talked to some TAMs at other companies that "wear a pager" (do you remember pagers?) and are expected to respond 24x7. Some aren't that on demand but are expected to handle all support cases for a customer and be their single point of contact for support. Others still are purely advisory. At Red Hat, we're somewhere in the middle.

At Red Hat, every TAM is given some leeway to handle the role as it works for them. As long as we're fulfilling our duties and the customer is happy, no one's looking over our shoulders to make sure we're doing it "right." We are not on call during off-hours and we're expected to work 9-5 Monday to Friday. We're also not expected to be subject matter experts on every single technology Red Hat supports. We leverage our own industry experience, technical expertise, and network of contacts within Red Hat to make sure our customers are getting the best available support. We hold periodic meetings with the customers that we're assigned. We use those meetings to learn about our customers' deployments and pain points.

With that information, we help shepherd support requests from our customers. This is another case where each TAM handles things differently. Some take ownership of those requests and then reach out to experts at Red Hat to get the answers they need. Others let the frontline support engineers own the requests and then actively work with them to ensure things go as smoothly as possible.

TAM at Red Hat is more than support, though. We help customers stay informed on upcoming releases of software that they depend on. We also help review deployments and upgrades. Personally, I love diving deep into security vulnerabilities to keep my customers informed on how these affect them and what they need to do to protect their environments. We never touch the customer's equipment though, that's the line between TAM and Consulting/Services.

Should you subscribe to a TAM?

This really depends on your team. I have worked with teams that have a lot of skill and they still get value out of a TAM.

It all depends on how you engage with us. We can't help you if you don't engage with us. We need to know what you need and we need opportunities to help you. However, if you lack expertise in a particular area, a TAM might be just what you need to help guide things through to resolution. The key is still engagement, though. Without engagement, we have to try to guess what you need. Without direct feedback, we could focus on the wrong things. If you'd like to learn more about subscribing to a TAM, you should talk to your Red Hat account team.

This sounds awesome; maybe I want to be a TAM?

I have to say I was hesitant coming into the role. I couldn't shake the notion that I was moving from my nice back-end sysadmin role into a more customer-facing support role. I worked in level 1 support early in my career, and I have to be honest, I did not enjoy it. I do enjoy helping people, but I do not like being in a call center and answering every little simple question 20 times a day. I'm here to tell you this is not what it's like to be a TAM. Luckily, I had two friends working at Red Hat—one as a TAM and the other started as a TAM and moved into a software engineering role. They both helped me better understand what it really is to be a TAM. I took the chance and applied. I haven't regretted it for a second since I was onboarded and started doing the job.

Of course, I can't tell you what it's like to be a TAM elsewhere, but my TAM friend framed it well when he told me this:

"TAM is where old sysadmins go as a reward for all of their years on call" - Unclemarc

Not every IT operations person is well suited to be a TAM, though. There is a definite people aspect to it that you should consider. You have to be able to build relationships with your customers and you have to present yourself in a professional manner. I've known folks who were spectacular as engineers or sysadmins but really lacked those presentation and personal skills essential for success as a TAM.

[ New research from HBR Analytic Services: IT talent strategy: New tactics for a new era ]

Wrap up

At the end of the day, I can't tell you if this role is right for you, but I can tell you that it's worked out well for me so far. If you'd like to apply for a TAM role at Red Hat, you can almost always find an opening on our Red Hat Jobs site.

I hope this has helped to clarify what a TAM is and what we do—at least at Red Hat.