It's been a long journey, but I've been in IT for a little over 20 years. I went to Berkeley from the ground, studied CS there. I thought it sounded interesting, was fun and it fitted with my logical brain and I enjoyed the problem-solving aspects of it and after that, I ended up getting a job right out of school, it was a consultant work in a company called Sapient that are part of publicists. For six and a half years, I did that consultant job, worked on custom bespoke applications for enterprise customers, worked for companies like Becca, Boston, U. S. Marine Corps. A variety of trading applications, financial, oil and gas industry, luckily it moved me around a bit. They helped me to move to Europe for 3 and a half years. I wanted to do something more product-oriented, So I switched over to Microsoft's, ended up getting a job as a program manager there for about two and a half years, working in the NET framework and then a friend of mine worked at Amazon back then in 2005, and he said, "Hey, I would like to take your interview for a product manager" and I said, "Sure sounds great". I jumped on that as an opportunity, I was now in Seattle, the Seattle area, having worked at Microsoft, and when I left Microsoft, they said," I don't know why you're leaving IT company for retail?" but this is the very beginning of Amazon Web services as it turned out, I might happen to land right there in 2005, I was a product owner. I used to own the first web services, AWS, it was actually about the retail site. I owned that for about three years and then switched over to a role that was just created called, Solutions Architect, which is what I've been doing for the last 10 years and that has been all about providing architectural and technical advice to customers on how to leverage cloud services. In Amazon, I worked in the early days with the commercial team, I helped to start pro serve group, I worked on the partner size law, I guided partners and then eventually switched everything to work on Alexa for a while. For a couple of years, I've been building integrations there and then left for a short stint with a small start-up. It turned out that it wasn't a great move for us. So, I spent about five months there and then switched over to right now where I'm at which is Google where I'm working as a Solutions Architect providing architectural and technical advice but mostly focused on capturing best practices, approaches to solve the large customer challenges as best as we can. I provide guidance and mentor wherever it is needed. In terms of instance and experiences that shape my path, there is a lot of it. People comment like, "Oh, wow, that's such a good career path" and in many ways, a lot of it was luck like meeting the right people at the right time, building a network over the years. Linkedin was always there when I was younger, but now it's like a fantastic way to stay connected with all the people I've worked with, and that's always been a great opportunity to keep my ear to the ground, listening to what's actually coming and then just being in the right place at the right time.

Solutions Architect job is pretty variable. It's definitely a later career kind of a job and since that often the expectations are there after several years of designing and building applications on a large scale. A lot of this role is about engaging customers, partners and product teams to help in shaping opinion, providing guidance and helping to develop a better understanding for our customers, adoption becomes easier for cloud service. So one week it could be working directly with customers during video calls or fly to their site, direct architecture sessions of training and other weeks it could be more focused on internally working with product teams on road maps, helping them understand what's happening in the field? What do customers want? Working with marketing teams internally to help to shape the message and also deliver it to the field. So, there's really no standard week. It is really about what people approach you with, what challenges the field is facing and how can you best serve to alleviate them. In terms of where I'm at? I am sitting at home, I'm going to work from home quite a bit just because much of my interaction is with customers who are out in the fields, who are in different places, a lot of virtual interaction. But then at the top of that, a couple of weeks I'm headed out to do a work trip down to Australia, to work with several customers and doing some workshops and then after that we have a big conference in San Francisco, so I do travel, you can call it 25% of the time, just to be there, people do require that in-person support dozens of time and then other weeks are in the office, working with individual teams, working with my colleagues to come up with what we think best practices are and then capturing that, building a plan on how are we going to deliver that from the perspective of the content.

There are a lot of different types of roles you can interact with, especially as a Solution Architect. In many ways, I think it is kind of that bridge between the customer and the product. So with that, it means that, if it's a new product, you might spend time with the product, product owners, directors of product management, directors of engineering to decide what's the right thing, so that is a voice of the field that fuel the customers and that's an example. Then from there, it's working directly with developers at times to test out our products, working with the marketing team like product marketing managers and product managers on helping to shape and craft that message, What the field will hear? How we're going to deliver it from a technical perspective, highlighting business benefits, technical benefits of the product versus the rest of the market that's a lot of internal-facing stuff. On the outside, I work a lot with our sales teams that are handling those customer relationships directly and then helping them figure out strategies around on How to sell into that account? How we can position our products and service in the best possible light to make them fit into the customer's need. So, field sales representatives, customer engineers, sales engineers and a lot of interactions are there, as well specialists are there in the field and then lastly but obviously most important is the customers and so when speaking to customers, I often have different levels. Early in the engagement, I might work with the C suite so CEO, CIO, CTO, helping them understand the positioning of Google Cloud, where it fits, how they should think about it relative to their digital transformation. Taking a notch down from that, then it's business owners, directors of IT, directors of engineering enterprise architects, helping them understand the technical strategy and then ultimately when we get to a real problem that we're trying to solve its hands-on, that's usually a lead architect or software Bowman engineer or manager, helping them find the right path. In many ways, the Solutions Architects and all of those individual interactions that different sorts of periods in the life cycle of the product, as well as the opportunity of the customer. In terms of being the most effective, what I find most effective is recognizing that there are multiple, different angles to every problem and multiple different approaches people take and really a lot of the role is not just saying, "Oh, I've come up with the answer. It's this". A lot of roles is listening and saying, "What is a customer looking for? What is your problem? The problem is not often technology as a customer, it is often a business problem like faster time market, more efficiency, my teams, reduced costs. These are the things that really drives in the customer's decision making and it's sort of helping through conversation. The same thing is with the product marketing team like for them, it's like the product can have 1000 features. What are the right ones to highlight? What's the right message around that, and how do we influence that? So, it connects to the developer and maybe reading the dots, but also with the CTO. So, a lot of is really often, although it is incredibly strong technical what I do, it's about understanding what's the right amount of content, at what level of depth that individual needs and also what is the real problem they're trying to solve because often these problems are technical, they're often business or organizational problems that we're trying to figure out, and the technology is an answer to that but you got to catch it in terms of the meet, meet with their understanding of what the problem is.