AWS Account Teams and You

Transcript
Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com.

Jesse: Hello, and welcome to AWS Morning Brief: Fridays From the Field. I’m Jesse DeRose.

Amy: I’m Amy Negrette.

Tim: And I’m Tim Banks.

Jesse: This is the podcast within a podcast where we talk about all the ways we’ve seen AWS used and abused in the wild, with a healthy dose of complaining about AWS for good measure. Today, we’re going to be talking about, really, a couple things; building your relationship with AWS, really. This stems from one of the questions that we got from a listener from a previous event. The question is, “How do the different companies that we’ve worked with work with AWS? Is the primary point of contact for AWS at a company usually the CTO, the VP of engineering, an architect, an ops person, a program manager, or somebody from finance, a [unintelligible 00:01:00] trainer? Who ultimately owns that relationship with AWS?”

And so we’re going to talk about that today. I think there’s a lot of really great content in this space. Pete and I, back in the day, recorded an episode talking about building your relationship with your account manager, and with your TAM, and with AWS in general. I’ll link that in the show notes. That’s a great precursor to this conversation. But I think there’s a lot of great opportunities to build your relationship and build rapport with AWS, as you work with AWS and as you put more things on the platform.

Amy: I think one of the things we always say right off the bat is that you should introduce yourself and make a good relationship with your account manager and your technical account manager, just because they’re the ones who, if you need help, they’re going to be the ones to help you.

Jesse: Yeah, I think one of the things that we should also take a step back and add is that if you are listening to this and you’re saying to yourself, “I don’t have an account manager,” that’s actually wrong; you do have an account manager. Anybody who’s running workloads on AWS has an account manager. Your account manager might not have reached out to you yet because usually speaking, account managers don’t reach out unless they see that you’re spending a certain amount of money. They usually don’t start a conversation with you unless you specifically are spending a certain amount of money, have reached a certain threshold, and then they want to start talking to you about opportunities to continue using AWS, opportunities to save money, invest in AWS. But you definitely have an account manager and you should definitely start building that rapport with them as soon as possible.

Amy: First question. How do you actually engage your account manager?

Tim: So, there’s a couple ways to do it. If you have reached a certain spend threshold where your account manager will reach out to you, it’s real simple: you just reply back to them. And it kind of depends. The question most people are going to have is, “Well, why do I need to reach out to my account manager? If I just have, like, a demo account, if I’m just using free tier stuff.”

You probably don’t ever need to reach out to your account manager, so what are the things, typical things that people need to reach out to their account manager for? Well, typically because they want to grow and want to see what kind of discounts are offered for growth, and I want to see what I can do. Now, you can open a support ticket, you can open a billing ticket, but what will end up happening is once you reach a spend threshold, your account manager will reach out to you because they want to talk to you about what programs they have, they want to see how they can help you grow your account, they want to see what things they can do for you because for them, that means you’re going to spend more money. Most account managers within a little bit of time of you opening your account and reaching a lower spend threshold, they’re going to send you an email and say, “Hey, this is my name, this is how you reach me,” et cetera, et cetera. And they’ll send you some emails with links to webinars or other events and things like that, and you can typically reply back to those and you’ll be able to get your account manager sometimes as well. But like I said, the easiest way to get a hold of your account manager or find out who it is, is to start increasing your spend on AWS.

Jesse: So, then if you’re a small company, maybe a startup or maybe just a student’s using AWS for the first time, likely that point of contact within a company is going to be you. From a startup perspective, maybe you are the lead engineer, maybe you are the VP of engineering, maybe you are the sole engineer in the company. We have seen most organizations that we talk to have a relationship with AWS, or build that relationship or own that relationship with AWS at a engineering management or senior leadership level. Engineering management seems to be the sweet spot because usually, senior leadership has a larger view of things on their plate than just AWS so they’re focused on larger business moves for the company, but the engineering manager normally has enough context and knowledge of all of the day-to-day specifics of how engineering teams are using AWS to really be involved in that conversation with your account manager, with your technical account manager, or with your solutions architect, or whatever set of folks you have from AWS’s side for an account team. And I think that’s another thing that we should point out as well, which is, you will always have an account manager; you won’t always have a technical account manager.

The technical account manager generally comes in once you have signed an enterprise discount program agreement. So, generally speaking, that is one of the perks that comes with an EDP, but obviously, there are other components to the EDP to be mindful of as well.

Tim: So, let me clarify that. You get a technical account manager when you sign up for enterprise support. You don’t have to have an EDPs to have enterprise support, but when you sign up for enterprise support, you automatically get a technical account manager.

Jesse: And, Tim, if you could share with everybody, what kind of things can you expect from a technical account manager?

Tim: So, a technical account manager, I mean, they will do—like, all TAMs everywhere pretty much can liaise with support to escalate tickets or investigate them and see what’s going on with them, try and, kind of, white-glove them into where they need to be. AWS TAM’s, they also have the same—or a lot of the same access to the backend. Not your data because no one at AWS actually has access to your data or inside your systems, but they have access to the backend so they can see API calls, they can see logs, and they can see other things like that to get insight into what’s going on in your system and so they can do analytics. They have insight to your billing, they can see your Cost Explorer, they can see what your contract spends are, they can see all the line items in your bills, they have access to the roadmaps, they have access to the services and the service teams so that if you need to talk to someone at a particular service team, they can arrange that meeting for you. If you need to talk to specialists SAs, they can arrange those meetings for you.

With a TAM, you—and if you have enterprise support, and they’re looking you for an EDP, you can have what’s called an EBC or an Executive Briefing Council, where they, in non-pandemic times, they will bring you to Seattle, put you up for a couple of days and you’ll have a couple of days of meetings with service teams to go over, kind of like, what the roadmap looks like, what your strategy for working with those teams are or working with those services are. And you can get good steps on how to utilize these services, whether it’s going to be some more deep dives on-site, or whether it’s going to be some key roadmap items that the service team is going to prioritize and other things like that. And the EBC is actually pretty neat, but you know, you have to be larger spender to get access to those. Another thing that a TAM can do is they can actually enter items on the roadmap for you. They have access to and can provide you access to betas, or pilot programs, or private releases for various services.

You’ll have access to a weekly email that include what launches are pending, or what releases are pending over the next week or two weeks. You’ll have access to quarterly or monthly business reviews where you get access to see what your spend looks like, what your spending trends are, support ticket trends, you know, usage and analytics, and things like that. So, a TAM can be quite useful. They can do quite a lot for you, especially in the realm of cloud economics. That said, every TAM has their specialty.

I mean, depending on how many customers they have, the level of engagement you may get. And, you know, some TAMs are super, super, really good at the financial aspects, some are better at the technical aspects. So, to be fair because the TAM org is so large at AWS, you don’t always have the same experience with all your TAMs, and the level of depth to which they can dive is going to vary somewhat.

Corey: This episode is sponsored in part by ChaosSearch. You could run Elastic Search or Elastic Cloud or Open Search, as they’re calling it now, or a self hosted out stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for App performance monitoring, cyber security. If you’re using ElasticSearch consider not running ElasticSearch. They’re also available now on the AWS market place, if you prefer not to go direct and have half of whatever you pay them count toward your EDP commitment. Discover what companies like, Klarna, Equifax, Armor Security and Blackboard already have. To learn more visit chaossearch.io and tell them I sent you just so you can see them facepalm yet again. 

Amy: So, let’s say we got the best TAM—even though he technically works for us now—when trying to envision what our relationship with the world’s best TAM is going to be—and I just imagine that as a nice little block text on a white mug—what is that relationship going to look like? How are we going to engage with them? And even, how often should we talk to them?

Jesse: I used to work for an organization that had, I believe, quarterly meetings with our account manager and our TAM, and every time we met with them, it felt like this high stakes poker game where we didn’t want to show our cards and they didn’t want to show their cards, but then nobody really was able to do anything productive together. And I have to say that is the exact opposite of how to engage your account manager and your TAM.

Tim: Yeah, that doesn’t sound great.

Jesse: No, it was not great. I do not recommend that. You want to have an open, honest conversation about your roadmap, about what you want to do with AWS.

Amy: They’re not getting that mug.

Tim: No, no.

Jesse: [laugh].

Tim: So, if you have a super-engaged TAM—and I will use my own experience as a TAM at AWS—that we had office hours, routinely, bi-weekly. One customer I had, I would have onsite office hours at their offices in LA, and I would have virtual office hours in offices in London. And those office hours, sometimes I’d have—we—that—we would use those to bring in, whether it was specialist SAs, whether we go over roadmap items, or tickets, or something like that, or we do architectural reviews, or cost reviews, we would schedule quarterly business reviews aside from that, typically sometimes the same day or on the same group of days, but there was typically be different than office hours. I was in their Slack channel so they needed to ping me on something that’s not a ticket but a question, we could have conversations in there. A couple of their higher points of contact there had my phone number, so they would call me if something was going on. They would page me—because AWS TAMS have pagers—if they had a major issue, or, like, an outage or something [unintelligible 00:11:05] that would affect them.

Jesse: I’m sorry, I just have to ask really quick. Are we talking, like, old school level pager?

Tim: No, no, no. Like on your phone, like PagerDuty.

Jesse: Okay, okay. I was really excited for a minute there because I kind of miss those old-school pagers.

Tim: Let me say, it was like PagerDuty; it wasn’t actual PagerDuty because AWS did not actually use PagerDuty. They had something internal, but PagerDuty was the closest analog.

Amy: Internal PagerDuty as a Service.

Tim: Something like that.

Jesse: Oh, no.

Amy: So, you know, if you have a very engaged TAM, you would have regular, several times a week, contact if not daily, right? Additionally, the account team will also meet internally to go over strategy, go over issues, and action items, and things like that once or twice a week. Some accounts have multiple TAM, in which case then, you know, the touchpoints are even more often.

Jesse: I feel like there’s so much opportunity for engagement with your AWS account team, your account manager, your TAM. It’s not entirely up to you to build that relationship, but it is a relationship; it definitely requires investment and energy from both sides.

Tim: And I would say in the context of who’s working with a TAM, ideally, the larger contact paths you have at an org with your TAM, the better off it’s going to be. So, you don’t want your TAM or account team to only talk to the VP of engineering, or the DevOps manager, or the lead architect; you want them to be able to talk to your devs, and your junior devs, and your finance people, and your CTO, and other folks like that, and pretty much anyone who’s a stakeholder because they can have various conversations, and they can bring concerns around. If they’re talking about junior devs, your TAM can actually help them how to use CloudFormation, and how to use a AWS CLI, or do a workshop on the basics of using Kubernetes, or something like that. Whereas if you’re going to have a conversation with the VP of engineering, they’re going to talk about strategies, they’re going to talk about roadmap items, they’re going to talk about how things can affect the company, they’re going to talk about EDPs and things like that. So ideally, in a successful relationship with your TAM, your TAM is going to have several people in your org are going to have that TAM’s contact information and will talk with them regularly.

Jesse: One of the clients that we worked with actually brought us in for a number of conversations, and brought their TAM in as part of those conversations, too. And I have to say, having the TAM involved in those conversations was fantastic because as much as I love the deep, insightful work that we do, there were certain things about AWS’s roadmap that we just don’t have visibility into sometimes. And the TAM had that visibility and was able to be part of those conversations on multiple different levels. The TAM was able to communicate to multiple audiences about both roadmap items from a product perspective, from a finance perspective, from an engineering architecture perspective; it was really great to have them involved in the conversation and share insights that were beneficial for multiple parties in that meeting.

Tim: And oftentimes, too, involving your TAM when you do have this one thing in your bill you can’t figure out, saying, “We’ve looked and this spend is here, but we don’t know exactly why it is.” Your TAM can go back and look at the logs, or go back and look at some of the things that were spun up at the specific time and say, “Oh, here was the problem. It was when you deploy this new AMI, it caused your CPU hours to go way, way up so you had to spin up more instances.” Or a great one was a few years back when Datadog changed its API calls and a lot of people’s CloudWatch costs went through the roof. And then several TAMs had to through and figure out, it was this specific call and this is how you fix that and give that guidance back to their customers to reduce their spend. So, being able to have that backend access is very, very useful, even when you are working with an optimization group like ourselves or other folks, to say, “Hey, we’ve noticed these things. These are the line items we want to get some insight into.” I mean, your TAM can definitely be a good partner in that.

Jesse: All right, folks, well, that’ll do it for us this week. If you’ve got questions that you’d like us to answer, please go to lastweekinaws.com/QA. Fill out the form; we’d be happy to answer those on a future show. If you’ve enjoyed this podcast, please go to lastweekinaws.com/review and give it a five-star review on your podcast platform of choice, whereas if you hated this podcast, please go to lastweekinaws.com/review. Give it a five-star rating on your podcast platform of choice and tell us, did Tim pronounce the shortening of ‘Amazon Machine Image’ correctly as ‘ah-mi’ or should he have said ‘A-M-I?’

Amy: I heard it and I wasn’t going to say it. [laugh].

Jesse: [laugh].

Amy: I was just going to wait for someone to send him the t-shirt.

Tim: Just to note, if you put beans in your chili, you can keep your comments to yourself.

Jesse: [laugh].

Amy: You’re just going to keep fighting about everything today, is all I’m—[laugh].

Jesse: [laugh]. Oh, no.

Announcer: This has been a HumblePod production. Stay humble.