Building scalable hiring processes & systems promoting operational excellence w/ Stephen Poletto #184

Even just very simple things like a candidate's been in back-to-back interviews, you hot-bond, hey how are you? Do you need to find them in a break? So we would train interviewers on some of those tactics, right? Hey at the beginning of the call, set the agenda. We're going to spend this amount of time on these topics. We're going to spend this amount of time to give you space to ask questions of me. Now the candidate knows what to expect. They're put at ease. It's sort of simple stuff, but it really colors the way that people feel about the interview itself.

So what do they have about the company coming out of it? Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC, and I'm Patrick Gallagher, and we're your host. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry.

In this episode, Steven Poletto, CTO at Lattice joins us, and we talk about strategies to build scalable hiring processes, especially when your team is growing fast. And then we reflect on different systems and approaches to promote operational excellence.

Our conversation covers topics like building out a systematic and repeatable hiring process. We talk about defining the employee value proposition. And then we get into specific experiences throughout the hiring process that make a huge difference when it comes to closing candidates.

Then we get into training your team on how to hire plus how certain rituals influence organizational psychology frameworks for adding incentives within your engineering org that improve organizational impact and how to avoid bad incentives. Let me introduce you to Steven as CTO at Lattice. Steven leads the company's product development where he scaled the engineering team from 20 to 150 team members.

He began his career at Apple before spending eight years building and growing technical teams at Dropbox. Steven said the opportunity to incubate new products such as Dropbox Carousel and Dropbox Paper. It has also worked on at scale products such as the Dropbox Mobile app and Dropbox's platform infrastructure. Enjoy our conversation with Steven Poletto. Welcome Steven. It's a Wednesday. We're hanging out. How are you doing?

Doing well. Thanks for having me on. We were talking about the outer sunset earlier and today is a gloriously sunny day out here. So I'm having a great day. As an aspirational outer sunset resident. This is why I want to move there. Thanks for helping bring that energy to our conversation today. Of course. I'm excited to get into it with you.

To set some context for folks listening in, many people have probably been navigating what you and I have labeled as a challenging or difficult organizational psychology with a lot of folks coming off of this post reduction in force, reorg massive market shift challenge. And then I think a lot of folks in our community have labeled this as like, you know, low morale. Like, how do we help get our team out of this like a low morale state?

So that's kind of one side. And the other part of this is folks want to go from this low morale state. So how do we get back to working? How do we get back to execution and get it things done? And I think your perspective is interesting. I think one, you joined Latest early on and navigated like an incredible hyper growth moment.

And also to share sort of this focus on operational excellence and been thinking a lot about some of the key questions. And so we wanted to kind of look at two sides of your experience here. Some of the insights, observations and lessons from sort of this hyper growth and operational excellence phase so that folks can figure out how to navigate and do things a little bit better.

So I think to begin, Steven, we'd love to take it back to the beginning from your time at Latest. Like, what was it like when you first joined? Like, what was the environment and what was sort of the goal when you first got hired? What were you working on?

Yeah, good summary. It's been a roller coaster, reflecting on the last four and a half years. But if I go back to March 2020, which is when I joined, you know, first of all, it was a very strange time to start at a new company because I joined right during the pivot to shelter in place.

I fortunately had the opportunity to meet the executive team during my interview process in person before we made that pivot to remote. But that was step one was like the whole company learning along with the rest of the world. How to shift into a fully remote orientation. When I joined, there were 20 folks in the engineering team. The company was about 140 people and even just from looking at that ratio, like 20 to 140, you can tell the software teams were a little bit behind.

So, it was clear product market fit. We were selling and supporting the product really well, doubling to tripling revenue year over year. And we had three successful products in market, the performance reviews product, engagement surveys and goals slash OKRs. And because the engineering team was so lean supporting those three parallel products, the company was constantly being forced to make really hard tradeoffs.

So for example, there was one pod of engineers, which I think had five or six engineers supporting both the reviews and the engagement products. It was called the R&E pod, the reviews engagement pod. That was just really difficult given the mounting demand from customers, all the features that customers wanted to see Jack, the CEO and founder had this bold breadth oriented vision saw the consolidation trend on the horizon and wanted to keep expanding the product suite.

So he wanted to build out career development planning, compensation management, people analytics and eventually build into the system of record and augment what lattice could do to power the HRIS itself. And so it was pretty clear from day one, this team needs to grow and it needs to grow quickly. And so my remit became scaling the team, figuring out how to build a hiring process that would grow the team quickly while bringing in great people.

And get the operational and execution processes in place that would enable the team to scale. So that was for the first two years, really the primary focus. I wanted to spend some time diving into this specific moment where you now are focused on scaling, growing hiring process and then systems that scale because I think that then also sets up our operational excellence conversation in a really interesting way as well.

Let's dive into this. Like when it comes to like building a thoughtful recruiting and a hiring process like in this demand where you have to go from 20 people to more to like accomplish this vision focused on breadth. What was that like building out that hiring process? Yeah, it's one of the things I'm really proud of in hindsight. It took a lot of effort, but I think we got a lot of things right with it.

First is really making it systematic and repeatable because you're going to have a large number of people involved in the recruitment process. And as much as possible, you want to try to mitigate bias and have consistency in how you evaluate people, what you are objectively looking for. And you want to have a great candidate experience throughout that whole process. So at the time when I joined, lattice was still relatively unknown, which meant we had to get people excited about the vision.

We had to get them excited about why joining the company would be great for them in their career. And we had to do a lot of that upfront selling. But then we also wanted to make sure we had a rigorous assessment process that would look at the different dimensions of what we value in our engine.

And we value in our engineering team things like values alignment to the company, things like technical craft ownership mindset cross functional collaboration. So really getting all of those dimensions on the table. And then being very thoughtful and designing questions that we felt could have real rubrics that back them up. What what is a poor fair, good, excellent answer to this question look like and try to systematize it as much as possible.

So we had to activate the whole engineering team on board a new hire and then very quickly get them interviewing because that's the only way that you can really work through the hyper growth process effectively is to make that repeatable and reciprocal very, very fast.

And then we finally considered it, but like the goal to get a new hire hiring as fast as possible to increase the speed of scaling. I didn't even think about like the inherent challenges of that because now you have to get them up to speed with vision and sort of selling the company.

And then on top of that, like alignment around the assessment process itself and like the process around it. I want to talk about then like let's go let's go back to like how to get somebody excited about the vision. What was the process at the beginning to develop that and what did success look like for you there? Yeah, one of the things we worked on early on is like what is the employee value proposition? Why would somebody choose to work for lattice?

The qualified technical talent at the time was hotly in demand and had ample choice about where to work. So much like you need to differentiate on the product strategy front and say why are we different, why are we better? So too we needed to do with our employees and say what is the value proposition?

So what was the difference? Why would somebody choose to work here? A lot of what we kept coming back to was the vision and mission and purpose of the company. So really talking about why does lattice exist? What are we trying to do here? And a lot of people have had an experience of poor HR systems or poor management and can sort of personally connect to and relate to the challenges that lattice is trying to solve.

So we would lean into that as like a resident problem that people wanted to make better. The second was about the culture, the people, you know, working in a high talent density environment with high collaboration, feeling like people have opportunity to learn and grow and progress their career, which, you know, to come back to how we trained our interviewers, we made that part of the interview training of like how do you present yourself?

So you can present the culture and the company as part of that bidirectional evaluation process. It's not just you assessing the candidate but the candidate assessing us at the same time. So that was another piece is like really helping people feel the warm and collaborative environment that we were creating a lot of us.

The third was financial as an early stage startup, you can't always compete dollar to dollar for, you know, liquid salary, obviously the equity is still private, but helping candidates understand the potential and model out what different scenarios could look like in terms of financial reward knowing that there's risk that they're taking, but how might that risk materialize in potential future monetary value.

And you know, one thing I learned from that is that a lot of awareness about how to reason about equity is just not very strong. And so we had to spend a lot of time training candidates on how to think about that. I have a couple of follow-up questions here to get into this. So you're talking about like the presenting culture part of the experience. How did that work like within the process, either in the hiring process or an afternoon like onboarding them? What did that sort of look like?

One of the things that Ladis built into its company culture very early was company values. Before company values, we've had them consistent over the past several years. And we've tried to operationalize those values in multiple ways. One is in the recruiting process we have an interview question designed to test values alignment.

A lot of companies talk about culture fit. We never really liked culture fit because culture fit can be sort of opaque as to what it truly means. And values alignment is more explicit. These are the things that we value in how we see ourselves, how we see our relationships with each other, how we see the world.

And then you can design questions that actually test that fitment with those values. So you know, even just having that values question in our interview loops, I think said a lot to candidates early on about how seriously we take these things. I could talk more about what we do once folks join to ritualize and operationalize the values, but focusing on the interview process.

The other thing that we really did was cultivate this mindset in the interviewers. This always be selling, always be closing kind of mindset, which is the way that we speak about the company, the way that we speak about how we work with each other.

Even just very simple things like a candidate's been in back to back interviews, you hop on, hey, how are you? Do you need a five minute break? Do you need a biobake restroom, anything? Very simple, but it just goes to show an intentionality about how we treat each other and the space that we give each other. And so we would train interviews on interviewers on some of those tactics, right?

Hey, at the beginning of the call, set the agenda. We're going to spend this amount of time on these topics. We're going to spend this amount of time to give you space to ask questions of me. Now the candidate knows what to expect. They're put at ease. It's sort of simple stuff, but it really colors the way that people feel about the interview itself. What kind of feeling do they have about the company coming out of it?

I mean, I'm just putting myself in the shoes of that candidate and sitting there and having somebody who instantly has sort of this level of empathy for where I'm at in this process or who understands what I'm going through, just ask the question of like, hey, do you need five minutes? We can start this in a second. I think automatically clues them in to think like, oh, they care about me already. So like as a differentiator, the sentiment of the feeling is like they care.

And I think that's such a powerful difference maker when it comes to competitive hiring environment. Totally agree. That was one of the things I was very proud of is at the very end of the interview. We would have what's called a wrap up, which is where the hiring manager just meets with the candidate and basically says, how to go? Do you have feedback for us? Did you enjoy the interview experience? Did you find anything out of place? Like tell us about your experience with this process.

What do you make of the opportunity? What do you think of the company now that you've had the chance to meet all these folks and ask questions? And that was just this opportunity for us to continuously tweak the process. I was really proud of the fact that, you know, nine times out of 10 candidate would get to that stage.

And they would say this was the most thoughtful interview process I've had in a long time. I loved the interviewer, you know, just really positive feedback. And it was something that was proud of.

Are there other experience differentiators that stood out as you're building the process like other like those of those like little changes or levels of intentionality in the hiring process that made a difference to Candace that you know, so in that feedback process like where there are other like little experiences that that changed the process for them.

The other thing that we did and this is something that I learned from my time at Dropbox is when we got to final rounds with a candidate that we were really excited about. We would have all of the interviewers reach out with the congratulations email about receiving an offer. We were going to move to offer and highlight one thing that they really appreciated about their interview.

So being like, hey, I really appreciated the ownership minds that you demonstrated when you answered this question or I was really impressed with how quickly you were able to solve this problem. We were really looking forward to the opportunity to work with you and just help the candidate really feel that appreciation and we want you to be part of this team, you know, that enthusiasm on the part of the interview panel.

So I know I know some other companies do that too, but it's just a really nice way to help the candidate feel loved and feel excited and you know, see that you really want them a part of the team. Absolutely, I love that. I love that practice because I think it makes people feel so special and just I feel the same way about like handwritten think you know it's like it's like such a it probably requires a little bit of effort, but it like leaves a maximum impression on folks like that.

Thank you note like of the one thing special that loves like people just normally don't do that because like we perceive ourselves as so busy like this is such a differentiator. So I think about like somebody maybe who's trying to like employ this or like introduce this their hiring process like and maybe there is this like I don't have time differentiation like how did this become systematized within like a cultural norm as a part of the company.

One of the things that I think is important to realize in the team building stage is ideas are cheap execution is everything. There are fewer things that are higher leverage than hiring the next great team member when you have way more to do than your current team can possibly do and the additional team member is going to help bring the vision to life.

And so that you know that's not in all circumstances right you have to have a very clear vision of what you're trying to do you have to have the funding in capital you have to know that hiring is the right solution versus keeping the team small with a high talent density.

But if you're in that position where you know adding that next team member is going to create so much impact for the organization and for the business then it's really a maximally leverage use of time to put in that extra 20% to make it delightful to get the best a plus team member you can.

And we would talk about that with the engineering team in terms of impact and when we talk a little later about operational excellence will talk about the role that impact plays in our psychology but we would really frame like we expect engineers to be interviewing even though it's time away from writing code to have a ton of impact here's why and sort of helping people see the power of bringing on that next team member.

So just making sure it was like a priority we had to put limits on it right because when we were in the craziest period of this growth we could have had our engineers spending 10 hours a week interviewing but we said no that's that's unacceptable we have to put limit on this right so we we capped it at yeah I think it was four interviews a week was the most that somebody could do and then that created a constraint on how many candidates we could speak with but yeah just helping people understand how impactful it is.

I want to shift to the moment where like you were trying to accelerate bringing people in and then immediately getting them involved in the hiring process so want to talk about like training the hiring team and training the engineering team on how to hire what did that look like and what were some of the practices that ended up becoming really effective within that process.

One thing I did was I put together an edge hiring overview which was sort of like our philosophy on hiring and we would give this to new folks when they joined so we would talk about the value of the candidate experience we would talk about the fact we want to make it a delightful process we would also document what we call loops which are for different levels of experience and different skill set profiles what questions would we administer to test their abilities and we had this document.

And we had this documented in a spreadsheet that was a part of everybody is on boarding packet where people could get up to speed with the question bank all the questions were documented the questions had rubrics one of the things that I'm also proud of in this process is the fact that we tried to document what a good interview looked like and so we had a couple of different dimensions for example if a candidate was doing a coding exercise or a problem solving exercise we came up with.

Three axes of ability the first was the level of progress so like how far did the candidate get did they solve the whole problem did they get to step two of the problem or did they run out of time and so we would say that they had a poor fair good or great result we would evaluate their level of autonomy so like how much guidance or direction did the candidate require did they need nudging and assistance from the interviewer or were they able to just sort of self drive and then the last was a level of mastery so like I.

So like how high quality was their code were they using good libraries and frameworks were they coming up with efficient solutions and so each question had a set of rubrics that said what does poor fair good and great look like along each of these axes and so some of the questions would be like oh you completed part one that's good you completed part two that's great.

So if candidate had high quality code that's good you know and so we sort of documented what each of these things look like obviously you know I couldn't do this all myself it was a team effort and so the other thing that we did was we had an open slack channel which was called end hiring process and we sort of treated this whole thing like a product and said how do we get engineers involved how do we have people come up with new questions how do we have people share feedback so that we can iterate on the process you know much like.

You would do an MVP product and then you get feedback and you'd iterate we had an MVP hiring process and we were constantly tweaking it it was just like going through so much iteration and new people would join the company and they would say hey in my interview I thought this was a little strange and subpar could we incorporate the end so we just got people activated from the very earliest days.

It reminds me like the quote from Buddhist philosophy is like how you do one thing is how you do everything and so I love this idea this mindset of like treating like a product deploying the same level of thoughtfulness that we bring to the work that we do into a critical experience which is the hiring experience.

How did you create the rubric and the loop documentation like what did that process look like from MVP to maybe like sustained process yeah started out pretty narrow and it got built out over time.

So one thing that we tried to do was avoid requiring interviewers to establish the level of a candidate and I say that because I think leveling is a difficult topic it's one that you train your management team on with you know hopefully career frameworks and calibrations to help get the management team all aligned on what does a senior level impact look like versus a staff level impact.

So when you put maybe like a new hire who's new to your company who doesn't maybe yet understand how promotions or leveling is done at your company deeply in the position of needing to assess somebody's level it doesn't feel good.

So one of the intentional designs of the loops was to say how do we have questions that test ability that can have objective rubrics that are agnostic of level and then for the leveling questions we built dedicated experience based questions that would be like a case study.

Like walk us through something you've built in practice give us a presentation about your past experience and we would have folks who are more trained and calibrated on leveling do that leveling assessment so that would be things like managers or like really senior ICs who are part of calibrations those folks who are like yeah how do I distinguish between a senior engineer and a staff engineer they would be the ones conducting those more.

You know subject to frankly subjective interviews because they would be more trained on that on that process so at the end of the day with the loops looked like was like what are we interviewing for is it a full stack suite is it a front end is it a back end infrastructure engineer.

What level are we hiring for is this a mid level is a senior is this a staff and then based on that we would have different questions that would either just test kind of problem solving and coding ability level agnostic versus more experience based questions that would get into demonstrating leveling signal based on past work.

The separation in the identifying of like who's the best suited to be able to assess this that's elegant I love that I want to ask one more question related this before we dive in operational excellence and thinking about like in reflecting on what's worked and what's been successful in the hiring process like has there been anything that's become more important now in I guess like the last year with the environment that we're operating in like are there certain things that you focus on now with more with the value proposition or there certain systems or processes that now have a greater shift of focus or have.

I guess or how you started to adjust your tweak to meet sort of the changing environment like the hiring environment that we're in like I guess there's something new that's important now that maybe was less less focused on in the last couple years. Yeah it's a good question I think with the macro economic backdrop in which we're operating everybody is just a little more nervous about changing role everybody is a little bit more nervous about the potential for layoffs in the future.

Everybody's a little more nervous about the long term trajectory and potential equity value of these companies I think now more than ever it's really important for us to talk about why are we still committed to our vision convicted and where we're going why do we believe we're in a good position as a business be real about some of the challenges that we faced and transparent about some of the unknowns because we can't just promise everything is going to be smooth sailing going forward.

But just really be clear on why we still have a strong conviction and where we're headed and be open with people that it's not going to be you know just up into the right there's going to be ups and downs along the way and how we navigate those as a team together.

And if I go back to like the employee value proposition that we're talking about you know in the earlier hypergote days I still think a lot of those remain true for us right it's about the mission and about what we're trying to build it's about the culture and the people it's about the long term.

Potential financial reward but those first two really matter a great deal in shaping the day to day sense of purpose and the day to day collaboration people are having and so we really try to mean heavily on those and we always have.

When you're speaking to some of the anxieties that people are experiencing right now I think that's a really a really great transition to dive into some of the the operational excellence elements I think just like first to like define kind of what we're looking at like when we when we talk about like operational excellence as a focus like what do we mean and then what are some of the elements that are top of mind for you right now when you're going to be able to do that.

And then you're going to be able to define for you right now when you're when you're thinking about this as a as a challenge so you probably seen some of Shashir's work from Koda he says you know what are the rituals of great teams they're they're named every employee knows them by their first Friday and they're templated and they basically create the operating system for your company.

And I think that's a really great deal in the operational excellence I'm thinking a lot about what are those rituals because the rituals create the standards that everybody is working against they run a full spectrum from what's the road map and what goals do you set around road map

how do you do goal setting okay ours V2 moms how do you check in on those and hold teams accountable to them what do you look at from a cultural health standpoint to know that a team has good psychological safety and autonomy and the culture is healthy and happy and how often do you review those signals how often do you talk about them and drive action around them and then back to promotions what do you promote what's the template that you're giving your team come promotion time for how they describe

that they're ready for that next level the thing that I think about when it comes to operational excellence is like what are those rituals what type of organizational psychology are they creating because they are telling your team what matters most and as things have shifted from the boom times of three years ago to now like how have the pressures on the business shifted such that those rituals need to be re examined and what sort of things you're incentivizing need to be tweaked.

As you've been reflecting and focusing on rituals as a driver what have been the rituals that you focused on most or the what have been maybe some of the dilemmas that you faced as it impacts culture as it impacts psychology and behavior.

Yeah, so early on one of the first rituals that we established as we were growing the teams we were moving into a pod structure where each pod would own like a vertical slice of the product and it would have a full stack cross functional team owning that product end to end we would do what we call the pod check in and it had a template.

The goal was how do we assess the totality of this product and team right so we checked in on road map we checked in on goals we checked in on team surveys we did team surveys at the time to assess how much ownership and autonomy and sort of taken from this squad check in model that spotify had that became our heartbeat that became the place where we identified cultural tensions that became the thing where we identified the projects were off track it worked really well until it didn't anymore you know it like it didn't scale scale.

Super well when you had multiple layers of management and dozens of teams so we had to reassess in the early days we did a lot of decision making in smaller forums where we could move very quickly and we didn't need to bring stakeholders along as we grew and got bigger and decisions got more complicated and required more cross functional input we started using process from square called spades which is a decision making process process.

Where you basically outline what's the decision you're trying to make who needs to review and approve the decisions who needs to be consulted and who needs to be informed and then you outline alternatives and it becomes a much more written oriented decision making process where you can share the spade get a very broad set of input and get to a point where you can look at the set of options fairly objectively and say yeah those do reflect the pros and cons of all these different paths like what do we value most and make a decision and move forward.

And all of these things come with their own baggage and tradeoffs but for us it's been like constantly re-examining is this process still serving us for the new pressures in the state of the org or do we need to tweak it and change it and revisit it.

You know I'll give another good example in their early days we had a site wide uptime measurement and a site wide incident management process and if there was performance degradation or outages or what have you we would call an incident the incident would go to one big on call rotation.

We would retro that incident and learn from it and figure out what actions we could take to improve didn't work when we started to have multiple products at different stages of maturity performance started to matter in the depths of a very specific reviews analytics workflow for some of our larger clients. What we had to do is sort of make this process recursive and say okay how do we now do more localized incident management incident reviews how do we take that concept of site wide uptime.

Move it to reviews product specific uptime measures reviews product specific performance metrics. How do we break this stuff down further into higher depths of granularity because now we've got way more customers and they're way more in the weeds of these different product experiences.

So just constantly tweaking and and one of the things that we've been really mindful of is every time we add a process like what are we taking away because the other thing that can happen as you're going through this growth you identify a problem you identify a process to solve it is you just end up with too many processes and now people are in meetings all day and now it's really hard to get things done.

And so every time we would try to tweak or introduce something we would say is there some meeting we can kill or does this replace something else that we're doing today just so that we can have a relatively streamlined set of operations.

Is there an example of that because that is such a step that I always forget like I don't even I don't even consider I'm just like okay process template we define that it's automated it's good but then all of a sudden it takes longer to like navigate the process than it would just do it outside process.

What would be a good example of like the end and replace so when we did our road mapping as probably like a 50 person EPD team we did a meeting with sales and go to market leadership every quarter as part of our road mapping process and we would look at the most in demand features why are we losing deals why are we losing renewals what areas have the highest number of cx tickets that we should address in the road map.

To make the product quality better and product experience better it was a really helpful way to make sure go to market and EPD were aligned on the biggest priorities and we're getting factored into the road map by the time we were like 100 people are like 150 people you could see in that meeting like people's eyes glaze over when like it's they're not you're not talking about your product.

So it's like two hour three hour meeting or going through all the feedback but you really only care about like your slice of the product and you don't want to look at the whole deck and the whole analysis and be part of this big expensive meeting.

So again we had to like granularize that and break it up and say okay what is working about this process we clearly need to kill and retool this thing but what is working about this process and how do we preserve the good elements while you know delegating so we came up with a model where there were sort of champions by product line.

In the go to market teams there'd be like a cx specialist and sale specialist who would like basically be responsible for aggregating feedback for that product line and then have a more localized meeting with the product owners and the leaders of that product spoke so that it could be much more focused. We were actually able to increase the cadence instead of doing this big expensive aggregation of feedback.

Quarterly we could do it more frequently and more routinely because it's scope was strong so that's maybe a good example of how the process got retooled as we grew. That's great the eyes glazed over part where people are only concerned about their what like optimize for their one slice of it. I think what's such a thoughtful shift.

So I think like a broader a broader question related to the rituals here I think is so interesting is how do you identify the gaps when the rituals or the ways of working are no longer serving you.

Are there certain signals that you're looking for and I think the other side of this question is like if you're looking at a certain process or or operational element like how do you think about the end vision like how do you like what is your process to determine what is the end state you want this to look like so I guess like gaps in end state are apart I'd love to learn more about.

Yeah on the gaps front it sounds silly but the eyes glazing over thing is a real thing right like when you don't have small tight meetings with really engaged people you've got big meetings with like eyes glazing over something is broken and it needs to get changed you know you want people when they're in a meeting there's a purpose for their attendance and they feel part of it and if they're just there as a spectator you know that that's usually a smell that something is just change.

Another one is like you know I heard this in an interview with Jeff Bezos he said something along the lines of when the anecdotes don't match the data trust the anecdotes and so we had an example with this site wide up time and these rituals around managing performance where we were hearing customer anecdotes and escalations that like things were not good despite the indicators being good when you have that kind of a situation of customer stories and anecdotes or feedback from the site.

Feedback from the sales team that does not line up with the management interface that you have with the teams like you've got your pod check ins or your monthly business reviews or whatever and the scoreboard looks green it's like something's missing something needs to be retooled here so something I always try to do as a leader is really maintain good relationships with a bunch of different people around the or so that I can get that more like quick gut take on things.

That cause me to cross examine the data and say do I really trust the process is this ritual actually serving us or are we missing things so those are two tactics on the gap side that I think have helped me on the final state I just don't think there is a final state it's a constantly fluid it's this iterative mindset that I talked about with our interview process I think it's the same with our rituals you have principles you know you don't want people to waste time in meetings you want to make sure people are engaged you got small tight focused

meetings where you can make decisions you know maybe you want to have a really inclusive culture and so you want to create space for people to like pre read a document and express their feedback and thoughts asynchronously or at the start of the meeting and writing so that one person doesn't

dominate the synchronous time in the meeting like that could be a principle of how you want your rituals to work and I think those can help you with the long lived final state because they help shape what matters to you culturally but I think the ritual format itself is just like a constant work in progress I want to switch topics to incentives specifically how to consciously apply incentives and reward structures within your engineering organization and maybe the other side of this is like incentivizing impact I know that's like a dilemma that we we've talked about in the past.

Like how do you think about incentives and rewards what are the dilemmas at play here and how can we be more conscious with this in the engineering organization. Yeah, there's that old saying your company culture is who you hire who you fire and who you promote which is a little class but I think pretty real it's a constant tension and struggle of like what kind of behaviors are you role modeling what kind of impact are you role modeling to the rest of the org when you make promotion decisions.

And one thing that I think we struggle with particularly in engineering is this gravitational pull towards complexity there's like promotion projects that people do in pursuit of that next level and complexity is easy because like if something is complex it takes a lot of effort if something is complex it takes a lot of technical craft mastery you have to know how to operate and build this complicated thing it can often be correlated with innovation because maybe you're trying a bunch of new technologies and so it's not easy to do it.

And so it's very easy to like look at complexity and reward it but on the other side complexity is terrible to operate if you have a simple idea you have a simple feature you have a simple system it's easy to understand it's easy to use it's easy to build and scale and operate you hire new people they can learn it quickly they have lower operational costs.

I think this is one of the core tensions that we face in engineering which is like how do you recognize elegant simple solutions that have a big impact and don't over rotate and over bias your engineering ladder and your career framework and things like that on complexity and I will not claim to have like a bulletproof answer like I think this is just an ongoing thing that we're talking about in

our promotion process but one of the ways that we've been trying to confront that Atlantis is to really have the promotion process and score cards index heavily on impact and so we talk about impact in a few different categories.

The first is like how are you impacting the customer in the business so how are you making the product better how are you solving customer problems how is that you know translating into higher customer satisfaction or lower turn or new sales or whatever so trying to get that

that's orientation and connectivity into the engineering team another way to have impact is through impacting your team right like how are you helping your team be more effective are you mentoring other individuals are you on boarding and growing other individuals are you suggesting changes in the process that's making your team more effective or more efficient sort of related is more organizational impact where you know maybe you're having that same type of impact at a broader scope maybe

you're coming up with processes that influence an impact all of engineering or maybe you're tightening the partnership with our cross functional partners in one way or another but you're sort of having that outside of your team impact on the culture and the way the company works and then the last is if you have some kind of strategic technical impact like maybe you're just able to pay off a whole category of tech debt or come up with a new framework or approach that multiple teams start using that makes them all more productive or you've been working in a really fragile part of the code base and you add tests and the test

make it easier to do development work in the future you know all of these things are sort of technical impact that are helping the engineering team work more productively and more effectively when we try to bring these promotion cases and calibration conversations we're trying to say like forget the complexity

forget the tactics forget the systems that were bill what was the end impact how did it make the customers life better how did it make a peer engineers life better how did it make a peer letitian who's in go to market's life better and if we can index on that you know we can not totally mitigate this bias toward complexity but we can at least frame it in the context of how is it serving us right how is this complexity serving us or not serving us

how do you balance or account for like some of the forms or the role of like output or like output metrics or like measurements of output within this sort of scorecard or understanding like how do you I guess how do you wrestle with between like impact and output yeah that is a really good question I view output as an input to impact right like as software engineers what do we do we write code like we build products right it's it's really hard to have impact if we don't write code

but at the same time I have seen engineers you know spend a week working on a really gnarly performance issue that produces a one line change of code that makes the site way faster you know and so it's like if you're just looking at output

what does engineer do all week they like wrote one line of code but you know it doesn't capture the impact that they were able to have through that really focused narrow change and I think that's the heart of the simplicity complexity thing is like there are very simple elegant solutions that require very little effort but ultimately produce maximum impact and so I think you have to look at output there's no way that you can not look at output you know we write code that's what we do but it's really important to compartmentalize the role that it plays

you never want to set metrics or measures around PRs or velocity or anything like that because that is not impact it's a means to achieving impact and you know speaking of incentives this is something that some peers of mine were discussing recently like when it comes to like incident management right if you say we don't want to have

a set of goals around reducing the number of sebs you've got a problem on your hands because now people won't want to file sebs if there's a customer issue if there's a part of the product that's down or whatever you want the reaction of the team to be customer centric and to file that

and to take care of it and so you know it's like it's more about how do you set goals around the time to detect the time to fix the time to remediate how do you set goals around the action items that you've identified and closing the loop on them but when you start to set goals on sebs directly you create a lot of organizational bad behaviors and I think the same is true with output you set specific goals about output and now you incentivize all the wrong organizational behaviors.

So the final question was to ask around this was you know you're talking about indexing on impact balancing output and how that impacts incentives and how you want to kind of avoid incentivizing bad behavior for folks who maybe like want a shift to incentivizing impact or assessing impact and avoid some of the bad incentives are there certain directional changes that they can make or are there any first steps that they could take to move towards impact and be more conscious of the impact.

Be more conscious of how to avoid bad incentives I think a really powerful tool is your career framework and how you do performance management every company is different I've definitely seen this first hand at lattice looking at how many different configurable things customers want out of our performance review and calibration product but pretty much everybody does something I would introspect that process as an engineering leader and ask yourself honestly like what are we record.

What are we recognizing and what are we rewarding and sort of come at it with like a bit of a devil's advocate perspective of like if I wanted to critique this thing how would I critique it what would I say could be improved and use that as a starting point right because pretty much everybody has some starting point and it's it's hard to know without context what's going to be most impactful to change but in that I would look at things like in your career framework.

Where do you talk about the results that are generated by the effort or do you only talk about the tactics you talk primarily about building big complex systems or do you talk about the resulting impact to performance customer etc and that language just kind of taking a pass of that language I think can say a lot.

The other thing that I have found really helpful is close partnership with your product team like asking the why behind everything that we do as an engineering team why are we doing this what benefit is it going to have is it going to improve quality and drive down customer tickets is it going to help us close new deals because there's a new value proposition what is the bigger picture why behind this thing and I think if engineers don't understand that they should push back.

Because like ultimately we're owners of the products that we build right and so close partnership with product and data it like brings that connectivity to the purpose and meaning and an impact of everything that we're doing if you don't understand why push back I love that steam we've got some rapid fire questions to wrap things up if you're ready to jump in let's do it all right first question what are you reading or listening to right now so great lock just started a podcast called product led AI there's only a couple of episodes right now but they're they're looking at the application language.

And I'm looking at the application layer like what are people doing with AI and it's just a really helpful cross sectional view into how different companies are thinking about this new transformative technology and how they can best leverage it for their businesses so I've been having fun listening to that next question what's a tool or methodology that's had a big impact on you early in my career I came across the getting things done philosophy and you know one of the things that they talk about there is just like get it out of your head like if you think of something that you need to do right it down and I'm going to do it.

And I've just like lived that religiously ever since because if I can free up my head space so it's not in my head it's written down somewhere I know I'm going to get back to it there's just a sense of closure that like it's tracked somewhere and I don't have to worry about it.

So I just try to free up my cluttered head space as much as possible when I think of something it like gets written down immediately I've used a lot of tools over the years the one that has stuck with the most is Dropbox paper which I did work on Dropbox paper so but it's just so simple and elegant to be able to like create different categories and move things around and like tree up.

And then like triage stuff crossed off off often what I'll do is all like make a brand new document and I'll carry things over from a previous document into the next one versus leave things behind and it's just like a workflow that I've built that works for me.

You and I operate so similarly I have like such a deep necessity to archive every thought and piece of information because it occupies so much space up here but I just need it to exist outside of my head so I appreciate that and it sounds like Dropbox paper is probably most similarly mapped to how you think considering you worked on it. So next question what's a trend you're seeing or following that's been interesting or hasn't hit the mainstream yet.

I'm actually wearing a continuous glucose monitor right now. I'm healthy. I'm not prediabetic or have diabetes or anything like that but I've just been learning more about the impact of blood sugar like your blood sugar response on your health and have become interested in the sort of quantified self of feedback of what I eat.

How is it affecting my blood sugar how is it affecting my energy and right now it's pretty expensive which is why I don't think it can go mainstream but if they can get the cost down and I know there's been like rumors of Apple working on a sensor that could go in the Apple watch and things like that. I think there's something there that could be very powerful to help people better monitor what they eat and what they're putting in their body.

I'm so obsessed with like the whole world of health tech. I think there's there's so many incredible things there. Well that all right last question. Steven is there a quote or a mantra that you live by or a quote that's been resonating with you right now. Yeah this is actually one that comes from a family member from my partner's family just do your best.

I'm able to critique myself a lot. It's both a strength and a weakness right to be able to look at the things I've done see some of the negative consequences look at the things have done see some of the positive consequences but like I sometimes beat myself up and hold very high standards on myself and sometimes it's just good to remember like you're doing your best. So all anyone can ask for is do your best.

I think it's an incredible relief to close off this conversation about all the challenges around operational excellence and hyper growth in the end of the day like reflecting on like you know there's probably an infinite of things you can optimize here or improve but at the end of the day just do your best even if that's in the work context but professionally speaking of rapid fire.

Can I rapid fire a couple additional resources at you absolutely yet things I intended to mention but didn't one is as it relates to understanding startup equity value a resource that I found.

And would give to like every candidate I could who interviewed with lattice was the hollow way guides to start up equity it's just an awesome resource if you ever have questions about how to think about startup equity there's also a really helpful calculator that front put out comp dot data dot front dot app they have like a tool to help you understand the value of your startup equity and then the last one is Steve

are tell over at gem I had the opportunity to work with him at Dropbox he's been putting out a blog of like a lot of these hiring things and it's just start a hiring 101 dot com it's an awesome resource highly recommend if you're trying to figure out how to build a recruiting process from scratch.

I think you just inspired a new you know talking about rituals and like changing rituals to serve like the different outcomes you looking for I think you just hands down inspired a new ritual for the podcast because we've never done like a rapid fire resource share and that was incredible.

So I guess to conclude like thank you for inspiring ritual change within how we're operating here I think that that pretty much captures like the intent and the impact of this conversation incredible thank you so much for having me on it's been a fun.

If you like this episode make sure you subscribe to our new podcast series engineering founders the leap from engineering leader to founder can be terrifying filled with unknowns and requires a completely different skill set we're going to be diving into the stories the pivotal moments and critical in the

insights from former engineering leaders turned founders that helped them take those early leaps to launch their company check it out you can also find the link for engineering founders in our show notes thanks for listening to the engineering leadership podcast.