62 minutes | Nov 17th 2020

One Year as a Google Cloud Engineer Part 2 with John White

Play
Like
Play Next
Mark Played
Welcome to episode 99 of the Nerd Journey Podcast [@NerdJourney]! We’re John White (@vJourneyman) and Nick Korte (@NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. Today’s episode is part 2 of a discussion we had where Nick asks John to reflect on his first year as a Google Cloud Engineer. Original Recording Date: 11-01-2020 Topics – Google Cloud 1-Year Check-in, Part 2 1:24 – Career in the Cloud This is part 2 of John’s 1-year check-in at Google Cloud. Go back and listen to part 1 if you missed it to get an idea of what John has learned during that time. What are the different advancement levels within the Customer Engineering role at Google Cloud? At Google there are levels. Usually entry level is L3. The levels go up to L7 as individual contributor roles. John thinks the promotion from L4 to L5 is the last one a manager can have sole discretion on, but there is heavier scrutiny for the higher level promotions. This is mostly speculative as John has not been through a promotion cycle just yet. Technical background and complexity of work you are capable of doing consistently continue to raise as one moves up through the levels. There are no specific descriptions for L3 through L7 except Customer Engineer. John mentioned a new role called Enterprise Cloud Architect (a role closely aligned with the Customer Engineer role), and most of those folks are L6 / L7. The job description is different from Customer Engineer, and the engagement model is also different. They just happen to report to the same managers as Customer Engineers. Keep in mind there are options at large companies to progress as an individual contributor which may not be there at smaller companies. It doesn’t have to be Pre-Sales either. What is John’s take on being tied more to cloud services than before? At VMware before John left there were a number of subscription services. Over time, that seems to be happening more and more. One of his favorite products was Wavefront (now named Tanzu Observability by Wavefront). It is a high volume time-series database that can really only be done in the cloud. When you buy something as a service (whether in your own datacenter or elsewhere), the service is owned and operated by a different party but provided to you for consumption. There is this bleeding edge perception of cloud services, but John’s thinking on it has evolved. Cloud services are not inherently bleeding edge / cutting edge. Listen to the examples he gives of services that are useful but aren’t super exciting (O365 / hosted e-mail). Some of the services Google has are a bit earlier in the hype cycle but may require more knowledge to handle. VMware is in this business as well (i.e. services around Kubernetes). Another example would be machine learning. The more these services become commodity, they become more like infrastructure and a bit less glamorous. Cloud companies of all types are focusing on products a little earlier in the maturity cycle. 13:07 – Many people go work for a vendor because they are passionate about the technology. Has John achieved a passion for the technology as a result of his experience after not having used much of the technology coming into Google Cloud? Before working for VMware, John was excited about bringing the technology he wished he could have used as a customer to his customers. Coming into Google Cloud, things like key differentiators of the services offered were not as clear to him. These were things he asked about in the interview process. Once on the inside, John came to better understand. Things like artificial intelligence and machine learning were somewhat "hand wavy" and felt like buzz words. Now John understands what machine learning is, what infrastructure needs to be in place for it to work, why we would want to use machine learning, etc. It was similar for data analytics, data pipelines, etc. These are all valuable when you have the right problem to solve, but one must understand the problem well. John mentioned streaming data analytics and how Wavefront from VMware helps solve this. John and his peers are able to leverage lab environments to learn about the products (how he learns best). Listen to his story about using Google products to create a COVID-19 data tracker. 21:53 – Cultural Changes in the Move to Google The in-office culture required some adjusting, and John came to value it greatly. While he does not miss the commute, he does miss seeing colleagues in person, picking brains, going to lunch with extended team members, etc. When you are new to an organization, this is such a valuable experience. John isn’t sure how he did it at VMware without this. John was able to shadow people and listen in on calls to help him learn and ramp. Over time you start to exercise the right muscles and get better and better. The Sales process was different. It was brand new to John to be assisting a Salesperson in efforts to drive business and to follow through afterward to help drive consumption. If customers do not use a service, everyone is unhappy at the end of a subscription term. There is an element of customer success to the role. Finding additional use cases within an organization for a technology already in use helps with the consumption element and provides more value to the customer. This seems to allow for flexing a different kind of muscle. Many of John’s customers are greenfield customers (i.e. no significant spend with Google Cloud). Only recently has he been involved in the monitoring of consumption. Being involved in hiring interviews is not something he did while at VMware. At Google Cloud, none of the interviewing is done by hiring managers as a general rule. All initial screening and interviews to qualify to get hired at Google is not an area in which hiring managers are involved. Managers get involved later in the process, however. In these initial screenings, interviewers are looking for things like role-related knowledge, general cognitive ability, leadership, and Googlyness. In the role-related knowledge interviews, it is usually two people (front line Customer Engineers) interviewing a prospective Customer Engineer. In cognitive ability interviews, a front-line Customer Engineer is trying to understand a candidate’s thinking and problem solving capabilities. Generally leadership and Googlyness screenings are done by a front-line employee. That’s 4 individual contributors which get involved in the interview process for an incoming Customer Engineer. John says there was a great deal of training internally on this which finally helped him understand what the documents he had read from careers.google.com had indicated (seemed a bit opaque at first). John has coached a number of people through this process. To be clear, John has participated in interviewing candidates who were going only for a Customer Engineer role or the Cloud Architect role (both report to his management chain). If you are looking to change jobs (even if not specifically targeting Google), look at the careers.google.com "How We Hire" section. It matches a number of things we have previously discussed on the show and describes the entire hiring process. Being a part of the interview process and coaching others through it has made John much more equipped to go through hiring processes in the future. The performance review process is very different than he had in previous roles. John does not remember ever preparing specific material for reviews at other companies. He did receive performance feedback from previous managers, but this is very different than Google. Google has a twice yearly formal review process which requires deep introspection. This is something you want to be preparing for on a weekly basis along the way. Asking for peer reviews was extremely helpful. The first time John had to do this, it was extremely intimidating. He was not sure what they were asking him for. Despite his manager explaining it clearly, John still had challenges with the process the first time through. At that point he had only successfully gone through training. It was challenging to describe an impact and accomplishments. This process is not routine (at least for John) an may require he go through it a few more times to get to that point. John has a weekly task on Fridays reminding him to pull information out of meetings during the previous week which would be useful for performance review purposes as well as a reminder of exactly what he needs to target. John was delivered a performance review yearly before VMware but little more than that. Nick shares his experiences with performance reviews (nothing compared to what John has been through at Google). John mentioned the official feedback after everything he prepared came at a later time with categories and ratings. This seemed to be extremely burdensome on management with the need to provide feedback and justifications for ratings to employees. In order to get promoted, John recommends preparing a promotion package which shows you are exceeding the metrics for success in multiple areas. At Google, the feedback ratings are calibrated and standardized across the entire organization (regardless of role, etc.). 41:50 – John’s Professional Development The job description at each level is very clear. On a weekly basis you want to describe how you are meeting or exceeding those job descriptions (i.e. strongly outperforming a specific metric, etc.). Recording things once per week was definitely not something John had previously done but is absolutely the best way to keep your accomplishments top of mind. This is near impossible to do well just before review time. John has learned to document the things he is doing even better now (account plans, customer overviews, etc.). In the past these types of documents had an ever changing format. John chose to create a narrative of his customers with engagement history. Listen to how he describes it and what gets tracked. When reflecting back on it, John isn’t sure why he didn’t do this before. This type of document is also helpful if an account changes hands to another team. Staying organized like this has done wonders to help John keep up with tasks. John has created a documentation web for each customer that he can share with extended team members to get them up to speed easily. Does John see himself moving to a different role within Google at some point? It’s too early to tell. He feels he needs to think of himself as an "Exceeds Expectations" person in a number of areas before considering a move. He has potential to be useful in a management position if company growth would allow for it, but again, he wants to first further sharpen his experience and level of excellence as a Customer Engineer (i.e. history of being a strong performer, influence on specific products, etc.). No specific product / product line has jumped out as an area in which he would like to at some point specialize. But, you never know. See also our Specialist vs. Generalist discussion from episode 26. Is the move to Google what John thought it would be? He didn’t really know what to expect. It is normally traumatic to move from a familiar place to something new. You’re walking away from all of the contacts, internal knowledge, and reflexes for navigating an organization. It has taken a year for John to understand enough about the organization to be effective. It had been long enough since joining VMware that he didn’t remember how traumatic it was to have zero institutional knowledge. John created a document to help others navigate the organization (getting a customer support that is in proof of concept, for example). 53:42 – Closing Remarks John doesn’t want every interaction with his previous teammates to hinge upon how great Google is. John tries to keep in touch with folks every 6 months or so, but it is not officially tracked in a document. Keeping in touch with others can be a challenge when entering a whole new world (new company). John suggests we all get organized early on and begin writing the narrative for your review process. Make it a habit as John wishes he had. Begin tracking your work against requirements in the job description for your role on a consistent basis. Even if there is no formal review process, it would be extremely powerful to give your manager a packet of information you have written. The weekly reflection process may seem like a whip, but get in the habit. Nick wishes he did it more as well. If this is not something you are doing, don’t complain when you do not accomplish what you want. This is something you can control relevant to your performance. If you do it and get nowhere, you have room to complain. If you chose not to do something to make it easier for your manager to help you get that next raise or promotion, it’s on you. If you do in fact get nowhere, there is still a benefit! This process has written / improved your resume for you. Getting hired is like a very structured performance review process. Episode 100 is coming soon! We should do something special for it.
Play
Like
Play Next
Mark Played