So, what do you do when you love technology but are ready for a change in the day-to-day activities of a DBA? One consideration is to become a Technical Account Manager, or TAM for short. At Percona, a TAM is an account manager who is also technical (the big “T” in TAM). While everyone’s path is different, I will share my story of how I ended up a TAM.
Becoming a Technical Account Manager
I began working with a small Internet Service Provider, or ISP. Back in those days, one had to be a jack-of-all-trades. I did web development, systems administration, database administration, and more. Those were the days when MySQL 3.23 was all the rage, and as I worked more and more with it, I specialized my career towards DBA work. For many years of my career, I went from MySQL DBA to Senior MySQL DBA, to MySQL DBA Team Leader. I shared pager duty with my team and was frequently on-call. Many years of that began to take a toll and I wanted something different.
It was then that I began to look into Consulting and even started a consulting business with a friend. The excitement of working with companies and solving their problems was fresh. It felt great to deal with new and exciting challenges on a daily basis, but after a while, I wanted something different.
This is when I got an exciting new opportunity to work with Percona as a Technical Account Manager. I have to admit, I wasn’t entirely sure what the position entailed when I interviewed. In fact, I had interviewed as a Consultant when I was told about the TAM position, and it sounded like a fresh change and a chance to grow my skills in another area of expertise and even combine my talents.
Once in the role, my first task was to help the team define the role. We worked on creating standards and documentation and so on. You know the kind of stuff everyone has to do, but no one really likes doing. After days of working through this, the time finally came to get on a call with a client.
I was never one that loved speaking on calls. So, how would it go? Would I learn to like the role? I was shocked during the first call when I realized how natural it was for me. I was combining my skills as a DBA, Consultant, Support Engineer, Architect, and so on, to solve real problems. Instead of being limited by the corporate structure I had come from, I was free to build solutions and solve problems in whatever manner was most appropriate. And you know what? Clients appreciated it!
What Exactly Does a TAM Do?
You may be asking, as I did initially, what exactly does a TAM do? In a nutshell, we combine all of our life experiences with technology to help clients solve problems. And not just any client – some of the largest clients which are household names. We spend a fair amount of time listening to the challenges clients face and probe with challenging questions to find the root of their issues. We look for patterns and trends over multiple issues to see how systems and processes can be improved. We identify the pain points that are holding companies back from meeting their goals or going to the next level.
Once we identify the root causes of the issues, we work to find solutions. If the solutions lie within our particular skill sets, we begin to architect solutions. When the requisite skills lie outside our capabilities individually, we search within all of Percona to find experts across our teams who can solve the problems and then work with them to architect solutions. We leverage the diverse skill sets across departments to give customers solutions they can implement.
But that is not where it ends. When I was a Consultant, that was the end of my engagement with the customer. The part that left me lacking was never getting to see the solution implemented and working through any unforeseen issues or challenges. I never really had the satisfaction of knowing I built something and feeling the great accomplishment and ownership in seeing my solution implemented. I wanted more.
Now as a TAM, I work with the customer to drive adoption and implementation of the solution. I first meet with their technical team and management to explain why they should adopt the solution, what benefits it brings, problems it solves, and more. Once we get buy-in, I then go back to the technical teams and work through project planning, through development, testing, and finally implementation of the solution. I am there along the way as the Proof of Concepts (POCs) are built, when testing teams run gamuts of tests, and finally, the solution is implemented into production. I never had that level of satisfaction as a DBA or even as a Consultant.
Sure, there are challenges as with any role. Sometimes, you wonder how you will solve issues or stress over how it will perform. But, once the hurdles are cleared, there is an extreme amount of pride in seeing projects all the way from the idea stage to live production. Is TAM a natural progression from DBA? Probably not for everyone, but for me it has been an exciting way to bring together a number of experiences into one role that is rarely the same from day-to-day.
When you are able to help your customers grow and solve their issues, you make some incredible friends. My clients are more than customers; they are truly my friends. This makes it less of a job and more about doing everything I can to help my friends succeed!