In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Tim Olshansky of Zenput about cross functional teams, OKRs, career paths for technologists, and making tradeoffs between technical and customer needs.
Key Takeaways
- Cross-functional teams deliver more consistent value
- OKRs (objectives and key results) provides a framework for alignment and goal setting
- Only 1% of technologists want to become people managers
- You need to have a career framework that allows technical people to advance without needing to manage people
- It’s important to frame technical decisions in the context of customer and business needs not just technical expediency
Subscribe on:
Transcript
Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down across the miles today with Tim Olshansky from Zenput. Tim, welcome. Thanks for taking the time to talk to us today.
Tim Olshansky: Hi, Shane. And hi, everybody. Thanks for having me on the show.
Shane Hastie: Tim. You're an exat Australian. I'm a Kiwi, so we have at least something reasonably close in common, but now you're based in San Francisco. What took you there?
Introductions [00:40]
Tim Olshansky: I've been out here, it's pretty much 10 years at this point. I moved out here at the end of 2010 to pursue the startup dream like many, I think that's across the pond. I had some friends from uni who'd been out here for a few years. I'd been working in a non-technology-focused career in Australia for some time and decided that I wanted to go do something a little bit more interesting, a bit more business oriented, a bit more entrepreneurial. And we joined forces over here in San Francisco and started a company called Topguest that was in the travel tech space. Our investors were over here. So, that brought me over. And I've been here ever since.
Shane Hastie: Tell us about Zenput.
Tim Olshansky: I would love to. Over the years, I've been through a few different companies. This is probably the fourth startup I've been a part of. And Zenput is a company, I think the way we try to describe our mission is to eliminate food waste in food service or food retail. We work with businesses like Chipotle, McDonald's, Pizza Hut, Domino's, 7-Eleven, pick any major food brand that's operating at scale with many restaurants or stores. And we build a mobile software solution that helps them go and manage their operations.
Tim Olshansky: The analogy I like to use when I'm recruiting is to compare it to something like Datadog or New Relic, or even PagerDuty, to a large extent. We give our customers the same level of insight into what is going on inside of their restaurants or inside of their stores, similar to what we get in the IT world or the technology world with insight into our containers, into our server infrastructure, our fleets. So we provide the same levels of instrumentation, dashboarding analytics, and that sort of thing.
Shane Hastie: Your position there is the EVP of Product and Engineering, and in that space, you are leading many of the tech teams.
Tim Olshansky: That's right. Yes. I run the product management function, engineering and the IT and security and whatever else, as well as the product design side of things. I overlook the entire product development function as a whole and have done that, I guess, in past roles as a CTO or equivalent sort of position.
Shane Hastie: In terms of that breadth, how do you come up with, or nurture a culture that brings all of those things together in alignment with the business goals and needs?
The value of cross functional teams [02:57]
Tim Olshansky: That's an ongoing challenge, I think because we've certainly grown a lot as a company. So when I joined over two years ago now, we were about 30 people. We're now just shy of 100 and we've been growing quite well. And we didn't really have much of a product design function, frankly, we didn't have much of a product management function. We were very engineering heavy. And the lesson I've learned over my career is that the best solutions come from that triumvirate. I'm sure yourself, Shane, are well aware of and I'm sure many leaders and folks who listen, have heard it and spoken about it at length. So I won't bore everyone with the specifics, but I'm a big fan of, we call it The Three Amigos. We have a large presence in Mexico as well. So it blends culturally for us.
Tim Olshansky: We try to create cross-functional teams that have the core capabilities together. The agile squad sometimes called. We have a product designer, a product manager, engineering manager with a technical lead and engineers, all working together collaboratively to build solutions for our customers. We do a few things to try and drive that cross-functional collaboration starting from recruiting. We try to bring in people who are business minded, not purely technically minded and who have a proven track record of collaborating with other functions or coming from organizations we know have a strong culture of that sort. And then everything else from the way we set goals, the way we communicate and bring people together. Those three, four people always together in the same room, discussing things together, have the same set of goals and frankly assessed or measured collectively together as well.
Shane Hastie: One of the big shifts that we have started seeing in the last few years is this move to true cross-functional teams and to the measurement, the assessment of those cross-functional teams together, one of the traditional HR structure of stack-ranking people and comparing them against each other. We've learned it doesn't particularly work.
Tim Olshansky: No.
Shane Hastie: I honestly don't think it works in any industry, but in information technology and in the knowledge worker and productivity space, it definitely doesn't. So how did it go making those sorts of changes and how do you sell that to people?
Tim Olshansky: I haven't had a lot of challenge selling it to anybody we've had to bring onto the team mostly because I think they've come from organizations that have been through that failure. And so they see an alternative and then they just put their hand up and just, yes, this is what I want, which is nice. That helps. But the change piece, I suppose, starting from a blank slate in a small company that's growing, I think it's probably a little bit less difficult compared to a maybe more traditional organization that's been around for 10 to 15 years.
Moving from silos to cross-functional teams [05:32]
Tim Olshansky: To draw on experience from a prior company, give you a little bit more background on myself. So I, and a few others were co-founders of a startup called Worksite, which was a construction-technology-focused software company. We were acquired by Aconex, which was another construction technology company, much larger and publicly traded. And we joined. So we were the USs development side of the business when we were acquired. We were the start of the kind of product design and engineering teams in the US. And we had from the beginning established a model of working together that was highly collaborative and highly cross-functional, probably coming from our startup roots and the fact that we needed to work together so closely.
Tim Olshansky: We had a fantastic relationship, high degrees of trust, psychological safety. And even though I was the only Australian on the team out here in the US ironically joining an Australian software company, culturally, we were very similar, lots of stupid jokes, of course, and lots of banter in the workplace. But when we joined Aconex, Aconex was already a company on that trajectory of transforming from maybe your more traditional, almost like manufacturing line form of development, where you had business analysts, writing specs that would be handed over to an engineering manager who might convert that into tickets for the team to work on or to work with a BA to do that. And then there would be this sort of back and forth and design would be over here on the far left. And everybody's well separated.
OKRs as a framework for change [07:01]
Tim Olshansky: They'd already taken a lot of steps to transition across and had already started to set up cross-functional teams, and that was working reasonably well. But the thing that wasn't happening yet that my team brought to the organization was the collaborative goal-setting portion of it, where the team collectively were assessed by the objectives and key results that they were using. So we used the OKR framework. As any framework, it's only as good as you implement it. So the framework I think is less material, but the fact was is that we were very clear on what our ultimate outcome was going to be, what it is that we were trying to drive for the customer or the business. It was very measurable, all the classic smart stuff of specific, measurable, achievable, results oriented and targeted or timely. And we set that in a way that allowed each individual function to contribute to each piece.
Tim Olshansky: So we had the clear objective, and then there were the key results that tracked each of the functional areas. That worked great. Our collective manager, because we all reported essentially to the same person, which was probably another key piece of it, made it a lot easier, meant that they didn't need to get involved in conversations with, well, why are the engineers doing this? And why are the product managers coming up with these things and what the hell is design doing over here? So that created unified vision and purpose and meant that we could execute collectively well. And that worked so well, that's a model that was replicated across other teams.
Tim Olshansky: And so I've taken that experience and I've continued to do things that same way here at Zenput as well. So team goals are shared. It's very, very collaborative when we go through the process of setting up OKRs or goals for that matter on a quarterly basis. We get everybody together in their functions and we get them all to come up with how they're going to contribute as opposed to doing it in silos that are maybe very specific to a function. And that helps a lot. That's just very tactical, but it's definitely a key piece of it I think.
Shane Hastie: This sounds to me like you've got good alignment, good, clear understanding across the teams of why. How do you support the technologist who's not necessarily that interested in the people side of things?
Only 1% of technologists want to become people managers [09:16]
Tim Olshansky: As we've been growing, we actually did a survey of the team through one-on-ones and other conversations, trying to gauge how many people want to become people managers. And if you had to guess, Shane, how many do you think put their hands up?
Shane Hastie: 5%, the technical team.
Tim Olshansky: Barely 1%. Nobody really wanted to do it, but that was not a surprise to me. I've been with this team for a while. I've gotten to know them pretty well. But I've always viewed the best path for people leaders are those that come through the organization because they have all the contacts. They've been a part of the early growing pains. They know the job really well. And so I personally really wanted to promote managers from within rather than having to hire externally. Alas, that's not something I think I'm going to be able to do, but we'll have one person. So we'll see, we'll make that happen.
Tim Olshansky: But as a result, and we'd already been taking steps in this direction, we wanted to create a career path for people and a way to contribute to the organization that was not reliant on managing people. But the reality is that in any growing organization or any organization that sees some measure of success, people are a large part of it in the knowledge worker world. So we had to find ways to create leadership structures that didn't also require a management structure, a classic dichotomy between leadership and management.
Career framework for technical contributors [10:36]
Tim Olshansky: We've got a few things. We have a career path or a career framework, I should say that separates the technical contributions from the people-focused contributions. We talk about the job as impacting the organization through technical contribution itself, as opposed to giving people direction on how those people can then contribute themselves. It's kind of direct versus indirect, but at both levels, at the most senior levels, you're still talking about large groups of people and trying to build vision and purpose and design a solution where our architects, if you will, some of the most senior folks, we don't use that title, but sort of makes sense, they still have to put together architecture vision documents, type of things. We use a combination of things like RFCs and ATRs and other types of documentation to help build that vision. And we hire for it as well. So when we're hiring somebody more senior level, we're looking for people who don't want to pursue a people management career path that have experience contributing to an organization outside of just hands-on keyboard. And so that's a necessary part of it.
Tim Olshansky: And then the last piece of it, we also create a little bit of structure around it. Something I believe in pretty firmly is that as a non-people manager, it can often be very difficult to lead teams without having structure around you to do it because you don't know how, and you don't often have the authority to go and influence people to not necessarily just influence, tell them right directly, although not something you should be doing. But we've created some structures as well to make it much easier for people who aren't people managers to be able to contribute. I'm a big fan of a guild-like structure. So something that creates a little bit of formality and gives people a set of, call it processes and practices to organize around a common topic or a common theme that allows them to both showcase their knowledge, be recognized as subject matter expert and have the opportunity to influence and mentor people who are probably less experienced to them so that they can then continue to impact the organization, grow the organization without having to also manage these people, be responsible for every intricate detail of their work as well.
Shane Hastie: And how do people take to that?
Tim Olshansky: Quite well. The reception has been pretty positive so far. Maybe ask me again in six months. We've done a few things over the course of the last say 18 months that have been pretty impactful. We've been a fairly distributed team for quite some time, maybe not on time zone, but definitely on location. Pre pandemic, we had team members in many different places and I've wanted to work actually everywhere I frankly worked. We've gone in with the mindset of let's design the way we work in a way that allows us to work anywhere, even if we all happen to be in the same place.
Tim Olshansky: And in order to facilitate the fact that we do have a little bit of time zone dispersion, we created some pathways for people to be able to communicate effectively. So classic agile rituals, of course, we're a scrum-focused team, so we have some of those things, but we use documentation quite a lot. And we use a couple of tools to support that. We use RFCs in something like confluence. We've created a template. We put some structure in there as well to make it easy to find that. We create some workflow around it, where we share it with people. We use tools like Figma. We use tools like Loom to make it really easy to document all conversations in one place. And of course, Slack as well for the chat portion of it.
Tim Olshansky: And I mention the tools because I think getting the tools right to support the processes is essential as well. So we've been using those tools to create an RFC process that works really well for significant technical designs and discussions. Any major infrastructure or architecture decision goes through a similar process, but results in an architecture decision record, or an ADR, which we found very helpful and creates this record for posterity reasons that allows new team members to look back and judge us based on our past decisions, having them all in one place.
Tim Olshansky: I maybe make it seem like it's a lot more rigorous than it is. It's not that rigorous, but just that little bit of structure has meant the team flies by comparison. They're able to collaborate really closely together and incorporate all functions as well. So we have product managers in there. We have product designers in there. We have software engineers in there, and QA as well are contributing.
Shane Hastie: You made the point that pre pandemic you were setting up for remote work. What's the impact been of the radical shift to remote that the pandemic has resulted in?
The pandemic impacted team happiness [14:57]
Tim Olshansky: I think the biggest impact has been on just say the happiness of people on the team, and that has been less to do with work and more to do with what's going on in the world around them. Because of the way we had been working well up until March of last year, we didn't actually notice much of a difference. From a productivity standpoint, I would say we're probably as productive as we were before the kind of shift to full-time remote began nine, 10 months ago. But I will say that the connections between team members are a lot weaker than they've ever been. And I think in the short term, I'm not too worried about it because we have the constraints that we can't really get together and that sort of thing.
The importance of shared social bonds [15:40]
Tim Olshansky: But I do personally fear the future where heavy deadline stress causes people to interact in ways that are maybe not optimal, say things they regret or do things they regret. And without that shared social bond of having gotten to know each other and seeing each other in person a few times, I think there's less tolerance or less willingness to forgive those sorts of social missteps that we might otherwise be okay with. And we've had some people join the company and they've gone many months now where they've basically only spoken to the four or five people in their scrum team. And so they haven't built that connection to the rest of the organization that I think is important again in the long run, not in the short term, but in the long run to build a high engagement and the desire to see the business succeed. That's the piece I worry about more so than the productivity portion.
Tim Olshansky: And pre-pandemic, something we used to do is if we weren't in a common location... We have three offices. We have an office in San Francisco, Atlanta, and in Guadalajara, Mexico. And we used to get together on a quarterly basis. So we'd fly everybody to one place and we'd spend some time together in one place. And then as a company, we do it all together once a year as well. So the inability to do that I think is concerning. And I will hopefully not notice any significant negative impact of it, but I'm anticipating that this time next year, if we haven't had a chance to get together, and we've again, doubled the size of the team as we're planning to do, it's going to be a lot harder for us to build a strong connection and have a cohesive culture and a cohesive approach to what we do.
Shane Hastie: You mentioned the productivity impacts have not being bad, but the happiness, this personal satisfaction impacts. How do we support our people when they are in this situation that we're in now, where there is that stress around us and so forth?
Supporting people through stressful times [17:35]
Tim Olshansky: The thing I found that's quite powerful is acknowledging the situation, stepping up and saying, hey, this sucks. And this sucks for me. I'm struggling with these things and sharing personal stories and things that perhaps your colleagues are also going through or peers are also going through. I've found also encouraging people to actually establish good boundaries, pretty powerful as well. So very early on, I noticed a tendency, not only in myself, but of course, in other people on the team to spend 16 hours working, basically. From the moment they wake up until they went to sleep, they were in front of their computer. Now I don't imagine that they were working for that 16 hours because I think you need to take breaks and all those other things.
Tim Olshansky: But the reality was is they were sitting there. They had Slack open, they would respond to messages. They were probably doing some work and they were certainly doing some work for the bulk of the day. And I could see bags under the eyes on the Zoom calls. I could see just like a lack of energy in the voice or hear, I should say a lack of energy in the voice. I've been fairly vocal in pushing my team to end the day at a normal time, create some rituals for yourself, go for a walk, go break things up, take lunch, have a lunch break. Don't feel like you're chained to your desk just because you're at home and it's a five meter walk to your bed just across the living room or wherever you happen to be.
Tim Olshansky: And not only that, we've been, or I would say we as a whole organization have been pretty pedantic about people taking time off and ensuring that they're taking a break, even if they're just sitting at home, watching television for a week, or just separating themselves from work as well. Because again, same thing, not a lot of energy, not a great degree of engagement, better to take a break, play video games, watch some TV, go for some walks, learn a new hobby, do something else to reenergize. And then on top of that, we also have been investing in a number of tools that we have available to us over here in the US. So counseling services, all kinds of like physiotherapy as well because people are sitting in front of their desks and they're developing bad posture and back pain and all those sorts of things, and care packages and trying to not spend too much time on Zoom, but having some well-timed and well-placed social events digitally as well, as much as possible.
Shane Hastie: Sounds like good sensible things to be doing and good advice for others, if they haven't thought about these things.
Tim Olshansky: Absolutely. Yes.
Shane Hastie: What happens when technical people make good technical decisions that are not necessarily good for the business?
The conflict between good technical decisions and business needs [20:12]
Tim Olshansky: This is near and dear to me right now, as well as we're scaling up, we're getting bigger. We're starting to think about the standard Conway's law type situations with designing our architecture. And I've found myself with some of the more senior members of the team spending a lot of time talking about technology and technology choices that are probably right. I was a software engineer, I suppose I still am to a certain extent. They're probably sound technical decisions, but when you put it in the context of the business and what the business needs for the next 12 months, it's very difficult to justify investing in technology X, Y, or Z.
Tim Olshansky: And I think the tendency I've come across in my career of strong technologists to focus on the technology and not really consider the business context is.. How do I put it? I think it's the thing that holds back a lot of peers of mine who have pursued more technical career paths from becoming rock stars to use that cliche. To give you an example. Now I'm a big fan of continuous deployment, continuous delivery. And I think that high performing teams can deploy on a dime and do it very regularly. And I find myself often in conversations with software engineers who will tell me that we absolutely must be able to click a button and deploy changes in 10 minutes immediately from the moment it's committed, merged, and deployed, like we have to do it.
Tim Olshansky: And the conversation usually becomes Socratic because I've been through it so many times. So I'll ask the question, why, why, why, why? And the context of the business is really important. So my business or the company I work for, we're building enterprise software. Our customers are using us in mission critical ways, and they're not interested in learning new UIs constantly. They're not interested in picking up and having to read user manuals or contacting support. And of course we invest in usability testing and we want to make it as simple as possible. But the reality is that when you're presented with a change, as we've all been presented with in the tools that we use, there's a moment of frustration with, I just wanted to finish what I was doing.
Tim Olshansky: And so if you consider those sorts of things, the risk of stuff breaking, the needs of the organization, and you ask that question in the business I'm a part of, why do we need to release 50 times a day, why do we need to push out every change instantaneously, you come to the conclusion that you don't need to. You don't need to do it. You can get away with doing it once a week. You can maybe get away with it doing every couple of weeks, whatever suits the nature of the business. There are customers that you have as a senior technologist that are not just your end users. They're also the people inside your company. And in the case of say, talking about the continuous delivery pipeline, you've got product marketers that need to put together release communications. You've got customer success or customer support people that need to be trained. You've got salespeople that need to be aware of how their demo scripts are changing. You've got all these different people that need to be kept closely in the loop when you're pushing out a change.
Tim Olshansky: The technical brilliance of being able to press a button and have the changes appear in production instantaneously makes a ton of sense for a company like Amazon or an e-commerce business, where you want to be able to maximize the transactions that your users are completing. And it's very heavily data-driven. And you've got tons of individual users that you can reflect on. In a different type of business, that may not always make sense. So considering the context that your technical solution operates in, I think is critical. It's essential. And as a result, your customer is, like I said, not just the end user, it's all these people inside and thinking about what they need and what their problems are and how to support them is essential.
Tim Olshansky: This is the thing about the technology choice that I see over and over and over again, they only consider maybe 20% of the customer base or maybe 50% of the customer base. There's this iceberg that's hidden below the water of all these other people who care about the solution, all these other customers that sometimes the strongest technologists overlook, because they're so hyper-focused on this one cool technical thing or this one individual aspect of the problem. And so I coach members of my team over and over and over again, to step back and don't think about it from the, oh, wouldn't it be cool if we were using Apollo or GraphQL or whatever, and think about it from the context of what do your customers need?
Tim Olshansky: You're designing a solution for a set of customers. Who are your customers? Are they the end user? Are they product marketers inside the company? Are they other software engineers on the team, product managers, whatever? And what are their needs and what are you solving for? And do we really need to introduce 50 microservices with absolutely no experience running Kubernetes at scale, just because we think microservices is the coolest thing ever, and we could press a button and deploy immediately? Do we need that? Not really. And then you go through the process of elimination, and you eventually end up at a good solution. That's just the one spark I found that has worked well is reframe who the customer is and who you're actually solving a problem for, as opposed to the technology being the coolest thing of all time.
Shane Hastie: Some really interesting things here. If people want to continue the conversation, where do they find you?
Tim Olshansky: I'm always happy to chat on LinkedIn or Twitter. So @timolsh on Twitter, or Tim Olshansky, I'm on LinkedIn and happy to continue the conversation there.
Shane Hastie: Thanks so much for taking the time.
Tim Olshansky: Thank you, Shane. Thanks for having me. And thanks for listening.
Mentioned
About the Guest
Tim Olshansky is an experienced Technology Executive across a range of companies from small startup to publicly traded, with a demonstrated history of working in the information technology and services industry. Skilled in people, process, technology and highly available & resilient architectures in a cloud-native world.
