Transcript
David Grizzanti: My name is David Grizzanti. I’m going to be talking about a roadmap to a fulfilling career, pillars of staff-plus growth. I am currently a principal engineer and SRE at Google. Previously, I was a principal engineer at The New York Times. I worked alongside Lesley Cordero, in their platform engineering org. Prior to that, I spent about six-and-a-half years at Comcast, where I was a distinguished engineer. I’m going to focus a bit on my story today, what my growth looked like in our field. For the last 10, 15 years, I’ve been in the SRE, DevOps, platform engineering space, building internal systems at companies, not as big as Google, but always been in this behind-the-scenes space whatever it’s been called, as the industry has evolved.
Let’s Meet Alex
Let’s start with a story. Let me tell you about Alex. Alex is a staff engineer at a mid-sized tech company. They were promoted six months ago, after years of consistent delivery, mentoring teammates, and driving high impact projects. Alex has always been the go-to person from blocking gnarly tech problems. Leadership told them, you’re exactly what we need at the staff level. At first, it felt great. The title was validating. Calendar filled with strategy sessions, big projects, big expectations. Slowly the feeling started to change. Alex was doing fewer code reviews. They weren’t shipping features directly anymore.
Meetings ended with vague takeaways. No one was telling them what success looked like. In one-on-ones, they’d say, I think I’m doing the right thing, but deep down, they weren’t sure. The days felt full, but their impact felt fuzzy. Alex’s story isn’t rare. Many of us, I think, hit this point, especially after reaching staff, principal levels, where the rules change, feedback fades, and the growth that used to feel so clear suddenly gets murky. That’s what this talk is about. It’s the roadmap, or some of the ideas I wish I had as I was going through these various career ladder levels as I was working in my career.
Roadmap to a Fulfilling Career (Five Pillars to Staff-Plus Growth)
A few questions to kick us off. How many of you were on the IC track and maybe have felt like Alex at some point? Or you’re on the IC track and maybe you were Alex before he got promoted? If any of you out there have achieved this level you’re working towards, maybe you realize now that it’s not what you expected, or maybe it is, depending on the company. I want to walk through some of these scenarios and talk about maybe some of the trappings and the things to look out for. Because there’s many things that motivate people as you achieve these levels, maybe it’s money, status, learning, natural tendency to want to grow. I mentioned the past roles I’ve had. I’m coming up on about 20 years next year in the industry. I’ve had a fairly traditional career path. I studied computer science in college.
I’m fortunate, I think, that my career path also coincided with the rise of IC roles growing in industry, not necessarily needing to go into management to continue growing. I never officially went into management despite being pushed, like I’m sure many of you may have been that have been in your career long enough. Maybe some folks have jumped into management and then jumped back. That’s something I realized along this almost 20-year journey, is that moving up the ladder doesn’t always bring the satisfaction it appears. There’s always another level to chase, a better company to work for, and more money to be made. I’ve been thinking a lot about this recently. What makes a rewarding career? What will make me happy, you happy in a job without feeling like you constantly need to chase the next promotion? I’ve personally experienced ups and downs of that process, and I’ve seen a lot of folks go through that struggle and that’s, again, what I want to talk about.
These staff-plus levels come with a lot of ambiguity and invisible expectations, and fulfillment isn’t just about the title. What I think it should be about is positive influence in your company with your coworkers, your mentees, if you have them. Your purpose, and some form of sustainable growth, whether that’s climbing the career ladder maybe for you, but also being able to grow in your role, have more responsibility, learn without necessarily needing to change the job title you have or the type of job you’re doing. In this gnarly career ladder that exists today, we want to be able to understand the pitfalls of moving up the ladder. What are the trappings that come along with it? Learn to navigate ambiguity, and some of the new challenges that come along with it. Developing influence in your organization, whether it’s the existing one that you may have gotten promoted at, or if you’re joining a new company, or shaping the engineering culture for long-term impact at the company that you’re at or maybe a new one that you just joined.
Pillar 1: Climbing or Getting Stuck on The Career Ladder
What are some of the things we think about as we embark on this journey? The first thing I want to talk about is climbing or getting stuck on the career ladder. Maybe you’ve been at your company for a while, you’ve been in your role for a while, and you’re feeling stuck. One of the first things that at least I think helped me, or one of the things I advise folks to do is try to expand your scope. I think, in many ways, the people I’ve seen struggle fall into the trap of saying, the projects I’m working on don’t have enough impact, complain to their manager, I need more high impact projects. You may be in a situation where those projects don’t exist. Maybe your organization or the group that you’re in is stuck in a spot in the organization where they’re not getting enough attention.
One of the tricks that I’ve learned or one of the things I’ve tried to do is make connections outside of your team or your org that may seem less obvious. I think for me, maybe this was luck, maybe it was a little bit of me making friends when I was at Comcast, we had an open-source team that was close to me, organizationally, but I wasn’t on the team. I didn’t work with them very much. They did a lot of work with the open-source community, they did a lot of work with our internal teams to do inner sourcing. They were struggling because they didn’t have any engineers on the team. They were trying to hire one for a while, but couldn’t get any funding. They wanted to build this tool to capture metrics about how many people were reusing software libraries that were being built internally for inner source projects.
I saw that as an opportunity to like, I’m going to befriend them, loan them some 5%, 10% time on this project that they need help with, that is probably pretty trivial to me, but is complicated for them. Worked with them for a few months in spare time, built this tool that they needed. It was a huge win for them. They were able to get more funding for their own projects internally. It turned into a conference talk for me and one of the open-source program managers that we were able to go give at an open-source summit. This is just like one example of ways that I think are maybe more creative ideas to latch onto something that might exist within your org that seems less obvious, build these connections and expand your scope without it being something that your boss may hand you, or is within your direct line of responsibility.
The next thing is, choose problems tied to business outcomes. Easy to get trapped into working and building things that are just focused on outputs. I built this thing, look how great it is. I made X product go faster. That’s great, but how does this influence business or make your customers happy? You really need to look at making consistent, iterative progress on things that really drive measurable business outcomes, and communicate those as they’re being built. I think this is specific to platform engineering recently, but I saw a pretty good success with the platform as product movement that’s been taking hold in platform engineering, where traditionally a lot of internal product development or even just internal systems development wasn’t really seen as true product work. I think that’s changed in the last couple of years.
Product managers are getting hired for a lot of internal teams. We had a few product managers when I worked at the Times that focused just on our product. We really treated the developer platform that we were building like it was a product, like we had customers. In addition to driving business outcomes, driving customer impact I think is a big win regardless if your customers are maybe internal or external. It’s probably a little harder if you’re building something that external customers use that you don’t see every day. If you’re on one of these internal teams and you can see how it affects customers and really drive customer growth, I think it’s a good way of showing progress and focusing on valuable outcomes.
Next is delegation and scaling expertise. I think this may not be true in every organization and may not be said out loud, but I’ve seen in many cases folks get stuck and not be able to grow into the next position because they don’t have a succession plan. That doesn’t mean that you need to literally have the person sitting next to you right now ready, but, in many ways, being able to depend on other people in your organization, in your team that can essentially do your job or do the job that you are leaving behind so you have room to grow is really important. Whether that’s coaching senior or junior engineers, having a mentee, building up your mentorship network and sponsoring other people is important. There needs to be folks that you can depend on while you’re away. Hand stuff off if you’re too busy. Don’t hold all the cards yourself, really look to elevate other people. Scale your expertise by building out your internal network of people.
Then, just to shift the focus a little bit, and this may be a slightly different topic of people who want to get promoted. I’ve seen recently from talking to people, that people tend to always chase the promotion. I think management assumes or expects that everybody wants to get promoted, everybody wants to move to the next level. I think I’ve coached people recently or talked to people and asking them, is this actually what you want? Do you want to go from staff to principal or whatever the promotion is, because it’s not the same job. That largely depends on the organization you’re at, and how big it is.
If you like the day-to-day job you have now, or if you like writing code or writing code 50% of the time or whatever your split may be, getting a promotion means, yes, you make more money and you have more responsibility, but you may be doing a totally different job. You may be not on a single team anymore. You may have scope over a few teams, and you really need to think about what it is you actually want, and not what management wants out of you. They may just need somebody that is a high performer and fits and shows the signs of being capable. I think oftentimes you need to step back and think about if this is the right fit for you before you jump into it. I think this is the same for if you’re at your job or if you’re looking at roles at other companies. Maybe you see out there that another company has a higher position than you that may seem like the right fit.
I think what I’ve often advised people to do if they’re looking for those sorts of roles is try to get to know someone who works at the company before you take the leap. I’ve seen people jump to bigger tech companies in the past, and six months later boomerang back to the job that I was at before or maybe a slightly different position, but come back because they realize that what they thought the job was isn’t in reality what it turned out to be. Not because the company may not be a good fit but just that that position at that company is not the same as what it might be at the company they’re at now.
Each company treats these roles slightly differently. Your scope is different. Your expectations are different. If it is the right time for you, what are some ways that you can seek out this opportunity when you are wanting it for the right reasons and know what you’re getting into? Like I said, even on the flip side when you are thinking about it, I think not necessarily a networking from a helping you get the job perspective, but I think the networking both inside and outside companies is very valuable. I mentioned it before from expanding your scope, knowing people that aren’t in your day-to-day reporting chain.
Maybe there’s opportunities within the company that are outside of your management chain so that networking helps. Also just getting to know people that are across different companies before you make the leap usually helps. I think cold applications are very difficult, so having a network connection when you’re applying really helps, I think just from somebody being able to vouch for you but also giving you a leg up when you’re applying.
Pillar 2: Navigating Ambiguity and Scope Change
The next thing is navigating ambiguity and scope change. I want to break this down into two pieces. First, I’ll talk about change of job and scope as you move up the ladder at maybe your current company. The next thing was changing job literally to a new company, especially at a high senior level, and how to navigate those challenges. How do you get started from scratch? The first thing is this quote, “Your previously learned skills or coping strategies suddenly seem inadequate to meet new demands”. This is typically a common pattern seen in children, and it’s referred to as the performance cliff.
The link at the bottom is actually from the real source. I read a really good blog post by Katie Sylor-Miller recently about the staff-plus performance cliff. This concept is again associated with children, whereas children who typically do really well, gifted children academically in grades K-12 at some point suddenly find themselves unable to cope with the demands of college where self-direction and time management and study skills are really important. They didn’t necessarily learn these in order to succeed in school upfront to that point, and are now critical to their success. The same mechanisms are at play when you move to this staff-plus role, team lead. You hit this performance cliff where you’ve been cruising up the IC ladder up until now, growing skills that are scoped to your role that are team centered around technical execution. Maybe you’re increasing larger scope in projects.
Then you get to a point where you’re responsible for not one, but maybe multiple projects, and you don’t have the technical depth necessarily on all of them, but you’re affected to juggle and keep all that context. Suddenly the main thing you’ve been focusing on all the time, maybe writing code, doing architecture, isn’t really your job anymore. That just goes to the general statement, “What got you here won’t get you there”. I think I’ve often seen in many cases, people assume the skills that get them the promotion are what will continue helping them grow, but really your job function changes as you move up this ladder. You really need to think about, before you leap there, what are the demands that I’m going to face when I get there, or at least be ready to change or adapt once that happens.
This performance cliff just lets us know, in general, that staff-plus, principal work is very ambiguous, has slow feedback, and is often invisible. You’re expected to drive business outcomes, but you don’t necessarily have control of those business outcomes yourself. You’re depending on other teams or individuals to do the work to accomplish those, much like a manager would, but in this case, you don’t have any people reporting to you to do that work. There’s a lot of influencing without authority that goes into this work. Success is self-directed. No one’s really telling you what to do next. You have to see 3, 6 months, a year down the road, and figure out where it makes sense to focus and where to push on your influence where it’s applicable.
Really think about reframing and setting new expectations on how you measure success. Think less about universally quantifiable metrics. It’s less about, I wrote this much code, or I closed as many PRs, or closed as many bugs, or shipped as many features. It’s really adopting a framework for recognizing impact and progress within this new set of responsibilities and longer-term outcomes. For myself, at least, I think about impact as, again, what business outcomes am I driving and who am I working with to drive those? Google’s big on OKRs, if people are familiar with that. I think over my career, companies have used different sets of these measurable goals. I think the OKR framework gives you a good way to structure what you’re building. It stands for outcomes and key results. The idea is that the key results always need to be measurable. For you, in this case, it’s less about measuring exactly what you’re doing and measuring the impact you’re having or the business outcomes that you’re driving.
Some survival strategies, I think, along this line is, learn to ask better questions. How does influence work here? What isn’t being said? Who do I need to befriend? Who are the key people that are really driving the teams? Or, who are the key influencers here? Who do people listen to? What tech leads are really responsible for the key decisions and that I need to work closely with? Find early wins that make your impact visible and tie into organization goals. Really try to befriend the other folks in these positions, so avoiding isolation.
That can be hard, I think, if you’re at a company that’s small and doesn’t have a lot of people at this level. If you’re at a mid-sized company, or even a large company, you can find the mini-pockets of people that are in a similar role as you or are facing similar challenges. When I was at the Times, we had about eight principal engineers, so it was a good size to stay connected with people and see what patterns they were seeing, what they were struggling with. Google’s obviously a lot bigger, but even within SRE, it’s a good set of people to stay connected to and learn what kind of challenges they’re having. At least have some folks that are facing similar challenges with you that you can lean on.
Next, I want to start shifting to talking about a new job at a new company. Let’s say you get one of these promotions, but you change to a new job. I think I’ve done this twice in the last 5 years. I think it’s definitely a struggle when you’re used to being at a company for a long time and you come in and a lot of people have been there a long time, have all this context that you don’t have, and you’re expected to operate at this very high level very quickly. Not only do you not know anyone, but you don’t know any of the tech and you don’t really know how the organization functions. Organization dynamics vary pretty wildly from what I’ve seen.
My advice is to observe and then engage. I’ll talk a little bit about frameworks that I’ve used in the past to try to help with that, ways to observe and figure out how best to focus your first 30, 60, 90 days. I think the first thing is build context. You’ve been hired because of your industry experience, tenure, or expertise. Context matters, but it’s always different depending on the company. I think the best thing to do is meet people, ask lots of questions, and listen. I think the last two jobs I started, most of the time in my first 30 days, I spent in one-on-ones, just trying to get context from people and learn as much as possible. Mine for information, understand what’s working well and what’s not.
Next is build relationships through those one-on-ones. You don’t necessarily have to maintain this constant pace of meetings as you’ve been there longer. You can’t lead without good relationships. Start investing in them early, and build them across the business and take time to learn and meet about other teams. Set expectations. You can’t make any drastic changes in your first 30 days, regardless of where you are.
Let’s start talking about what you value and what you bring to the table. One of the things I’ve seen work pretty well is write a ‘how I work’ doc, and share it and get feedback. You’re going to want to engage with people on how you expect people to engage with you. Whether that’s like, I really like synchronous meetings, I really hate them. Here are my working hours, especially if you work at a global company. I like writing my thoughts down in Google Docs. I like chatting, those sorts of things. I think I’ve found everybody works slightly differently. This can be a good way of almost like a user’s manual. I think setting up office hours is another good thing in addition to these one-on-ones. I think some folks could be intimidated by, there’s a new person coming at this high level. I don’t want to schedule a meeting with them or bug them because they’re busy. I think setting up office hours, whether the calendaring software you use supports that or not, give them a way to reach out to you that’s less intimidating.
Then, set up a 30, 60, 90-day plan. Some of this may seem super obvious, but I think when I started at a new job, me and my direct supervisor having this framework really helped to say, the first 30 days, I’m just going to spend time learning. I’m going to meet people. I’m going to read as much documentation as I can, play around with whatever tools, let me learn stuff. Maybe go on call with a team, if you’re in that role, to learn what the teams are struggling with. Maybe in the 60-day mark, you want to make a small impact. I think at the 90-day, at least for me, it’s good to set a pretty good target. Like, here’s this maybe overly ambitious thing I want to do.
At Google, every new hire gets a starter project. That can be as minimal as, we want you to write this small feature or build this small project that we know doesn’t have any business outcomes or high stakes tied to it, but it’ll give you something to focus on and maybe it’ll be great. Or depending at the higher level, it’s something like, I want you to have a strategy around X. Maybe that strategy is already partially formed, but it’ll give you a way to focus your energy on, my goal is to write this strategy document. That means I need to figure out who’s involved in this area, who understands the moving parts of this, and then at least started collecting my thoughts. It gives you, again, just something good to focus on.
Pillar 3: Growing your Influence
Next thing to talk about is growing your influence. A couple areas here to talk about. I think as you move up, strategy is something that becomes more important, but not just strategy, just maybe strategic thinking. I’m hammering this in, but pick problems tied to company and org goals, driving business outcomes is really important. When you’re writing these strategy documents, I think tying any strategy you write, not just a technical vision, but how is the tech you’re picking, how is the technology you’re working with solving problems for the company? Frame any technical decisions in business terms.
Next thing is communication. I like this make ideas contagious thing, but I think a more concrete example that I’ve used and seen work well in the past is, if you have an idea that you’re trying to get buy-in for, instead of writing a 20-page document for it and sending it to a bunch of people and saying, can you read this and tell me, can you approve this document? I like the idea of talking to people one-on-one about this idea until the point where when you need the decision to be made, you have a feel for everybody feels how everybody is going to accept or not. Using the feedback they give you along the way to make it better so that when you eventually do need a decision, it’s not a fight. Everybody is feeding into this idea that you have, maybe tweaking it a little bit.
At the point when you need to send it out to everybody, it’s not as controversial. The last thing is systems thinking, systems awareness. Spot the patterns, not just the bugs. Michelle talked about systems thinking. I’m also a big fan of that. The idea that strategies are made more robust and effective by considering the interconnectedness of all aspects of organizations and systems. You need to take a holistic view of problems. Better decision-making and anticipation of unintended consequences comes out of this. Learn to see how the organization works, how it moves. Who are the important people? How do decisions really get made, both from the organizational side, but also from the technical side as well.
I wanted to draw a circle for this, but I couldn’t figure out how to make it work very well, but this idea of this influence writing flywheel. I think this like, gathering your thoughts, write them down, shipping them, talking to people to earn trust. I think that will get you pulled into more critical work. This idea is that if you can write your thoughts down clearly, get them shipped, get buy-in, you earn people’s trust, earn credibility, the more you’ll get pulled in, the more you’ll be seen as someone who can be relied on to gather the right people across the organization, gather the ideas that they have, push on solutions. Maybe you’re the person drawing all those people together, drawing the narrative and pushing it out there, even though you didn’t do all the work, you’re the one driving the people to come together and earn their trust and get the work done. Make your work understood and approachable.
I think influence grows when your decisions and rationale are understood and echoed by others. This goes back to the storytelling and buy-in gathering. Documenting decisions and storytelling matter more than ever. I think that telling that story, crafting that narrative is really important. Like, why are we doing this? What are the business outcomes? How does this relate back to something that the company needs, the user needs? Along this decision-making driving, even if you’re doing a great job telling the story, there’s always this struggle with building consensus and getting approval. I think I’ve seen 10 or 15 different ways of like, how do we approve documents at this company? How do we do decision-making, whether it’s like a decision-making framework? If you have to pick a new software language or a new library, who is going to approve this direction we’re going of this strategy document has 10 approvers on it. We’re waiting for this one person.
One of the frameworks that I used at my last job that our VP recommended is this thing called DACI. It’s like a riff on RACI. There’s the acronym, it’s, do you have a driver, an approver, or are consulted and informed? It’s the idea that instead of having five approvers, you have one approver. The driver is the person driving the decision, maybe they’re the writer of the document or the person who wants the decision. You appoint one person who is accountable to be the approver of the document. That person is responsible for talking to all the people who are consulted, getting their feedback, making sure the feedback is heard. Then, once the decision is made, a bunch of people are informed. This pushes on the fact that when you have five approvers of a decision or five approvers of a document, it’s easy for two of the five of them to not pay as much attention, or be like, yes, this person’s really the approver, I’ll approve it once they approve it. This is a good framework if you’re struggling with having too many people when approving things.
Pillar 4: Shaping Engineering Culture
Next is shaping engineering culture. I think about when I started at a new job, I was thinking about ways to figure out how this organization works. I think about it as a mix of like an anthropologist and an archaeologist. Organizations are studying cultures. Anthropology is the study of human beings and their ancestors over time and space. Figuring out, what artifacts did they leave behind? How do I find my way through this organization? There’s a talk that I was originally pointed to, by a guy named Mike McGarr from QCon in 2019, who talked about discovering organizational culture through artifacts. I wanted to just point out a few things that he mentioned that were really interesting, which is, when you’re trying to figure out what is an organizational culture, what are you looking at? How do you discover that? What key points are mentioned? He had these axes here, which is about behaviors.
On one hand, you have rewarded behaviors, one hand you have punished behaviors, but in between you have these accepted and expected behaviors. Understanding where behaviors fall on the spectrum gives you a good idea of what the culture is like for how things are tolerated at a company. Expected behaviors are like, what things should I be doing to maybe get a promotion or get rewarded? Then there’s things that even though someone expects you to do something, if you don’t do it and you don’t get punished, those are accepted things. The example he gave is you’re supposed to come to work every day at 9 a.m., that’s the expectation, but most people show up at 10:00, and no one’s getting punished for it, that’s an accepted behavior. As opposed to violating some security policy, which is, you’re punished and you get fired. That was one example.
Then, that culminated in what makes up a culture of your company? His idea is it’s a combination of tools, processes, behavior, values, and ultimately people who observe these different things. I think this goes back to what I want to key off of is, when you’re trying to shape an engineering culture at a company, you really need to understand not only the behaviors and what makes up the culture, but how are decisions being made? Who has the authority to make those decisions? Which departments have influence? How is information communicated? If you can understand those four things, I think you can figure out a good way of, how do I shape this in a way that not just benefits me, but how do I work in this environment once I understand all these things? Understand the culture.
Then, figure out how to set your own norms. How you review code, how you treat feedback, how you get buy-in, build consensus, and respond to conflict sets the tone, not only for your peers, but also for maybe other engineers that are working with you and may respect you for the tone that you set. I think in that case, culture is very important. I think a leader, whether it’s an IC or an engineering leader who has management duties can really set a tone and make a huge difference in an organization. Culture is a multiplier, so again, be the example. I think once you get to this staff-plus, depending on how big the company is, is definitely a leverage point.
Use your influence to amplify values like psychological safety and inclusion. Make sure you’re setting a good example in these areas. Be approachable. I think, oftentimes people don’t realize if they’re giving off a bad tone. In the past when I’ve started at new companies, I’ve gotten feedback from people that say like, “A lot of the other ex-engineers, I don’t feel comfortable talking to them, you’re really approachable. I feel safe not complaining to you but talking to you”. I think that idea of giving off a vibe that you’re accepting and open to feedback, for folks to let you know what they’re struggling with is a good way of building your network but also amplifying other voices and scaling your impact.
Pillar 5: Design Your Own Roadmap
Then the last thing is designing your own roadmap. How do you take all these things that we talked about and really think about, are you ready, do you want to move to the next level? Do you want to keep climbing the ladder, grow in your own role? How do we think about that? I think the first thing is just understanding what motivates you and what keeps you happy. A new title may feel rewarding but it changes your role in your daily life. Especially going to a new company, totally new sets of challenges, think about all the work that you have to do to build up your network again. Not that that’s a bad thing but it’s just something that you have to get used to if you bounce around to companies a lot, especially as you move up the ladder. I think understanding what motivates you is important. I think it’s easy to get trapped in the hecticness of jobs and not really realizing that when you change, you’re like, “I actually really like writing code 50% of my day. Now I don’t get to do that anymore”.
Then the other thing is, is there room to grow in your current role without a promotion? I realize, growing without a promotion, maybe that’s like an oxymoron because you’re doing more work but not getting paid more. I think companies still have ways of rewarding people that aren’t necessarily going to the next level. Maybe you take on more responsibility, maybe you take a different role in the company that’s not necessarily a title change. I think either way, it’s just understanding what you want and making sure you’re doing it for the right reasons.
I had a physics professor in college who inspired this picture. Whenever we would need to study for a physics test, he would always tell us to get a hot cup of cocoa and go home and study physics. I asked Gemini to create a person drinking cocoa studying. That’s what they came up with. I think the idea of understanding what makes you happy is just invite reflection. Like, which of these areas resonate with you right now? Which one needs your attention in the next 6 months? Are you looking to shape culture? Are you looking to grow your influence? Are you looking to grow in your role? What are the things that you need or want to think about?
Maybe start writing those down, reflect on them over some cocoa, or whatever hot beverage you like. In a similar point, what are your goals in the next 6 months, 1 year, 3 years, 5 years? Would you rather grow your influence outside of your job, like start a blog, start writing more, doing conference talks, those sorts of things? Or would you rather put your energy into being great at your current job so you can get promoted, or building your network so maybe you can look outside of your current company? Again, what motivates and keeps you happy now? Are those motivators the same? Are true if you continue to climb the ladder?
Talk to engineers maybe a level above you and at different companies at events like this to see what their day-to-day is like. I’ve definitely found that across the three companies I’ve worked at, even though I have a similar title, my role is wildly different at the three companies, both because the companies are different sizes, but also because they’re at different stages of their growth. Google basically wrote everything themselves, doesn’t use a lot of open source or vendor software, whereas Comcast and the Times did. I feel like the context you have and the industry experience you have can help, but how it benefits you is very different at different companies. A staff or principal engineer at one company is likely very different than at your current company. It depends on the size, the industry, your org structure. I think taking all these things into account, really think about what growth looks like and what you’re thinking about next.
Takeaways
I just want to put out a few takeaways. Know what you want, what makes you happy. Don’t assume a title is what will drive that. Hone the new skills you need to take on your role, whether that’s at your current company or are looking to grow to a new one. Work to shape the culture. Thinking about, again, how culture moves, what makes up the culture at your company. Understanding that before you dive into shaping it. Grow your influence, working on some of the things that we mentioned. Then, lastly, sit down and design your own roadmap. I have two references at the bottom for the two blogs I mentioned.
Questions and Answers
Participant 1: Whenever you change and you assume the other role, let’s assume that you didn’t think through how this is going to change how you are effectively participating. Then you’re there, and now you need to understand how to build your circle of influence. Do you do any kind of strategy like that culture assessment in the organization or mapping levels of influence to know who to contact with and straighten your relationships with, given your role, or something like that? When you’re doing the assessment on the strategy of the company, if your company has two high-level goals across the entire organization, but technically speaking, there is not much of a relationship, how do you connect the dots? How do you straighten your path back to these goals?
David Grizzanti: I didn’t realize many of these things like, my job was going to change, until I was in the position where it changed. I think that happens to a lot of people. I think the way I started, or at least when these situations happen is I talked to other people that may be in a similar position, maybe like in a slightly different team than me. Like, how does your team work? How are you influencing things? How are you pushing change? I think a lot of people before they move up, again, don’t necessarily understand what the job function is. They see people doing it, but it’s hard to tell what their day-to-day is like.
That mapping exercise is different depending on how long you’ve been at the company. If you’ve been there 10 years, you probably understand the culture already pretty well. Maybe you don’t understand how business outcomes are measured because you haven’t been in the room where the leaders have been doing that, but all of a sudden, you’re more responsible for that. I think talking to engineering directors is another good way of doing that because they’re usually in the business of having to measure these things all the time, whether it’s yours or other folks that you might know. Just figuring out how they quantify their work and see their impact, because they’re also not in a role where they are necessarily doing a lot of hands-on keyboard work a lot.
Participant 1: How do you align with business goals if your work is a little bit too technical, or you’re leading too technical?
David Grizzanti: I think if you are working on a system that has users and one of the business outcomes is increase adoption of this tool, or increase CSAT scores on the tool that we’re working on. CSAT is a customer satisfaction survey. I think partnering with, if you have product management or not, to thinking about, what types of things are making customers happy with our tool, and how does that translate into technical things? What features can I build or what features can I convince the team to build that will make customers happier or drive more adoption?
If you have metrics already for your tool that you’re seeing how many users we’re getting per month. I’ve even found value in reading customer feedback as it comes in, whether it’s through bugs or through feature requests, just paying more attention to that stuff and seeing what things people are complaining about and what things people want. I think, traditionally when you’re a junior engineer, you’re getting started, you’re just responding to the needs of the business, like someone told you to work on this feature, you don’t really have a say in it. I think as you grow, you can have more influence there, at least paying attention to the signals and trying to influence the path for people.
Participant 2: What is your approach for conflict resolution, especially like in my career, sometimes on technical things, people have different opinions and that gives a lot of conflict. They are editorial opinions, like the company can go different ways, but that creates a lot of conflict and tension.
David Grizzanti: I think if you were to ask an engineering director, for instance, but like, they probably don’t care what the technology choice is, they want to make the customers happy, or, again, drive business outcomes. I think it’s framing the technical decision in ways that are going to drive the business outcome and not pushing the technical decision under the rug. Not that it doesn’t matter, but I think if you’re struggling to say, which tool do we pick to get this thing done? I’ve seen frameworks in the past to just weigh the pros and cons of all of them, and say, we have to pick a new JavaScript framework, here’s the four of them that we’re going to pick.
Let’s use this framework to weigh out all the pros and cons and take out the names of them, and look at all of them on a spreadsheet and say, ok, this one won, this is the one we’re picking. In the end, there are factors there like supportability and maintainability, how many people understand this language, how many don’t. Everyone’s always going to have opinions about what the technology choice is, but there’s usually a way to make a pros and cons list and pick one.
Then, at the level that we’re talking about, unless you’re operating at a super-technical level and it’s going to affect you, which one will you pick, your goal should be to drive the business forward and have them get more users or make more money, or whatever it is. I think driving clarity on how the technology decisions are made should be fast. Try to remove the blockers and tell people that it’s not personal, not that it doesn’t matter what we’re picking, but let’s pick the best one for the job and move on. There is a QCon 2023, one of my colleagues from Comcast gave a talk and he mentioned trying to fight with making a technology decision. There was a staff-plus track at QCon in New York, if you’re looking for the framework and look up the talk, his name is John Riviello.
Participant 3: I had a question about culture. You talked about creating culture. One of the things that I, in my experience, have struggled with is motivating people to take on more ownership or take on a bigger role. Do you have any advice for that?
David Grizzanti: I haven’t struggled with this because I haven’t been a manager, but when I was at the Times, a peer of mine was struggling with this because as I was moving out of one position into another, he was saying like, I really need someone to backfill for you, do you know anyone or how can we motivate people? It’s definitely difficult. I think I’ve tried to find people either through one-on-ones and getting to know people, who has the personality and the skills that would match. They’re not too pessimistic or have the right motivations, and try to coach them to see if it’s the right fit for them.
Don’t push people into the promotion if they don’t want it, like I said before, because I think that’s a trap that we sometimes fall into. Look for people who are credible and are willing to take on ownership. I realize that that’s hard, because I think if it were there, you would naturally see it and they would just already be doing it. I think in some cases, you just sometimes have teams where there isn’t somebody who’s a natural fit, and maybe you need to bring in somebody from another team or from another org to fill the gap.
Participant 4: As you try to grow your reputation through impact and trust by relationships or working on larger projects, how do you effectively handle failure at some point during these projects? How does that impact your trust?
David Grizzanti: I think you need to be comfortable with the failure and comfortable taking risks. One of the things that someone said to me in my last job was that he found that oftentimes people would be unwilling to put stuff in writing or try something if they didn’t think it was going to work 100%. We were talking about a project I was working on, and I was unsure if something was going to work, but I was like, I think we should try this and let’s work on it. Even if it fails, then it fails, and we’ll move on. Which is interesting to me, because I feel like our culture is very built around fail fast, like try things, and if they fail, it’s fine.
I think in reality, a lot of people are not comfortable with that. I don’t know if it’s like a personal not comfortable with failure, or people still see people putting out big decisions and then failing as a problem. I do think people respond, if you push forward with something and you’re confident, not necessarily that it’s going to work, but you’re confident that the decision is sound and even if it fails we can move on. I haven’t had any issue with losing credibility in those cases. I haven’t lost faith in a person because they tried something and it failed. I think you just have to be comfortable with taking the failure and moving on. Making sure you’re calling out scary areas to management in the beginning, so if it does fail, they’re aware of it, and not waiting too long to back out of a bad decision. Just make sure you’re iterating and moving on.
See more presentations with transcripts
