Recently I wrote a short LinkedIn post on this topic which blew up. The feedback made me realise that I had knowledge that others genuinely wanted to hear. So here is a more in depth version.
This is written for SAs, TAMs and anyone else in the technical field because that’s what I have experience in. Others have said that it has helped them in other roles and at other companies, which is fantastic.
The majority of people I’ve met who join the SA community at AWS are from a technical background. They might have been senior engineers, architects, DBAs etc, and they are thrust into a completely different type of organisation. Now instead of making something for someone, they are advising a customer of AWS. This can take a while to get used to. Along with this change, you also get exposed to the enormity of AWS and typically work in very small teams, if not solo. The variety and scope of work involved as an SA is also very unusual. One day could be an architecture review, the next a security incident review with a CSO, the next a customer enablement session, the next public speaking. This is why I personally enjoy the work as an SA so much. I enjoy the variety and freedom to work in a way that I think will have the most impact. This all takes a lot of readjustment, and time. You have to learn the gaps in your knowledge, you have to learn about your customers and their own priorities and goals, you have to build a relationship with the account managers you work with.
It can easily be two years before you lift your head up and realise that you’ve only been doing transactional work, and you’ve not impacted anything outside of your direct customers. Also as a quick aside, you’re also being exposed to the successes of some of the best technical people in the industry. It’s hard to not compare their best successes to your everyday work, and think you’re not good enough.
After this period, you have done a heap of AWS work. You’re an experienced SA with most likely lots of successful customer projects. Along the way you’ve built proof of concepts, and seen customers support cases. You know the problems with services, their rough edges, the differences in experience when using API X compared to Y. You start to get frustrated because you know what needs to be done and you fire off emails to service product managers, but nothing seems to change. You add customer feedback to product feature requests, but again you might not hear anything back, or it might just take a longer amount of time than you’re expecting.
I’ve seen people leave at this stage because they want to be able to effect change, but they don’t know how. Here is where AWS is different from a lot of other companies. The way that ideas, projects, initiatives are agreed is through writing and reading. Having an amazing idea, and telling other people about it will likely not prove effective. There is also no culture of PowerPoint presentations or after work pitching in a bar.
You start by writing out the customer problem. How is the customer impacted by a service and its current design? What would be the benefit to the customer if this problem was no longer an issue. How many customers does this affect? What would be the overall impact of an improvement?
This alone is valuable, even if you don’t propose a solution. The problem statement can be shared with the service team. It might be new to them, or it might be an additional data point for something they’re already working on.
If you do have a solution, now’s the time to get it written down. The mere act of trying to write down your idea will force you to think through it more. It will open up gaps you’ve not thought of yet. Explaining a technical solution to others is difficult. After a few iterations, start to share your work with other people you know have experience in the problem space you’re working in. If you don’t know anyone, now’s the time to speak to your manager, they’ll most likely have names for you to follow up with.
Getting feedback on an idea can be hard, just like a code review. The difference in feedback between different people can vary a lot, over time you’ll learn what type of feedback you want and which part of the lifecycle you’re in. You’ll be able to select a variety of different opinions. Always try to prove yourself wrong. If you only seek opinions from people you know think as you do, you might be losing an opportunity to improve.
Once you have a document written, you’ve done the easy work. Now you have to get someone who can make a decision to read it. Depending on your tenure and network this might be easy or difficult. Try to find the product manager most closely aligned with the service feature you’re proposing changes to. Arrange a meeting with them to go through your idea. Your idea must have a clear customer benefit and that should be clearly expressed in the invite. You can send a link to your document, but the expectation shouldn’t be that they’ll read it beforehand. It’s most likely they’ll read it in the time you’ve scheduled.
The outcome of this meeting will most likely be that the idea is interesting but doesn’t have the data required to be prioritised. This isn’t a failure. It’s the reality that AWS has a huge amount of potential improvements that could be made, and only a limited amount of resources to assign. Take the feedback and iterate on it. Continue to collect data points from other customers who have the same pain.
Over time you’ll have docs that never seem to progress. Only you can decide whether to continue to focus on them, or drop them from your focus. With persistence and by continuing to listen to customers, you will have successes and changes will be made due to work you’ve done. This feels great, there is no greater opportunity to have a scaling impact than improving a service for every customer.
Now what? You’ve had some experience, some success.
Decide what you want to focus on. What do you want to be an expert in? When deciding, be ambitious, think big. You don’t need to solve the problem in one go, most likely you’ll be working to make improvements bit by bit. Being a known expert is important because it reverses one of the difficult problems, data. Now people come to you with customer issues which will provide you with the data you need to validate, or counter your ideas.
Find other people who share your interest and make a community. This can be as simple as a slack channel. Use it to share what you’re doing, encourage others to share what they’re doing as well.
Time to level up!
Opportunities for improvements are everywhere, which should you spend your time focusing on? In my opinion, try to stay focused on a specific area / theme / expertise. By doing this, your previous experience, network, and credibility will lend weight to your future interactions.
Focus on opportunities you have the likely ability to influence. Proposing the next greatest service might make complete sense to you, but in all likelihood is a problem too big to focus on outside of a service team. Exercise the muscle on something within your sphere of influence. This is a skill. There are often many solutions to a problem. You’ll learn that some can be completed without involvement by a lot of other people. Although this might not be a perfect solution, that’s ok. Making progress, and moving fast is important. This initial solution should include a mechanism for collecting feedback to be used as data for a more complete solution. This is also satisfying, as nothing is more frustrating than thinking you need someone else in order to progress. Ask yourself what is the smallest thing you can do to progress the solution yourself.
Examples of small steps could be open sources examples of doing something well. It could be blog posts explaining a common problem and workaround. It could be a fix to an open source library.
Don’t work in a vacuum, make sure that the customer pains and your work to improve them are being reported. Find out who writes monthly reports in your org (2x2, MBR) and write good single paragraph summaries for them. This is another opportunity to reverse the regular way of working by having leadership read about your work and having them ask you what else should be done.
Level up again
Refocus. Read other people’s strategy docs (OP1, OP1). Find something in those which aligns to your expertise. Working with a larger initiative is much easier than working on a tangent.
Use your successes, credibility and the trust you’ve earned to expand the size of the problem you target. Collaborate with your peers with more of a business development mindset. Think about how your ideas can be incorporated into a larger go to market strategy.