On this episode of Labs Live, Dan and Tobi welcome Detroit Labs Delivery Lead Shannon Kubenez and Technical Program Manager Chris Trevarthen. The discussion will focus on the process of scaling a team and navigating the challenges all teams face when adding new team members to an existing software team.
Watch episodes of Labs Live and Subscribe on YouTube.
About Labs Live
Labs Live is a stream hosted by Detroit Labs’ very own Dan Ward and Tobi Adebisi, where they bring on guests from the Labs team and our clients to talk about the latest in technology, software design and development, and whatever else comes to mind. Labs Live streams live on LinkedIn and YouTube each month.
Transcript:
Dan:
Tobi.
Tobi:
Hello.
Dan:
How are you?
Tobi:
Pretty good, must be getting to the cold season now. So adjusting from Summer vibes to October feels.
Dan:
Well, October feels, okay. I was going to say, what would you like vibes turn into what feels?
Tobi:
Because you can’t go out as much. So it’s mostly indoor stuff or stuff that you could stay outside a little bit. It’s not the same as just, Summer vibes is just a whole mood on its own.
Dan:
Yeah, we got a lot of leaves falling right now over here in a blow up dragon that’s supposed to be on the front line, but it has been moved up to right outside my window, which could be fun to blow up at some point we’ll see. I do appreciate Tobi, your crew is already full into our comments.
Tobi:
They’re are all here.
Dan:
They are always here and always appreciate it. All right. Welcome to Labs Live. This is exciting one, right Tobi?
Tobi:
Yeah, this is, I’m super excited about this one, because even beyond work in general, just scaling a team, growing a product and all that stuff is something that I’m passionate about even outside of work. So excited to talk to Shannon and Chris, this is good.
Dan:
I mean, as a former developer, I mean maybe current, but former project developer, right? You live through scaling.
Tobi:
Oh yeah. Multiple times we’ve been on very large automotive projects that have deadlines and the way you have to scale and sometimes even reduce size scale again. So I’ve been through several scaling efforts. I’ve seen some that went really well, I’ve seen some that didn’t go really well. And Shannon and Chris basically they’ve walked the walk when it comes to doing this stuff so, I’m curious to see what their thoughts are in doing that today.
Dan:
Very much agree. Okay. So before we get into it and make sure if you’re on our social channels, follow us, like us I don’t know, bell icon, all those different things to get notified when we upload content we’re constantly pushing out content. And so you want to be there for that. Labs Live is something we do once a month as a LinkedIn event. And we’re happy to have you here. Daniel Caspo says you’re always a developer to him Tobi.
Tobi:
I love you Dan.
Dan:
That’s fantastic. All right, let’s move along as Tobi mentioned today, we’re talking about scaling a team. The why, the when, the how? It’s something that I think oftentimes is inevitable. If you’ve got a really great high functioning team, there’s a desire for it to grow and so we’re going to be talking with Chris and Shannon about how to make that work. So without further ado, let’s bring in Shannon Kubenez, she’s a Delivery Lead at Detroit Labs. And I think I’m going to let her explain what a delivery lead does because I think for a lot of people that might be a new term. So Shannon welcome. How are you?
Shannon:
Good how are you?
Dan:
Fantastic, Tobi has moved into Fall feels instead of Summer vibes.
Shannon:
Team Summer over here.
Dan:
So Shannon, tell us all about a delivery lead what your role is, what they do?
Shannon:
Sure. It’s a pretty unique role. We have delivery leads and that project managers at Detroit Labs. A delivery lead is an agile coach, they wear many hats, so agile coach really a support team member to the entire development team. So to our QAs or QEs design development. We’re helping to support all of our team members from various parts of the project life cycle, from ideation, to designs, to development all the way through to shipping a product. So we are keeping on, we’re keeping of risks and mitigating risks. We’re helping to break down work. We’re keeping an eye on our progress and tracking towards our deliverable date. A whole bunch of stuff wrapped into one role.
Dan:
Just a few things, right? Just a couple things do you have on top of, It’s no big deal.
Shannon:
No big deal.
Dan:
All right, fantastic. Also let’s introduce Chris Trevarthen, Technical Program Manager. You happen to both be on a same project, so you get to both work closely together, but Chris welcome.
Chris:
Thank you.
Dan:
Tell us all about technical program managers.
Chris:
Technical program manager. That’s kind of a role that is newer to Detroit Labs. It’s something we didn’t have until the particular project Shannon and I are on. We needed to scale. We had, I think at the time three different projects that were going on all for the same client, but there was a lot of communication that needed to be done across the projects. Because it wasn’t how we typically would do a project where you might have an Android app and an iOS app that the same thing they’re just being developed on different platforms.
Chris:
This was completely different, but from the same sort of workflow. So it was something that we had to, we needed to be able to keep track of how technology decisions were being made, how they were being communicated across teams. And so I stepped into that role to basically sort of play an architect but also work with delivery leads on making sure that they communicate, that we had our workflow set up correctly, that we were organizing releases of that sort of thing. So very much working hand in hand with Shannon on this.
Dan:
Fantastic. Okay. So let’s dive into this. I mentioned something as we were describing Scale, I mentioned high functioning team and I think that’s probably a great place to start at least give us a baseline. What does high functioning team mean?
Chris:
Well, I think it’s interesting that you used the term high functioning because I don’t see that as the same thing as a high performing team. Because I think you can have a team that ships stuff quickly. They’re getting a lot of stuff done, but they’re not functioning well as a team. So when I think of high functioning team. It’s not necessarily about the throughput. It’s more about how does that team work together? So having, for me one of the main things is having a clear, shared purpose on that team.
Shannon:
Yeah. And another thing I think about is trust. We have trust and safety on a high functioning team. We are committed, we’re supporting one another. And it’s not just about, I trust you to do the work, but I trust that when I fail or when I fall, you’ve got my back.
Dan:
I like that. So if you’ve reached high functioning status, if you will which obviously is great communication, great trust. So it’s a very good foundation rock solid team. Why on earth would you want to scale from there?
Chris:
I think that’s a great question because yeah, I mean, we’ll probably you don’t always get advantages from that, but the advantages aren’t always apparent, but you might want to scale because expectations increase. So if you are adding a whole new piece of a project, say you’re adding maybe a new platform or you’re doing a new workflow or you’re just basically expanding the amount of work you need to do. Then you might want to scale because of that, because it’s just over capacity for what the team currently can put forth.
Shannon:
Or if you’re adding a whole nother platform. So we started off on a lab project, we needed to build an iOS app. So the skillset of the team needed to change. So we needed to scale to meet the need of the new product we needed to build.
Dan:
Go ahead Chris.
Chris:
Oh, I was just going to say yeah. And then along with the workload, team burnout as you get more workload, team burnout it’s real. So scaling to help lower that kind of, that bar for everybody or that pressure level for everybody on the team that can definitely be a reason you might want to scale.
Dan:
So I think we covered a couple of the things here. But I think oftentimes scaling is, we equate that to speed, more capacity, faster velocity. But you do touch on one of the other reasons which is burnout. Are there any other reasons that you would want to scale beyond just expectations increasing in the need for speed Tobi, it’s a video game.
Tobi:
Great game. I think I played it in high school.
Dan:
Yeah, well very right.
Shannon:
I think actually right now is a great time to scale. We’re all still working in this environment where there’s a pandemic happening. And even though we’re remote and we’re learning to adjust to that, it’s still underneath everything that we’re doing. And so right now, just given the circumstances that we’re living in right now is a good time to scale. If you can invest in your people and you have the room to do that, I think that enough is a reason to scale if you can.
Chris:
Yeah. And I think I’m talking about investing in people, having a larger team scale as you grow your team, there’s going to be a need for leaders, right? There’s going to be need for people to step up and take on additional responsibilities. Or if we have different skill sets that are needed, you’re going to have people that you’re going to give an opportunity to people. So scaling a team, one of the great advantages is you get to encourage that sort of on the team and get people who can grow in their careers.
Tobi:
Yeah. And how do you do that? I think that’s like a really great point of just having people grow into new positions, maybe team lead and stuff like that or people who manage the CI/CD pipeline, how do you create a team that when it scales those opportunities are taken?
Shannon:
I think sometimes that could happen organically. Now we’re bigger, this need is bubbling up. Maybe in the beginning when you’re about to scale, you don’t really recognize it yet, but along the way, an opportunity arises and an opening presents itself to people to actually naturally and organically step into a leadership role.
Dan:
Do you find yourselves encouraging that? And I mean do you see the team naturally doing? You mentioned it kind of happens organically, but do you find a part of your role is to also encourage that to take place?
Chris:
Absolutely yeah, I think that’s a good point. It’s being able to see that which is one of the great things about the role that I have, where I can see staff across multiple projects within this particular team. And so I can see where there are people who are, who sort of have that that eagerness or that inkling to step up into something like Tobi said, the CICD pipeline, somebody starts being interested in that. It’s like, okay, well, let’s start inviting you to those meetings. Let’s start having you take on some of these responsibilities and have and for instance, me take a step back from that. So that’s always awesome.
Dan:
All right. Awesome. Now I think oftentimes when it comes to scaling, there are myths that come with that. I have a couple here, obviously they don’t want to talk about so when you do scale, when that times come, you say, “Okay, we’re going to committed to do this.” Does that make you instantly faster?
Chris:
Oh, absolutely. Every time you’re just done problem solving. No, no, I think that’s a great myth to call out because yeah, you don’t immediately get benefits from adding more people to a project. You’ve got there’s onboarding. You have to get people either, if they’re brand new to say the company or to work with that particular client, there’s some culture that you need to kind of basically give the background on. And then there’s the technology stack. Whatever you’re working on, if you’re talking about developers or QEs or something like that, you might need to get people familiar with the tools. So I think that that scaling is not automatically going to get you that speed.
Tobi:
So when you talk about getting people familiar with tools, I don’t know if, I’m asking this question more like high level. So you have a generic team that is not necessarily one technology. What are some things that you think are high level enough that was good when you’re onboarding people to this new high functioning team?
Chris:
I think for some high level things like for instance I mean, if we’re not even talking about technology is what’s the relationship with the client like? How do you or what’s the relationship amongst the team, if it’s your own team that you’re scaling, what are the roles, what are the responsibilities? But then from the technology point of view I think, just sort of going into high level, like here’s all the pieces of that. So there’s the people, how the people interact, but then there’s how do the pieces of the application or the architecture interact? And giving someone that sort of that really high level view of here’s all the pieces, here’s how it goes together. And making that clear, I think is really important.
Shannon:
Yeah. I think that there’s some different levels. There’s one onboarding as it relates to coming on to a new company. And so there’s the onboarding, not even related to the project or anything, just the company and what to expect from that. And then there’s the part of onboarding to a greater team and what that looks like. I think about what does somebody need to know? What are the pieces, the dynamics the key players, the stakeholders, our relationship? Some of the dynamics that Chris talked about, and then before you even get into the technology piece, okay now I have to onboard you onto your individual team. That’s part of this bigger team. So there’s three different levels.
Tobi:
That’s awesome.
Dan:
So I was going to bring up one of the myths on here that I wanted to ask about, because I have found myself taking this approach probably all too often. And Shannon you’ve probably corrected me a couple of times, but is it just adding people or at the end of the day, I mean, are you changing complete dynamics within a team?
Shannon:
I mean, I think you are changing complete dynamics on a team. I’ve been on teams that had as little as five people, and the dynamic is completely different. How we communicate with one another, how we problem solve, how we implement solutions is different. There’s a lot more autonomy there. When you’re on a bigger team, the dynamics are totally different. There’s so many communications, streams and tools. And so it kind of you have to change how do we send out information or how do we provide information? A lot of time spent doing that. On a smaller team, we didn’t need to have a weekly update to keep you updated on what has changed over the past week. Now at a large team with a lot of moving pieces, we have to do that just to keep everyone on the same page. So the dynamics are completely different on a larger team versus a smaller one.
Dan:
And I have one add one more myth here before we move on, because we kind of introduced it earlier in the conversation. But when you add, so let’s say you have a team of 10, and let’s say you double that to a team of 20, right? Does that immediately mean burnout is gone or is there work that needs to be taken into account to actually manage that in order for burnout to not disappear, but be able to move it a little bit, right?
Chris:
Yeah. I don’t think it goes away immediately. I mean, because I think workload is only one source of burnout. There’s a lot of factors that go into it. Like having a clear goal, having, actually believing in what you’re building, that sort of thing. So I don’t think that just adding people will do it. It takes away some pressure eventually that pressure of having to be sort of like having all that weight on one particular team or one small group of developers. Now you can share that way. But I think there are, I mean, like Shannon talked about communication there, and keeping up with people on the team to see how they’re doing. That’s really important as you scale the team to see how the team is feeling and checking in with them.
Tobi:
So who kind of does that, is that what you do, is that what the delivery lead does? Is that what the whole team does? How is that check-in who kind of owns that?
Shannon:
Yeah, I think on a smaller, even on these individual teams, the delivery lead is a checkpoint for that. I think as the team grows, it’s hard not to think and care about every single person on the team, even if I’m not working directly with them. I think it becomes a shared responsibility too. And I think that the developers and the other roles also have to look out for one another. And we see that all the time. There’s lots of support across all of the roles to keep in and touch, connect with one another, check in with one another.
Dan:
All right. So we talked about the why you should scale, right? And we obviously touched on some of the myths because I’ve always found myself being one of those people that probably instantly thought things would be faster and instantly thought that it was just adding people and that would be just fine. So I think it’s good to highlight and address those, but knowing that now we do want to scale and knowing that those myths exist, how do you start to set expectations both with team and then with either a client or stakeholder?
Chris:
Yeah, I think first of all, it comes with setting expectation of timelines. So when are we doing hiring, when are we doing interviewing that sort of plan around that? Because those all take a lot of time to do so you, can’t just one part of I guess the myth of scaling that we kind of didn’t even hit on was that you can scale immediately, right? You might not have the folks to do that. So making that plan clear to stakeholders and then the follow up to that is making sure that they understand that there is an onboarding plan and there’s an onboarding process. And the more open you can be about that I think the better understanding is, and maybe can help dispel that myth a little bit of that you’re instantly going to get benefit.
Dan:
So one of the things that keeps coming up right? Is communication. How important is it to be transparent with the team talking to the team about, okay, these are why, here are the reasons, here are your expectations almost unfiltered from a stakeholder, from a client how important is transparency in this process?
Shannon:
I think it’s huge. You have to give information to the team on what’s happening and why it needs to happen. And because they’re going to be impacted by it, and they’re going to play a role in it too. So being open and honest and transparent on the why and when, and what it looks like, what does it mean? What are the plans around it? Are the better off it’s going to be, more successful it’s going to be.
Chris:
Yeah, I think it goes back to that concept of the shared purpose. If there’s at least an understanding of why is this happening, why is this scaling needed? I think people can buy into it a little bit more than just being told to do that we’re increasing the team size.
Dan:
So obviously if you’re increasing team sizes, there’s essentially two ways to do it either you’re moving people within a group from one team to another or what is more likely the case you’re hiring? How do you manage those two work streams, right? You have to do the hiring and the scaling almost at the exact same time.
Chris:
I will say it’s not easy, I will just have to admit that yeah, for the interview process as we’ve tried to scale some of the team that we’re on, we had to figure out ways to, how do you interview during a pandemic when everything’s remote? How do you get people through the process quickly? So how are we able to interview maybe multiple people at the same time? Things like that, I think that takes time for the team too, because the team is working on as is involved in the interviews as they want to be in the interviews. So that that balanced with now, yeah, we’re trying to figure out you know, who, from what team can go where, and so there is a lot of coordination amongst so my role and the delivery leads trying to figure out where, what makes sense, where it from do we, where can we get people?
Shannon:
And I think the OnSite team was a huge part of that in their help. And they brainstorm like a new process to try to get people through the interview process quicker. I think there was already an episode labs about that. But I think that was really key too. There were other, we had support outside of our team to help us with the hiring.
Dan:
Yeah. You mentioned this so we have just for anyone tuning in we have a very large team that Shannon and Chris happened to be on that was and need to scale quite quickly. And with that became the need to both hire and scale at the same time. So you just lived through this and I should say, not lived, you’re still living through this and certainly not an easy thing to do. But having a partner in it as Shannon mentioned with with our OnSite team, having a partner is certainly a big help in that. So all right, we’ve got folks, we’ve got a need, we’ve got folks somehow you’ve been able to divide your time up and also interviewed folks and bring them in onboarding. What are some of the top things that you need to take into consideration or top things to do in order to successfully onboard someone to your project?
Chris:
I think a checklist having a list of boom, here’s all the things that somebody needs to have access to or some information that they need to be aware of. Here’s the different systems that then you log ins to having that and having something that’s a repeatable process, I think is really key.
Shannon:
Yeah. We were lucky that we had a bunch of people coming to the project all at once. So we could do some group onboarding together. So we had the documentation and checklists, but also just bringing people together and welcoming them to the team and to the project and just, it made it more efficient to be able to just do a group of people unlike bring them all together and give them some insight.
Dan:
It’s interesting you mentioned, what’s that Tobs?
Tobi:
Now I was just asking do you gain when you do group together besides efficiency and stuff, have you noticed anything else that you gained from doing group onboarding/doing it one-on-one?
Shannon:
I mean, you answer one question the same, you only have to answer a question one time instead of like 10 different times, so you can yeah. And they’re learning from each other, two people are learning from each other. They are at the same stage. So I think it builds comradery there with a new group of people.
Dan:
I got to say, I don’t think I would have thought of it that way. I think I would have assumed that bringing somebody on one by one would be the easiest way, but I guess that’s a really good point if everyone’s coming on at the same time, it’s one conversation and you have a support group right there built in.
Chris:
Yeah. And it’s not if you have a question, probably someone else has that same question. So that’s based exactly what Shannon said about building that comradery.
Dan:
I love checklists. I’ve spent a lot of time being told to do a checklist through my early career. Oftentimes not doing them, but realizing that I need them. So I think that’s fantastic. It seems so simple, but it does work. What should you avoid?
Shannon:
I have to try to avoid having a perfect plan because it will never be perfect and there will always be improvements to it. That’s one thing I would avoid.
Chris:
Yeah. And I think I’m just relying too much on documentation, just saying here’s the manual, read it. And you’re onboarded, there you go. I think there needs to be a much more personal touch.
Dan:
So I’m going to jump into something here in a minute. And before I do for anyone tuning in, if you do have questions, we’re reading the comments. So Chris and Shannon have offered to graciously answer every single question that you have, and if they can, they’ll be able to jump in and do it. But by all means if you have questions, throw them into the chat, we’ll bring them up on screen as we continue to move through this. So I want to talk about as you bring people on and you onboard. There’s something that Shannon, you taught me a while ago. And I think it’s interesting because every time you bring it up, I feel like it warrants explanation of conversation and people walk away with a really different perspective of team. Team agreements, tell me about team agreements, what they are, why you have them, what that process looks like of going through that?
Shannon:
Sure. Yeah. A team agreement is, I mean, it sounds pretty similar. Team agreement is a written document. Usually we’ll do it at the start of a project where when a team is coming together to just outline how are we going to work together? We know we have this goal. We’re trying to accomplish X for our stakeholders. How are we going to do it? And so we can have an open and honest conversation about how we want to work together. And we put it down in a Google Doc, and it’s a living document though. So any time a new team member joins the team, we should revisit the document and make updates to it or tweaks to it. Or we should evaluate if something isn’t working, let’s change it up. So it’s a living document that should be revisited, but it will outline the tools that we’re going to use a moment when we’re working core hours, what are our cadence meetings are going to be, how are we going to communicate a lot of like interpersonal stuff too.
Shannon:
Like how do we create a safe environment to work in, how do like a commitment to giving each other feedback? That’s really, really hard, but it’s one thing at labs that we try to do is just open and honest communication and open to feedback. So how are we going to give each other feedback and maybe a little bit about what are your personal goals that you hope to accomplish on this project? So it is a living document, super important. I would encourage everyone to create one, if you’re on a team it just gives you kind of the rules or rules or structure in which you’re agreeing to work in.
Tobi:
So what does this kind of document live? Sorry Chris.
Chris:
Yeah, the document lives. So typically we’ll have it in a shared location that the entire team can get to something like a Google Drive or a SharePoint or something, it depends on the team, the tools that the teams use, but yeah, it’s somewhere where everybody can access it.
Dan:
So, correct me if I’m wrong here. So I’m on the team. Let’s do a hypothetical situation here. I’m on the team. I communicate to you how I work best, correct? Okay, these are, I do best in a Slack or I do best in email or is that one of those things where that’s a part of it, but the team agrees that okay, you may be really good at communication through email, but we really need to keep things in Slack. And so that’s great that you have some personal preference but as a team, we’ve all agreed that Slack is where the main communication happens. Am I getting that correct?
Shannon:
Yeah. I think that on every team you have to make some compromise. It can’t always be what one person wants, but all right, you like email better, but what I always go back to what is good for the project, client or team? Or what’s good for the project stakeholder team? And how do we make decisions based on those three things? So it’s less about my personal preference and more about what helps the team do the work they need to do? What’s going to make the project successful and what’s going to help support our stakeholders?
Chris:
I think one thing that Shannon did call out though, was what are your goals for the project? So yeah, Dan it’s the team agreements is sort of like a rule set at its basis for how the team’s going to operate. But I think that I like that idea of what is the team. It’s not just rules, it’s more like, what does the team want to get out of this? What do individual people want? What is their goal for how this can help them individually, how this can help the team by working on this project? And it gets back to that point of the shared trust, right? So by putting yourself out there and saying, okay, this is what I want out of this. We can, you put yourself out there and you say, okay, that’s it, help me get to this point team.
Dan:
So we do have two questions that came in through the comments I want to pull up. So Christina, Tobi crew wants to know what aspects of being a people first company carry over well or are reflected in the onboarding process?
Chris:
I mean, I would say that kind of what Shannon talked about, about having onboarding as maybe a group onboarding. So thinking about the onboarding process from how does it benefit the person who’s coming on? Not just how does that benefit the team that they’re coming on to that they’re an additional person who can help out, but more like, what is the experience like for that person? So we do a lot of thinking about that when we go through, come through documentation and stuff like that, like is this makes sense to someone who’s brand new to this? So I think that coming from the perspective of what does it look like from a new person? I think that kind of shows that people first approach.
Shannon:
I also think if you think about it as what does somebody need to be successful on this project? You’re putting that person first. Not oh, what is the? Like I think Chris, you were saying now with, what does a project need, but what does somebody need from us to be successful on this team?
Dan:
I think engaged people, right? End up making great team members, which ends up making a great team, ultimately leading to a successful project and successful delivery. So certainly starting with the person I think is fantastic. Diana asked a question, which I think is really great. If there’s a client that is considering scaling a team but feels something’s holding them back from going all in. What would you say to them just to kinda alleviate some of that early fear?
Shannon:
What’s holding you back is probably what I would say. I’d want to dig into that a little bit more.
Dan:
Yeah, that certainly does seem like it is right for a follow up question. I think oftentimes people just don’t know where to start and I think when it comes to scaling and when it comes to higher expectations, I think oftentimes we just want to go faster. We just want to get to, we want to finish the race quicker. We want to get to the end faster. And oftentimes that leads, but that’s often puts blockers on too, where do I start, where do I go from here?All right. Now let’s say you’ve done everything wonderfully. You have a team that’s gone from 10 to 20 to 40 to 100, let’s say, hypothetical. Are you done, does this, you’ve scaled up, your high functioning now, the work is done team just kind of goes along or is there ongoing work?
Chris:
Oh, there’s definitely ongoing work. First I would love to live in that scenario that you just talked about-
Dan:
That utopia went really well.
Chris:
Yeah, I mean, there’s like with anything there’s the team needs care and maintenance, so and that comes from checking those check-ins that Shannon mentioned with, between people on the team. We do retrospectives on the team across the entire, the whole team. So we get everybody’s perspective, not just one particular project at a time.
Chris:
We want to make sure that people on the team are feeling that they have the ability to grow. So once again, looking at those opportunities for people who are stepping up or opportunities for people to grow or putting opportunities out there where people can can say, “Yes, I’m interested in that.” That’s going to keep people happy I think feel fulfilled and keep retention on the team.
Tobi:
Yeah, you did mentioned retrospectives. And I think it’s not very, it’s not as common as I thought it would be because when I’m in regular life just having a conversation I’m like, oh, we did a retro, I’m like what is that retro, so what is the retro Chris?
Chris:
Well, a retrospective is sort of a look back at some past event or past timeline to see how things went. So at the very simplest, it can be broken down to what went well, what didn’t go well, and what do you want to change? So that you can, it’s part of like a constant improvement process, right? So if you’re not talking about it, if you’re not bringing things up, you don’t know what you should keep doing, and you don’t know maybe what you should stop doing or what you need to actually change to do better.
Tobi:
That sounds right.
Shannon:
I think on the same note of, okay, you have this large team now, what is it just smooth sailing? Is it just project as usual, project work as usual? You have to kind of check in even outside of the retro process to kind of evaluate what is working and what isn’t working, how are we structured? How do we need to change? How do we need to change communication, continuously looking at it and thinking about what improvements we need to make, even outside of a retro where you’re bringing everyone together. I think you continuously have to do that.
Dan:
So I’ve got to ask on the retro side and in lines with keeping communication, open fluid, and often what does that mean now that I kinda don’t like asking these questions anymore. Now that we’re all remote. What does that mean? Or now that we’re in the middle of that? What does that mean? But it’s real. So as your team grows and there is a need for more intentional communication and there’s a need for maybe more frequent and honest and open retros, how does that happen without being face to face, without, with the computer screen between us?
Chris:
Yeah, it does not happen easily. It isn’t and it does still does not feel natural. But I think there’s, so when we talk about these retrospectives, like there’s big, those are big events, those are something we do every sprint. So every two weeks we’ll have each individual team will have its own retrospective. So but between then, we’ve got, I know the delivery leads do check ins with their, they schedule time to check in one-on-one with people on their team. They check in with stakeholders on the client side, see how are things going? And then things come up as if we have communications issues or something along those lines, we’re starting to see things we might call an impromptu meeting. We might say you know what, let’s if you’re available tomorrow, let’s take 15 minutes and just talk about this. And see where people are at. So it is real. It really has to be intentional. It just does not flow, but yeah, it’s really important.
Shannon:
Sometimes I’ll just think I haven’t talked to X person in a long time. I’m going to just check in with them a quick Slack message or something just to, because I’m working with less and less of the greater team. So I just try to check in when I can, when they come to mind, but I probably need to be more intentional about it too.
Dan:
I like that because I feel like it’s easier and easier now that especially with the team grows, but without being face to face, it’s easier to kind of pull back and disappear a little bit, not necessarily from a work standpoint, but from a social standpoint. And being intentional about that communication is certainly seems key. And Shannon, you hit on a great thing we can all do better at that. I’m always finding that I need to check in with people more, Tobi doesn’t need me check in with them, but.
Tobi:
Yeah, we do. I think we do a great job, on our own just checking in and Slack and text and all of that. So that’s good.
Dan:
All right. So we’re going to kind of wrap up here. I always like if possible to leave folks with, I don’t know, maybe a small piece of advice whether it be on scaling or whether it be on having great teams working together or communication. I don’t know who wants to go first, but if you want to give a small piece of advice or an hour long, it doesn’t matter. We can run through it. It’s fine.
Tobi:
Shannon.
Shannon:
I think that if you’re looking to scale, figuring out the why is huge, figuring out the how, the onboarding and what kinds of things can you put together and plan for when you’re scaling but not worrying about everything being perfect. Even our onboarding documentation, we’re continuously updating it. I’ll say when we have someone join the team, it may not be perfect. You may see things that we’ve missed. So feedback is welcome, and it’s just like an on, has to be an ongoing process of improvement, getting feedback on it. And so I would, I guess that’s a lot of tips for someone, but to figure out why you want to scale and what’s holding you back and some steps you can take to move in that direction.
Dan:
Awesome. Chris, do you have any parting wisdom for folks?
Chris:
Yeah. I mean, I think it’s weird to say this as part of a business, but leading with heart, right? Like doing these things out of, always keeping in mind empathy, right? Why, how does this affect the team? How does this affect a new team members? Empathy with a client or with a stakeholder as well as there’s a there’s pain points there. So trying to keep things on that level, especially as we’re disconnected as we are now, trying to try to keep it back to that human element even in business, I think that’s where I try to lead from.
Shannon:
What he said. I’d like to change my answer to it.
Dan:
It’s interesting you say even in business, I honestly, I think that’s the most important time to realize that at the end of the day, we’re all humans, we’re all doing a job, but it’s just that right? I talk with folks all the time. It’s just putting things into perspective, right? You’re dealing with another human being, they have feelings, you have feelings. Being empathetic to those, to another person’s feelings I think is paramount when it comes to team makeup and yeah. At the end of the day, everything’s just a project, it’s just a job, right? So I think that’s a great way to look at it. All right. Tobi, any other words for Chris and Shannon before I let them go?
Tobi:
Yeah. Just thank you so I really just appreciate it when just the last words of wisdom you just shared, like with Shannon I think that’s one thing I personally, as a human being always struggle with you want to make it perfect. And just even just coming to terms with like, it’s not going to be perfect. And with Chris saying leading with heart, I just feel like both path in like, if that is what I take away from this conversation we’ve had for the five to 45 minutes, that it in itself is a whole life lesson. So thank you both for taking the time to share your wisdom. I appreciate you very much.
Chris:
Thank you.
Dan:
Chris, Shannon I’m going to move you a backstage. You can hang out there until we’re done with the stream. We’ll talk after. Thank you so much for taking the time, talking to us today, talking about how to scale. The people element, setting expectations. We appreciate your time.
Shannon:
Thank you.
Chris:
Thanks for having us.
Dan:
Tobi, that was fantastic. Wasn’t it?
Tobi:
That was it hits all the good parts. It’s like, you’re talking about scaling, but then ultimately it just comes back to, you’re just working with people. And this is not a plug for labs, but this is one of the things I love the most. This is business is ultimately about people, about relationships and empathy and all those things. And that is more important than anything else. And yeah, it just gave me the feels. It was really good.
Dan:
We always talk about being a people first company. And certainly when the first pass at that is our team members, but it’s bigger than that because we’re working with clients, we’re working with stakeholders, there’s a human connection. There’s a human element there right? They have expectations that they need to deliver to. And it’s important to show empathy with them as well right? We all have bosses somewhere, right?
Tobi:
Yeah.
Dan:
And so there’s always expectations somewhere. Sometimes they’re realistic, sometimes they’re not. And I think just taking into consideration that everyone is playing a role, but at the end of the day they’re people. We’re a people first company, because we want to show empathy for one another, both from our team members, our clients, stakeholders. And I really think that is a great thing that anybody in business can do. I like that Chris said, even in business. And I think that it’s like maybe the most important place to do it is in business. So that was fantastic. Again, thank you to Shannon and Chris talking about scaling, the why, the when, the how?
Dan:
What are the things to do and whether things to avoid? I think it was fantastic. Don’t forget to go to our social channels. This will be available afterwards. You also see snippets throughout the next coming weeks. I don’t know. We have another episode scheduled in November at some, I don’t know the date off the top of my head Tobi, which I really should get better at that. But I do believe we’re going to be talking about apprenticeships.
Tobi:
So nice.
Dan:
Fantastic. I think November is apprenticeship month or there’s a week or something along those lines. So we’re going to be talking about those, which are going to be great. So you’re going to want to bookmark us. It’s not even bookmark us it’s like follow and-
Tobi:
Follow, bookmark.
Dan:
Did I show my age there Tobi?
Tobi:
A little bit.
Dan:
That’s it from Lab Live. Thanks everybody.
Tobi:
Thanks for tuning in.
Dan:
And we’ll talk to you later, bye.
Tobi:
Bye.