This week’s guest is Jenny McClain, who leads R&D Team Enablement at Toast. Jenny’s team focuses on enabling individual teams at Toast to drive their own productivity improvements, and this conversation dives into how they tackle this problem.
Abi: Jenny, it's so great to finally have you on the show. Excited to talk with you today.
Jenny: Yes, thank you so much for having me. I've been looking forward to this one.
Abi: Well, I've been following what you and your colleagues at Toast have been doing for a while and have been so impressed. And I think one unique aspect of what you're doing is the really intentional way in which you're focused on enabling teams. So that's really what our conversation today is going to focus on. But just to get started, tell listeners what your team actually is, what it does, and how it fits into the rest of the organization as far as the DevEx focus.
Jenny: Yes, absolutely. So I work on the R&D enablement team at Toast. And so the R&D enablement team sits within our developer productivity group. So that includes both the more technical branch, which focuses on developer platform and building out a lot of our tooling around dev environment and testing and all that good stuff. And then our group is really focused on the learning aspect of enabling teams and making them more productive.
So that developer productivity group sits within our foundations org, which is also known as platform org in other groups. And that whole sphere focuses on providing those building blocks upon which the whole organization and the whole product is run.
So similar to I think a lot of the people that have been on this podcast, the enablement team got started by our now senior director who had a big passion for helping developers do their jobs more effectively and more efficiently. And so he started Enablement as a side hustle in addition to running a product development team. And then we ended up spinning that off and making a much bigger investment in that space, which is when I joined the team.
Abi: Take us a little more behind the scenes. That's really interesting what you just described. In my experience, what I've seen is that a dedicated learning enablement team such as yours, a little bit less common than the more typical product engineering aspect of developer productivity. So tell us more about that side hustle and how that transitions. What was the problem that was aiming to be solved at that time?
Jenny: Absolutely. Well, I think it started during this phase of hypergrowth for a lot of companies. And as I think we've talked about before, a couple years ago when it was all about scale, scale, scale, move really quickly, hire loads, grow, grow, grow, there was a real need to address onboarding and to take the weight and onus off of managers to constantly build onboarding plans from scratch and instead thinking, "Okay, what could we centralize here? What could we standardize? How do we reduce that cognitive load for people from the onboarding perspective?"
So they really got started and just said, "Okay, let's build out some basics around onboarding enablement. Let's build out a spreadsheet, a checklist, a get-started guide, think about what do we want to teach people when they're first coming in, and just help individuals launch really effectively in that."
So that was really the genesis of how this team got started. And then they started to think about, "Okay. Well, once we get people launched, how do we think about continuous education for individual contributors? How do we help them feel like they're not only learning to better contribute and better perform in their role, but also think about how do they want to develop professionally and then be able to really supercharge their career growth in that way?" So thinking about how do you build some real scrappy and fun programs and offerings to get that going.
Abi: So it began with onboarding, which especially during a phase of hypergrowth makes a lot of sense and has now expanded into the ongoing support and education for teams. Can you share big picture then, today, what are the main projects or work lanes that your team is focused on?
Jenny: Absolutely. So we still have a big focus on new hire success. And certainly as you get more lines of business opening up the needs become more niche and more tailored depending on what team you're going on, we still have a pretty significant arm of folks that work on new hire success and new hire experience.
And then like I said, we have some folks that focus on individual contributor and manager professional development. And so thinking about how do you upskill those strengths and that knowledge for individuals on the team.
And then when I came into the team here, my focus was really on team health and team enablement, how do we think about building and driving and improving high performing teams? And how do we scale that out across the organization? Part of that was just how do we think about defining what a high-performing team is and what are the elements of a team, and then how do we actually think about helping them grow and helping them learn as a whole unit and really make that collective greater than the sum of its parts.
And so specifically within my focus around team health and team continuous improvement, I work on things like building playbooks for managers, starting off new teams. I build out new team starter kits for a new triad to really get in there and launch and get to know each other, have the important conversations early. I do a lot of content curation and documentation on team best practices on different processes. The main idea there just being, "Hey, here's something you can take and just not have to start from scratch." Because I think that that can be one of the biggest challenges for folks.
And then a big part of what we're doing now is really just facilitating conversations between teams, allowing people to really learn from each other there, and then starting to dig into doing more custom team workshops and embedded coaching for teams that are really looking for that more white glove support.
Abi: So to recap, there's three main areas your group's focused on, new hires, personal or professional development for both ICs and managers, and then this last team health and performance piece. I think this last piece is what a lot of organizations that I speak to are still trying to figure out how to do, especially at scale and especially in a systematic way.
As you know, a few weeks ago, I had Manuel Pais, one of the authors of Team Topologies on the show, and my main question to him was, how do you actually do enabling work? And on that show he gave the analogy of an art curator, that a big part of doing enabling work is curating knowledge and curating it for the teams across the organization.
So I know that's something in particular you're focused on. So I want to take listeners, as much as possible, step by step from the beginning of what you've created, but how you started. So maybe start by, I know what you've built, what really prompted that and how did you think about conceptually even this, like where it would live, what the scope of it would be? How did you come up with the design?
Jenny: So when I first came in, my thought was, okay, we know we want teams to be able to learn from each other. We have this very vague notion of, we want to drive continuous improvement. We want to help teams get better. And that's a very wide definition. And so I remember my recruiter asked me, "How would you approach this? There are many ways to eat an elephant. How would you go about this?"
And so what I did to start was I said, "Okay, my best approach to thinking of how I improve teams is just go meet them where they're at, see what's going on in the different teams," and especially knowing that all these teams are in very different phases of their team maturity development of their product complexity. And so it was very clear that there was not going to be one way to rule them all or one process to rule them all.
So I said, "Okay. What I'm going to do, I'm going to show up here. I'm going to go talk to all the senior leaders in the organization and say, 'Hey, how are you thinking about teams?
How are you thinking about growing them? But more so and more importantly, who are your most interesting groups right now? Send me to your top one or two teams.'"
And then I spent really a lot of the first six months in my role just going and doing these two or three week embeds with all these different teams. And so I would show up to these teams, I would do one-on-ones with their engineering leader, their product manager, designer, QAs, some of the engineers, and then I would go observe all of their team ceremonies.
And then just pour over any documentation they had, whether that's roadmaps, strategic plans, operational plans, anything there. I just said, "Just throw it at me. Just lay it on me. I just want to see what you're doing." And so I thought of myself as a bit of an investigative reporter here. I didn't quite know what I was looking for yet, but I just wanted to go see what was interesting.
And so I ended up embedding with about 12 different teams over the course of the first few months. And what I would do with each team is I would do a writeup at the end and say, "Here's what I found super interesting about the way that you interact with each other about this particular process."
And then I would pull a couple of pieces and say, "Hey, this specific practice or this specific tactic that you do, I would love to document this and I would love to be able to share this more widely with people."
And sometimes that was a particular type of spreadsheet they would build, and I'd say, "Hey, I would love to templatize this." Sometimes it was a way that they ran their retros. Sometimes it was a way that they set up their meetings and what kind of questions they would ask, what agenda they would pull. Sometimes it was the way that they built an operational plan for the quarter.
Really, it was just looking for all of these different techniques and tactics. And then what we started to do was really document these and put them into templates. And then we created what we called the Team Health Toolkit.
And so the Team Health Toolkit really became this catchall library for all these different techniques and practices that I was seeing all these teams take on. And we ended up divvying the Team Health Toolkit up by what stage of team development a team was at.
So we used the Tuckman's model of forming, storming, norming, performing, and adjourning. And we kind of said, "Okay, for teams that are in this phase, these practices might be interesting. For teams that are in this phase, we would recommend doing this." And we tried to also organize it by what type of problems would a team encounter at this time, and then surface up these offerings as potential solutions to those.
Abi: The way you embedded with teams is really fascinating to me. I love your description of being an investigative reporter. For listeners who might be interested in doing this themselves, what did it mean to actually embed? I mean, I assume it was like a hybrid. Was this in person? What did you actually do? How long did you spend with each team and how did you integrate and observe?
Jenny: Well, the first thing I did was once I had chatted with leaders and had them give me a few suggestions for teams that were strong, and I specifically wanted to focus my first embed on teams that were regarded as high performing teams. We didn't necessarily have a specific set of metrics that at the time were like, these are the clear indicators of this team being great performers. So I just said, "Okay, leaders, throw me some teams that you consider high performing."
And so then I would reach out to them and say, "Hey, PM. Hey, engineering leader, your team has been suggested to me as a team that is high performing, that's doing really cool things, and that has a really good team dynamic. I would love to come observe y'all for a week or two and just see what I can learn personally for that, but then also see if there are opportunities to really showcase what you all are doing."
And I wanted to make sure to really frame it in that way because you don't want to frame yourself as a McKinsey-esque consultant coming in to be like, "I'm going to take a bunch of notes and tell you all the things that you're doing wrong." It's like, "No, no, no, this is the opposite."
I wanted to very much make it clear that I was coming in and taking a strengths-based approach with this. So saying, "You're really doing something interesting and good, and you're regarded as being really good, so I would love to hear from you."
And a lot of these teams, a lot of these folks are not naturally inclined towards self-promotion and especially teams here in Ireland, they're like, "Oh gosh, I don't want to take this as a compliment. This sounds terrible." And I was like, "No, no, no." I was like, "If you're cool with that, I would love to just come in and sit in with you."
And so would dial in remotely to most of these meetings. Again, when I was starting this, we were still at the tail end of COVID. So that was also really interesting just seeing the way that teams would create that team dynamic and have these good conversations remotely.
And so again, I would dial into all these ceremonies. I would do one-on-ones with the different team members. And then as I started to go through the couple weeks, I would also do one-on-ones to cap out the time that I spent with them. So I would usually spend about two to three weeks with them just learning, observing.
I typically would ask a lot of questions on Slack to folks, especially to the team leaders, that triad model, as I was embedding to just say, "Hey, I noticed you do this. Tell me more about that." Or, "Hey, I saw that you took this approach to story pointing your stories. What made you decide to go with that aspect?"
And also this was helpful for me in that I was learning the language and learning the vernacular of not only the company, but all the different groups, all the different lines of business. And I still frankly had a lot to learn about just various stages of the software development lifecycle and how engineering teams work.
So it was all very interesting for me, and people were incredibly knowledge-generous. They were incredibly happy to sit down and share their thoughts. And then we would wrap up this two to three week engagement with me putting together a writeup on my observations. And so that's where we tried to add value for teams as well, is in giving them that writeup, we were acting as a mirror to the team to say, "Hey, here's what I'm observing. Does this line up with how you feel you're operating as a team?"
And then a lot of teams would say, "Hey, can you tell me where you think we should be doing better? Can you tell me some good suggestions?" And usually any suggestions that I had would usually say, "Hey, well, I just got back from observing this other team and they're doing this thing that I think could help you." And so I started to do a lot of that telephone operator connecting.
Abi: It's so interesting. You touched on this at the beginning, how there couldn't be a one-size-fits-all solution because of how different teams are. But when you're on the ground like this, working directly and embedding with the teams, I think you really see how different teams across an organization are. And I think this is not intuitive necessarily to folks who are in leadership even sometimes, just this idea that the teams are so different.
I'm curious, what were some of the biggest things that surprised you as you embedded with different teams and just how much variance was there between different teams across the company?
Jenny: I think one thing that surprised me, I think when I was coming in, there was this perception of, okay, well, the difference in a team's ability to deliver comes from the mechanics of how they run their team, comes from the mechanics of their development process, or how fast they're shipping, or the logistics of it all.
And as I was embedding with these teams, I think one of the surprises that I had was like, oh, a lot of these teams, they actually have similar processes. They have similar mechanics and logistics here, but what's really shaping and I think differentiating their ability to deliver at the speed at which they operate comes from both their stage of team development as well as their product complexity.
And so I ended up developing this two by two in my head of team maturity and product maturity and placing which team ended up in which quadrant as I was working with them and really thinking about, okay, for a team that is brand new, but taking over a really complex code base, they're going to have a very different set of needs and also very different set of demands than a team that maybe has worked together before, knows the ins and outs of each other's working styles and working preferences and has now been brought together to really launch a new product.
And so that really started to shape how we thought about what type of resources we would not only want to curate, but how we would want to market them to people, just knowing that those different classifications of team would inform not only the way that they would operate, but really the demands and the complexities that they would need to navigate in order to do so.
Abi: This curation and the marketing of it, in essence, you oversee what is a product, right?
Abi: Like the learning resources. And so I'd love to dive into it more. I think this is something a lot of listeners, a lot of other leaders out there would love to aspire to build themselves. So would love to go into a little bit more of the nuts and bolts of what this is and how it's continually developed and maintain. So for starters, could you share with listeners just where this lives, how people can access it, and the sort of taxonomy or how you've organized it?
Jenny: Absolutely. So we house this currently on our internal company wiki, and we build out different pages for each new practice, each new idea that we want to be able to evangelize there. And then the way that we push it out to people is through a few different phases there.
Sometimes we'll build these playbooks that are specific to a situation, like we said, maybe it's a new team starter kit that's a playbook for how you launch a new team. Maybe it's a playbook for managers who are looking to split a team and what that looks like. Maybe it's a playbook for teams that are launching a new project.
And so then we'll curate these resources into a playbook that meets a specific moment and then work to find those trigger points for a team and be able to surface those up just in time. So one thing that we do is any new manager who starts at Toast as part of their onboarding resources, we send them the manager playbook for spinning up new teams. And so then that can really just meet them where they are in that moment.
But more so, what we started to do was we created a Slack channel called Team Health Corner where we would really just work to start conversations around that, around the topic of team health and really use that as our forum for sharing out these ideas and then starting to facilitate conversations between different peers there.
And so as I started doing these team embeds, as I started to document more of these ideas, we spun up Team Health Corner and we said, "Hey, if you're interested in this topic and you like to nerd out on processes and team development, come hang out here." And so we would start to post these different resources up there as we would build them.
And then through that we started to see more engagement where people would say, "Hey, I'm trying out this new thing. What do people think of it?" Or some people will come in and ask questions saying, "Hey, does anyone have a good resource for dependency mapping?" Or, "Does somebody have an interesting resource for this piece?" And so we really wanted that to be a little town square of sharing ideas. And so that's one way that we've really worked to try and get that content in front of people.
But I think you really have to think about how do you meet people in that moment where it's of greatest need. I think probably any learning and development team, any enablement team knows that in any given month, you're lucky if you get a 3% timeshare in people's brains. It is really challenging. And Abi, I know you and I have talked before around how do you create that type of learning culture where people feel like they can prioritize that time?
And so I think what we really try to do is try and think about, well, how do we meet people in that moment where they actually have had that appetite and that hunger for that? And so, as we've gotten more into measuring and assessing various elements of team health and having people actually select what they want to improve upon, that's actually given us a much sharper tool now to have a targeted audience for how to share these resources.
Abi: Thanks so much for the deep overview of your platform and the curation work you're doing. In terms of the actual content that you're curating, how much of it is ... Who's writing it? Is a good portion of it coming from external content you found and are curating? Or is a majority portion coming from articles and content created in-house at Toast by either yourself or ... Who's creating the content?
Jenny: Yeah, great question. So a lot of the content that we have in the Team Health Toolkit is actually based off of internal processes and practices that we've seen from people, and that's intentionally done. So again, that started through the team embeds, but then has just continued with whether it's myself or other members of the enablement team or even other leaders that say, "Hey, I spotted this interesting practice." We go and chase after it and we go document it there.
And part of the reason why we wanted to do this is that I think people sit up and pay attention a little bit more when they feel like it's coming from not only a trusted and respected peer of theirs to where they not only know that, okay, this person has delivered and I know who this person is and I know that they can do this, but also they know that that person has managed to make this work in the environment that is specific to Toast.
And that's not to say, "Oh, Toast, we're all special butterflies and what can work here, it doesn't work there." But I think that it's almost like it's been Toast vetted and Toast practiced. And so I think people, they'll sit up and pay attention to that and be really interested.
Now what we do is we say, okay, if we're talking about something that is like we have a resource that's like a kanban at Toast 101, a lot of the content in there is based off of observations and practices that we see in teams do at Toast, but then we also link out to a lot of external expertise and resources on that as well. So that way people do want to do more of a deep dive and understand the industry perspective and the industry best practices, those are there as well.
And so we do try and shape that external thing, but I think we try and grab people's attention first and foremost by saying, "Here are what your peers who are in the trenches with you are doing, and here's how they've made it work, and here's how you can too."
Abi: So primarily in-house content, supplemented by a little bit of outside resources. You mentioned again, whenever you hear of something interesting happening, you guys go chase it down and do your investigative journalism. How have you sustained that? I mean, you mentioned the community forum. I mean, how are you keeping your ears to the ground and learning of interesting things continuously?
Jenny: Yeah, it's a great question and it's something that we're still iterating and figuring out the best way to do this in a scalable way. So in the early days it was really just, "Oh, I'm going and talking with lots of leaders. They're pointing me in this direction, I'm doing that." And then we kept up the conversation enough to then when this idea pops with somebody organically, then they say, "Oh. Well, let's reach out to Jenny. Let's reach out to the enablement team. Let's get this on their radar."
One thing we're also trying to do as a team now is to actually get more embedded in the different lines of business, in the different product groups to have more boots on the ground, more eyes everywhere around who are these teams that are doing interesting things? How do we stay connected with that?
Because I think that that's one thing that a lot of enablement teams find that challenge is you get all this really rich stuff in your initial discovery work, and then you probably have a year, two years worth of roadmap just based on that, but you have to go back and make sure you're staying connected with what's happening today.
And so that's one model that we're playing with there. But I would say what has been the richest and most interesting piece for us lately to really stay connected is using our metrics program where we are looking at various elements of team health and how we're measuring that.
And so then we're able to look at these different aspects of team health and how teams are assessing themselves on that. And so then we can look and say, "Okay, well these teams are scoring really consistently high in this topic, so maybe those would be interesting teams to go chat with."
Or I think even more interesting for me is we can say, "Okay, in the past six months, this team started out here, maybe started out with a lower score, and then they've actually had a big jump in their score for this particular topic. So hey, I want to go chat with them and understand what did you do here. What made you go from this score to this score around the topic of let's say, deep work or around balancing tech debt or documentation? Was that based off of a really intentional effort? And if so, what did you do? How did you do it? Was that by accident? Was this completely circumstantial or totally coincidental and in fact, you haven't paid attention to this at all?"
But it's a good way to use team sentiment and to use this metrics program to really help us know where to place our focus and know where to go hunting for good ideas.
Abi: I think this is a really important point that your work isn't happening on an island. It's actually aligned to, and part of how Toast as an organization is trying to measure and understand and improve developer productivity, team productivity. And Toast does this, of course you know, through a combination of both quantitative and qualitative measures, developer experience surveys, metrics from systems. How do you then in your role structure your work around this measurement program?
Jenny: So as you said, we really try to make use of a developer experience survey and to really understand at a macro level, what are the issues that are plaguing developers and teams as a whole, where do they feel like they're strong? And then to actually dive in deep at the local level with those as well to understand which teams in particular are having challenges with this, which teams in particular are soaring and doing really well at some of these topics. And then which teams have raised their hand and say, "Hey, this is something that we want to actively put improvement energy towards."
And so for that middle section, for the teams that we're able to see through this metrics program are doing really well in this, that's where we want to go and ask them questions. That's where we want to go and get their ideas for how are they doing it, what are their practices, what are their techniques for having that result and these developers feeling really good about these topics?
And then we want to be able to connect those ideas with those teams that have raised their hand and said, "Hey, we want to focus on this. We want to get better at this." And so that's where we work to really build those connections with each other. And some of that is doing marketing campaigns and sending out ... We have a resource guide for a lot of the topics that we assess in the developer survey.
So let's say, okay, documentation is one of the most commonly chosen focus areas and topics for improvement for a lot of teams. And so we said, "Okay, let's build out a resource guide that is all of these different recommended actions and quick wins and industry articles around documentation." And then we send that directly to the teams that have raised their hand and said, "We want to work on documentation."
And so again, it's really just about instead of just doing the spray and pray model where you throw resources out there and hope somebody reads them, instead, just really focus on sending that to folks that are really actively trying to improve this. And then we also do a 201 level of this, which is really bringing those people together to have community conversations around this topic.
So again, continuing with the example of documentation, one thing that we've done a couple times after these developer surveys is we said, "Okay, let's bring together all the different engineering leaders whose teams have said they want to improve documentation and let's just throw them in a room and see what happens. Let's ask a couple of very basic questions at the beginning, which is like, how would you define the actual issue you're having with documentation and what are some of the ideas that you have to improve this?"
And then now that we've started to have a little bit of this flywheel going on, then we can also start to bring in teams who have previously done this improvement work and have started to see those results. And we can have those people come in and say, "Hey, so here's what we tried. Here's what we think has worked. Here's one thing that we tried that maybe didn't work so well." And just be able to provide some of that peer guidance and peer mentorship on these different topics as well.
And so I think we're still just at the very beginning phase of spinning that flywheel in terms of that community-driven enablement. That's one thing that's really the north star for us over the course of the next year is really starting to spin that flywheel on community-driven enablement.
Abi: Well, I love that. And I know you probably think of yourself as early in your journey, but I'm so impressed by how the flywheel you've already created that ties measurement and insights about developer productivity and team health to action that then ties the action to the learning content and resources that you're putting together.
And as you touched on earlier, the way you're curating and then distributing this content to folks who are raising their hands and might actually need this content, I think that's so important because, I mean, anyone who's worked in marketing knows creating the content's just half the work, actually distributing it and getting it into the hands of people is sometimes even more work than creating the content.
And you've touched on in this last part, the last tactical question I had, this idea of connecting teams to talk with each other. It sounds like you're doing this in this new, very intentional community sort of forum way. But outside of that, I mean, how have you actually connected teams to one another? I think about this. I'm like, "Oh, do you just Slack DM two managers and say, 'Hey, you two should be like ...'" How do you actually make those connections across the organization?
Jenny: We've done just that at times. The number of times where I've just said, "Hey, you two should meet." You're almost a bit of a tech industry Yente, very much a matchmaker in finding people, like you have this problem, this person might have a solution. But I think in ways that we try to do that at scale, we take a couple of different approaches here.
We have the Slack channel that is Team Health Corner. That's like we said, kind of a large town square forum. We've got about 500 people in that at this point and just chat. They'll chat away with each other. Sometimes that channel can go quiet and it's really on us to nudge people and make sure that that stays alive and that conversations are happening there. But that's been one way we've connected with people.
And then that next phase is really those community conversations and community courses. So trying to bring people together in small groups. Usually we try not to do more than 10 people at a time because once you get bigger than that, people don't necessarily feel the level of psychological safety where they can have these hard conversations because sometimes they are hard conversations. And so I think that's one space that we try to connect people with.
And then sometimes when we do these more kind of in-depth team embeds and team coaching where we'll really get in there and understand what team challenges they're having, what team needs that they have, then we say, "Hey, based on what we're seeing here, here are specific teams or specific people that we would recommend that you chat with." And sometimes we'll introduce them to each other, we'll set them up for coffee. Sometimes we'll just point them in the right direction there, and hopefully that is a conversation or a relationship that will start to take off there.
So again, I don't necessarily think there's a magic bullet of how you work to connect people. I think it's playing into lots of different forums, but I also think that allows for people to find what method of learning really works for them. Some people really like reading, some people like coffee chats, some people like podcasts. And so thinking about what's going to help them not only intake that information and that learning, but then be able to apply it there. And so I think we tinker around and experiment with different forums in that way.
Abi: Thanks so much for walking through that. I know, like you said, there's not a silver bullet or one magical way of connecting people, but I do think all the different approaches you shared will be really helpful to listeners who are looking for tactical tips.
I want to shift the conversation a little bit now to talk about your role a little bit about how you got into this role and how companies should think about this function for themselves. As we talked about at the beginning, this isn't necessarily the most common role. And so one question I have for you, when should companies in your view think about establishing this as a dedicated role or function within their organization?
Jenny: Yeah, it's a great question. I think that as the company scales, and particularly as the R&D organization scales past the point where people are no longer just they know each other and they're talking to each other and they're learning from each other by accident. And for some companies that's once R&D gets past 50 people, for some it's once it gets past 200, for some it's once it get past 500.
But once you hit that inflection point where people aren't naturally finding each other and naturally sharing those ideas, then that's an opportunity to maybe bring in somebody that can nudge those conversations along or more so, create those spaces and create those forums for those conversations to happen.
I also think that as companies grow, as they start to become multi-product, as they start to build out more platform teams or InfraEng, or as you start to have teams that start to work in very different ways and as you get to the point where you no longer have the one way of doing things but teams start to create more bespoke processes and practices, that's a really good opportunity to I think invest in enablement there because then you can start to document what all these things are.
And I think a big role that enablement plays is bringing things from being oral history and just passed down through storytelling to actually start do a lot of documentation and write things down and just bring calm to the chaos.
Abi: I love that. Well, I want to follow up by asking you how you got into this role and also in your opinion, who are the right kind of people for this role in general?
Jenny: So my path into the tech industry and into enablement was just funky and weird. So I started out in my professional career as a teacher, so shocking that I ended up in education and enablement. But I worked as a teacher and then worked for a while as a wedding planner. I worked in nonprofit event planning and then made the step into the tech industry to work as a recruiter.
And then after working in recruiting for a little while, moved into a role that was focusing on team development, leadership development, just general people development, how do we think about helping this organization be happier, be more effective, et cetera, et cetera? Again, a very nebulous role there.
And what I really found I enjoyed as my niche in there is, how do you get engineers to talk to each other? For me coming like a highly liberal arts, very colorful, very fun set of background there, I really enjoyed the fun challenge of getting in there and working with people where a lot of them, they're like, "We see things as very black and white. We are very much coming from the STEM background." And I just enjoyed that fun culture clash of figuring each other out.
And in doing so, I realized that I always thought that me not having the technical background and me not knowing the ins and outs of that, I thought that that would hamper me in the industry and specifically within enablement. But the way I really see it now and what I've told a lot of people who are looking to come into this space is like, "No, no, no, that's your superpower."
Your superpower is being able to ask really good questions and be able to understand a concept, but in its simplest form because then when you can explain that, and however you make it make sense in your head, whether it's through a framework, whether it's through just stating something very simply, then you can bring that message and bring that simplicity to others.
And then not only can they be able to absorb that and take that in, but again, you're helping reduce that cognitive load. So take these really hard concepts, simplify them, communicate them, evangelize them, and make it all make sense.
Abi: I love that. I think the last piece is really true. In my experience as an engineer myself and someone who's been in technical leadership, we overthink things and overcomplicate things all the time. And like you said, your superpower of being able to distill that into layman's terms and simple concepts, I think is definitely something that is powerful and can help get to the truth of things.
So in general, what are some of the other general skills for folks out there who might be considering pursuing a role like this or proposing moving into a role like this at their organization? What other sort of skills, day-to-day things, attributes do you feel are beneficial to have?
Jenny: Absolutely. Yeah, I think some of the key attributes for somebody coming into this role would be curiosity, first and foremost, an urge to write things down, and I think really wanting to make things run smoothly. I think working in enablement, it's so much about just asking people, what's the hardest part about your job? What are those paper cuts? What's driving you nuts right now?
And so having that drive to say, "Okay, I want to help them solve their problems and just help them breathe a little bit easier. I want to help them sleep better at night. I want to make their lives just a touch easier there." So I think having that drive is really important. And I think some of the tactical skills there, again, it's asking really good questions, and that goes back to the curiosity piece. Ask good questions, why is that? Tell me more about that. Explain that to me.
Again, this goes back to the idea of where not coming from a technical background can be a superpower because if you just keep saying, "Hey, can you explain that to me? Can you walk me through why you do it that way?" sometimes that in and of itself is the biggest value you can provide to them by asking the most basic, obvious questions.
And that really makes people sometimes sit back and think, "Well, why do I do it that way? Is there a way to do it better?" And so I think that's a big skill that can add a lot of value in this space. And then I think, again, this idea of distilling something complex into something simple, chunking that up into small digestible bites.
And then I think having a really strong marketing eye, how do you communicate this in a way that is going to be targeted, that's going to be memorable, and that's going to incite a decision or action?
Abi: Well, it sounds like being curious and asking questions is core to this role, as you've shared throughout the episode. Last question I want to ask you is around, all of us in our careers want growth in our roles, growth in our careers, and not just in your own role, but maybe other folks you've seen who are in similar roles as you at other companies, how do you see the role in your work growing? Is it more about the pursuit of the north star that we've talked about, or is their growth in other ... Again, this is for listeners who might be interested in a role like this. What's the longer term view on this path?
Jenny: Yeah, absolutely. And I think before I get into what that growth looks like, certainly for any listener that is interested in going in this field, again, I would encourage folks that who might be listening to this and think like, "Oh, maybe that's interesting, but do I have the background for this?" Listen, our team alone, our backgrounds, we have former teachers, we have bartenders, we have equestrian instructors, we have accountants, and we have engineers and former product managers. So we come from all over the place here. And so certainly, I think wherever you are currently sitting, I think if you have those skills and that interest, I think that it's a cool and fun path to get into.
And then I think for what that growth looks like, I think for a lot of us on the team, I think there's opportunities to grow into senior operational roles, chiefs of staff type roles, people team roles, people development.
As you were talking about earlier, there's a bit of a product focus within this, understanding your customer, building solutions to drive problems. And so we talk a lot about is there a foray into product management from this?And then I think a lot of people will come out of this and end up really being interested in coaching or guidance or sometimes even corporate therapy.
But when I think about the work that we want to do and what that north star looks like, I think what we're always trying to find that good balance of is delivering that iterative value while also thinking about what are these transformational ideas and problems.
And I think that that's one thing that can be hard sometimes is that you do want to have those big transformational moments. Sometimes you're charged with coming in and change the whole culture around this place, which is a whole other soapbox moment I could go to where it's like, "Eh, can any one person truly do that?"
But you do want to fundamentally shape and impact the way that that does, but you don't necessarily do that by kind of crawling in a hole for a year and developing all of these things and doing it in a very waterfall way. You start to chip away at that by doing these small, iterative quick wins there.
And so I think that that's a big piece of this as well, is having that patience to know that that transformational work happens over time, but also that urgency that you do want to deliver value and help people in the immediate as well.
Abi: Yeah, I love this idea about how you're thinking about the transformation process. It's such a buzzword of course, and it's such an audacious goal for all organizations, but you're thinking about it in an iterative way. I think that that's so important, such an important concept for listeners.
Well, Jenny, this conversation's been amazing. I'm so grateful to you for taking the time to sit down and chat with me. So many tactical, actionable insights in this conversation. I think listeners are really going to appreciate it. Thank you so much for taking the time coming on the show today.
Jenny: Absolutely. It was my pleasure. And hopefully we'll keep having more and more conversations like this.