On June 18, Ben Wilson, Engineering Manager at InVision, spoke at LaunchDarkly's Test in Production Twitch Stream. His talk focused on "Speeding Up the Enterprise" through the lens of virtual squads, an approach taken at InVision.
Ben explained the process of how, when, and why a virtual squad may be your best bet to speed up decision-making and time-to-release across your engineering, product, and design organizations.
Watch Ben's full talk below. Attend our next Test in Production event.
FULL TRANSCRIPT:
Yoz Grahame:
Hello, internet! Thank you for joining us today. My name is Yoz Grahame. I am a Developer Advocate at LaunchDarkly, and welcome to Test in Production. Today is June the 18th, 2020. Our guest today is Ben Wilson, Engineering Manager at InVision, who is joining us today from Brooklyn.
Ben Wilson:
Hello.
Yoz Grahame:
Hello. Thank you for joining us.
Ben Wilson:
Ah, thank you for having me.
Yoz Grahame:
And you're going to be talking to us about virtual squads, using virtual squads to accelerate projects in large organizations. [crosstalk 00:00:40]
Ben Wilson:
Yes, indeed. Yeah.
Yoz Grahame:
Cool.
Ben Wilson:
A topic very near and dear to my heart. As an engineering manager, we're always looking for ways to improve upon our speed and velocity and get meaningful impact to customers quickly.
Yoz Grahame:
Cool. That's always going to be useful, especially in large organizations, that have terrible trouble with this sort of thing. And before we get started, I know you've been keeping busy during quarantine with some arts and crafts.
Ben Wilson:
Oh, yeah. I've got my embroidery machine behind me there. We have a Cricut maker in the other room. I'm a big fan of using the plotter to cut things. I make my own bootleg stickers for InVision, for instance, and send them out to new team members. I also like working with paper craft. Just recently made this box, here.
Yoz Grahame:
That's fabulous.
Ben Wilson:
Yeah! So, you can see that.
Yoz Grahame:
Well, we will go into that more later in the session, I think, because having just learned about Cricut makers, I'm incredibly interested.
Ben Wilson:
They're the best.
Yoz Grahame:
Mm. So, you're going to talk for 15 minutes, also, on virtual squads. We will be taking questions and answering questions. If you are watching, please post your questions in the Twitch Chat Stream, and we will be going until shortly before... For the next almost an hour, until 11AM Pacific, 2PM Eastern, which is where you are, and I think we might even have some viewers in Britain at the moment.
Ben Wilson:
Excellent.
Yoz Grahame:
So, take it away, Ben.
Ben Wilson:
Great. Yeah. For anyone just joining, I'll just reintroduce myself real quick. I am Benjamin Wilson, Engineering Manager at InVision, and my talk today is going to focus on startup speed in the enterprise. We're going to cover the need for speed, so timely projects with clear business cases, how to line with your high level company goals. We're going to talk about virtual squads as a possible tactic to accelerate your delivery, and then we're going to dive into a recent example that I had assembling and running such a team.
So, you might have had this experience. You're at a large company, and you lament that you're moving so slow. When you're building enterprise-grade software with best practices and complaints top of mind, your org will tend to grow quite big requiring more layers of coordination and process along the way. That's going to make you move at a slower pace, which isn't even a bad thing, right? Generally, that means that you're hardening your product, that you're going to make it available in new markets or new languages, and that you're going to scale to millions of users, but occasionally, an opportunity presents itself, and you need to act now and move fast in order to capitalize on it.
So, let's say, when those instances occur that you don't have a team that can really accomplish the goal with the way you're currently structured, and you need to move quick, maybe create your own lane to cut through some red tape and seize on the opportunity. The method that we use at InVision is called Virtual Squads, but before I get into the virtual squads, I think it's worth touching on a few other cross squad collaboration methods.
Often times, all you really need to do it open a pull request against another team's repo, do the work for them, have them review it and deploy it on your behalf, and you're done. That's your cross-team collaboration, but there are those occasions where you need to work with two or more teams, and as long as there isn't a ton of overlap in the work, you might be best served by having shared OKRs that you agree to. It's only really when you have this weird jigsaw that cuts through multiple teams, or you're doing something like Net New that you'd reach for the virtual squad option.
Just to explain a little better what I mean by virtual squad, I'm talking about a temporary cross-team squad exempt from organizational constructs to deliver against a specific outcome. To break that down, why temporary? Well, you're borrowing folks from other teams and parts of the business, and both they and their managers would like to know when they're going to be coming back. Also, by making it temporary, it's easier to get buy-in from leadership. This is finite, and we're going to have an exit strategy.
Exempt from organizational constructs. So, you need the right people to achieve your outcome, and this is an area where you really don't want to compromise. So, pushing here leads to the further discussion in weighing this opportunity against other bets the business is making. That's a good thing. Also, try not to box yourself in with titles or organizational boundaries, really just get the right people.
And then finally, your goal, or specific outcome, is your rallying cry. It's the thing that's going to bring the team together, and the business around it, and it also reinforces the temporary nature of the squad. So, we can get into a few examples of when you might want to use a virtual squad. When you're building something zero to one, or when you're re-architecting shared infrastructure, or as an accelerator for important initiatives across the business.
So, moving from the abstract to something a little more concrete, I'm going to talk about a case study that we had for specs. As we survey our customers and we engage them, we discovered, this year, a key area of focus was improving designer to developer hand-off, and in those instances, what we're really looking at is developers wanting to know what prototypes are ready to develop, where they can go in InVision to find what's ready to implement, having their own space within the platform, and designers wanting to see progress from the developer within the InVision platform. So, our proposed solution to this was a new document type called Specs. It allows designers to break down large prototypes and designs into the subset of screens you need to build. This way, the designer can document requirements for the developer complete with artwork, UX maps, annotations and specific guidance.
For developers, the need to be able to click into those artboards and get at the measurements, fonts, colors and assets they need to do their work. I think the best part of this is that it seamlessly integrates with Jira, so you can easily connect an InVision spec with a Jira ticket or epic enabling the developer to quickly and easily get at the design requirements and stay up to date with any changes that happen on the spec, and then, conversely, the designer can follow along on the spec to see where the ticket is in progress.
So, we had this idea. It's a potentially big opportunity. What's the next step? Well, we need to break down the problem. This project is going to be complex. It had a diverse set of needs. This is going to be a zero to one product, so it needed a new domain service. It needed a new spa, so we needed a good mix of front-end and back-end folks. This product was also going to be built by, essentially, taking other products and pieces of the business, so we needed domain experts on the pieces that we would be leveraging. This product was also going to be built on some legacy systems, so picking someone who's a bit of a historian helped us navigate the winding road of why we built this thing in this way in the past, and then the project was going to need approval from various guilds and architecture teams, so it was important to pick folks that had influence and would want to champion the architectural design with those other stakeholders.
So, then it came time to assemble the team and begin working. Above all, what counts here is people. You need people with that X Factor, people that are excited and passionate about the project and the vision that you have, people that are senior enough to take ownership without needing excessive requirements or a well-groomed backlog, people that can maintain a good attitude and be positive even under pressure, and people that you can instill a lot of trust in. Once you have those people, you need to make sure that they're all in. If you have people that are 50/50 or 80/20, they're going to get distracted by the other workstreams they have going, and things can fall apart.
In terms of squads, rituals, and comms, you're going to run this like any other regular agile team. Two weeks prints, retros, stand-ups, all the usual stuff there. A couple of notes, here, though, is if you can, favor explorations like spikes and proof of concepts over technical documentation. I tend to find you get a stronger signal path by starting to walk down it than remaining in the abstract, and then if you've committed to an aggressive deadline, try to cut scope over cutting quality, and where you do cut quality or cut corners, make sure that you over-communicate that and have a plan in place to address it once you get something into customers' hands.
Speaking of getting things into customers' hands, you need a good release strategy. For us, this is where LaunchDarkly is amazing. We're big fans of it. In this instance, we had one feature flag across four teams that allowed us to onboard new users across native apps, within space and home and on our new document type. We were able to target internal teams sooner, and then we, essentially, used rules to create new sets of cohorts. Because we hadn't done a lot of performance testing against this, it allowed us to quickly roll back if we brought on too many users at once, and we're still using it, at this point, to de-risk new features. So, as we add new text and drawing tools to specs, all of those are behind feature flags.
Then the Yin to Yang of this is that you need a good way to collect feedback. We want to do that in a highly collaborative way, so we created a new workspace in Slack, brought our customers into it, brought our engineers into it, and on the first day of the beta, we actually had a user notice a bug with how their artboards were being displayed. They called it out in Slack and one of our engineers was able to respond to them directly and actually help them identify the bug and then chip a resolution within an hour or two. The other great thing about having a Slack workspace is that your customers can also engage each other and share their experiences, which creates a nice fly wheel for communication overall.
So, with all that in mind, we were able to reduce our time to market with this approach, leveraging existing technology, documenting things internally, and we were able to go from idea to team formation to beta in just under three months, and on the first day of the beta, we were able to respond to users' feedback in real-time and improve the experience for them. Presses was hitting bigger deadlines in record time and getting to learning sooner.
So, I'm looking forward to any questions you have or the community out there on Twitch, and thanks for listening.
Yoz Grahame:
Thank you very much. That's great. Yes, as Ben said, we are eager to take your questions, today, on the Twitch chat. Please, give us anything you'd like to address. I mean, I have a bunch of questions about this approach because I can imagine that it's the kind of thing that... I mean, you've presented all the upsides here and some of the things to be aware of, but there's got to be some trade-offs, right? If you're taking an existing organization's structure and dynamically suddenly changing it, I can imagine that cause a bunch of problems.
Ben Wilson:
Yeah. Absolutely. I mean, you have to... For every person that you're going to take from a different team, and I think we ended up taking folks from four or five different teams, they had to measure the impact to their own roadmaps to help us create this new experience, and we had to weigh all of those decisions. As we went along to... I think we discovered some other pain points about not having everybody be all in. So, that's actually why we added that slide to this deck. We had some people who were partially committed, and that created challenges around scheduling certain meetings we needed to, or understanding what of their time was going to be available to us. So, I think that was a big learning.
Yoz Grahame:
Yeah. How do you deal with that? If it's only possible, presumably, when you have a situation where the team's... Actually, let me stop and step back a bit. How do you pick who's going to be in this virtual squad? Is it based more like who the ideal people are and then you try and persuade their existing team leads or project managers, or is it more about which long term teams currently have capacity to lend some of their key people?
Ben Wilson:
Yeah, I mean, it could be a mix of those approaches. I try to be as idealist as possible and figure out who is going to best accelerate this project, or look for gaps. As you're assembling the team, you're going to discover where you have gaps or you need coverage, and you want to find those folks that you can bring in, as well. One thing to actually watch out for with a virtual squad is you don't want to stack the deck with too much talent because having brilliant people being idle means that you might over-optimize or over-engineer your solution, and really what you want to do is get signal from users because if this doesn't work at all, copy-pasting something is fine because now you're just throwing that away and you can try the next thing.
So, it's honestly better to try to run the squad as light as you can and not over-extend anyone, but make sure that they're all stretching to create the coverage you need.
Yoz Grahame:
Right. So, question we have from [Mustack 00:15:01] in the chat saying, "Can you prepare for the case where you need more time than expected? Does every effected team need to commit to potentially giving up their folks for longer?"
Ben Wilson:
Yeah, that absolutely did happen, in this case. We were hoping to have somebody roll off the squad earlier and, due to other changes, we needed him there longer, and so you have to, essentially, have the same conversation you had when you brought them in and say, "Hey, is placing the bet on this new thing more important than what they could be doing back on their other squad?" But you can also swap other folks, too. The picture I have of this virtual squad in the all-in section, I think 50% of that remains on the virtual squad for this next leg.
Yoz Grahame:
Right.
Ben Wilson:
So there's some fluidity there. Sometimes you really do need to get those people back to the good work they were doing elsewhere.
Yoz Grahame:
To me, the first question that raises as a soft engineer is Brooke's Law. Right? Being that, if you try and sort people in and out, dynamically, in the middle of a project, doesn't that cause massive slowness, itself?
Sorry, I should quote for those who don't know the reference. Fred Brooks, writer of the Mythical Man-Month, which is possibly the longest-lived and best-known software engineering text in existence. The law is adding more people to a late project makes it later because of, especially, the cost of getting them up to speed, is primarily the issue here.
Ben Wilson:
Yeah. You do incur those costs. You kind of have to bake that in, but what's ideal is as you're transitioning somebody out, if you can get a week or two of overlap with who is going to be coming in and have them shadow the person that's leaving. Pairing is a great way to reduce ramp up time and just having them move in lock step. So, I found that that's a good way to not get such a drag on velocity as you're rotating people.
Yoz Grahame:
That's a good point. It sounds, to me, fairly challenging from a project manager point of view. There's a lot of planning, a lot of independent not just agility, but improvisation needed.
Ben Wilson:
Oh, absolutely. Early in the project you would come to stand up and find that a developer had been working on another ticket much of the day, and as long as you're instilling that trust in them and they're making the right calls, you can actually move faster by having less overhead and less structure around it up front. If everyone understands what the outcome is and feels like their able to unblock themselves and to move with some autonomy, that can be a good strategy to mitigate that. Of course, that can go wildly wrong, but that's, again, where trust and building relationships with folks eases that concern.
We actually brought a TPM in to help with the project a little bit later, much closer to when we were going to launch the private beta to just look at what we had at that point. It just felt like the right time because early on, what we were doing was a ton of testing, a ton of concepts, and then just trying to move as fast as possible, and then, at a certain point, you have to say, "Okay. Where are we now? What is the shortest path to getting this thing released?" It's great, at that point, to have a fresh set of eyes come in and help guide the process from there.
Yoz Grahame:
Yeah, and I can imagine. It sounds like it's a higher pressure project, and that is not an impression you want to impose on people for a long period of time.
Ben Wilson:
True. You can't really keep up that exact pace and have these poorly estimated tickets. At a certain point, you get into a rhythm and you want to create a team velocity that you're all moving at. So, you do have to... For us, it was post-private beta released to customers that we said, "Okay. Let's take a look at our operations. Let's harden some of our processes now, and make sure that we're building sustainably."
Yoz Grahame:
Sorry. That looking at your operations, was that happening inside the virtual squad or is that more across the whole engineering world?
Ben Wilson:
I definitely think it's a mix of both, but it did feel like it was being driven somewhat internally. We had really great leaders who were looking at what we were doing, too, and were really great at pointing out, "Hey, this is the moment to bring in that TPM," or, "You might want to think about what this means for support or legal," or any of these other considerations that swirl around, that are really important to actually getting it to the last mile of into a user's hands.
So, a lot of the internal stuff is really around how do we build this with as little tech debt as possible? Let's make sure we don't go through any one-way doors with the architecture, and then to identify those areas where we straight-up copy-pasted code from another team. Well, we went back and created another virtual squad with an engineer from our virtual squad and an engineer from where we took their code and created this unified Canvas component that we both could use. You have to incur those slowdowns and pay down that debt, but it was important to us to get user learnings faster.
Yoz Grahame:
Yeah, and I can definitely see that getting the validation of the ideas, shaping in something to actually decide whether this is worth the effort.
Ben Wilson:
Absolutely.
Yoz Grahame:
It sounds quite costly to run a virtual squad in this way, in terms of that it requires more effort and you are taking resources from other departments or other teams. Has there been an attempt to actually try and budget, to cost it out, specifically?
Ben Wilson:
Yeah. Absolutely. I think we always look at what the potential opportunity is for us, and in this case, if we improve the developer experience in our platform, we can sell more developer seats. We look at the opportunity from what customer demand is, and we can do calculations around those team sizes and what it means to get this lift, and then look at what we're investing in it up front. In this particular case, we're not quite sure yet if Specs gets folded back into... We have a developer persona team called Inspect. This work might just fall back into that squad, or it might stay as its own separate track long term, especially if it's improving customer value and is starting to generate its own revenue. That's an opportunity for us to reevaluate what this looks like, and maybe we step it up for the long haul.
Yoz Grahame:
Right, and this actually leads into another question that we have from the chat, here, from Mustack again. How do you plan ahead for staffing that project In the long term? Is it a situation where the virtual squad becomes a real squad, or is it handed off to an existing squad, or what do you normally do?
Ben Wilson:
I mean, I guess there isn't necessarily a normal. It depends. With the shared canvas component we made between another squad and the component that we copy-pasted, that's going to have shared ownership forever and will require some time from both teams that are contributing to it. The case for Specs, I think, that's why it was so important to get it done in three months or less because we wanted to start to get that customer signal because all told, if this isn't the solution, it's better to find out early and scrap this and figure out what we need to do instead.
So, I think it's important to look ahead, but you don't want to look too far ahead. If you have a specific outcome or goal in mind, that's your North Star, and see what you need to do there. Do you need to invest more? Like, you think you're close to something and you need to invest a few months out, or it's a smashing success, let's staff this up now, and keep it going long term.
Yoz Grahame:
Right. What do your existing squads look like? As in, the non-virtual squads. What are the teams that you're pulling from?
Ben Wilson:
Sure. As an Engineer Manager at InVision, I'm currently running four different squads. So, I pulled some folks from my other squads. This probably is just for the developer persona. So, the core team we took from was Inspect because this is going to support that persona the greatest. Outside of that, we looked for opportunities. Like, we were about to do some pivot with other teams' projects, and they had some really dynamite back-end people. So it was good to bring them in to help us build something out in greenfield.
We had to reach pretty far to get some people with the historical knowledge we needed, people who that had been in the company for five or six years, and in each of those cases, you want to balance a lot of different things because you need to think about that individual that you're pulling in and the story they want to tell at InVision. Right? Often times, they're vying for promotion or figuring out what's next in their career, so you want to make sure that you're helping them tell the right story. You want to make sure that the teams that are sacrificing that velocity are getting recognized as part of your success. It isn't just this team. It is a company-side effort. We're all in.
I think those are some of the ways that it helps you recruit the right people, but it can really be a challenge.
Yoz Grahame:
Yeah, but it's interesting because that, I think, gives me some of the best insight into why this works. I think, certainly, I was initially skeptical, as I always am, of new approaches, but if it's a situation where you have teams representing different business value or different parts of the business, and you have a new feature or project that is going to benefit multiple parts of the business in one, and that if they're going to need to do their own engineering on it. It makes total sense to pull from those teams, especially because what you're doing is you're also creating the knowledge within those teams, seeding the knowledge as the project is created.
Ben Wilson:
Yeah. Absolutely.
Yoz Grahame:
Yeah.
Ben Wilson:
And then there are all kinds of personal reasons. Maybe you have a new developer who's wanting to jump in to go or just get some exposure to that world. I think you have to find both the business case and the personal case for why it makes sense, and it's not always the easiest, but fortunately we have a really great talent pool at InVision, and that certainly helps.
Yoz Grahame:
That's fantastic. How many engineers, or not just engineers, but team members who would be in these squads. Roughly how many people do you have for that?
Ben Wilson:
I believe, somebody can correct this on Twitch if anyone's there, but I believe we're just over 200 engineers in the org.
Yoz Grahame:
Fantastic, and, presumably, it's not just engineers that you pull into these squads. It's designers, writers...
Ben Wilson:
Yeah. Exactly. Marketing folks, customer-facing people. Yeah, when you do something like this, the products you build is somewhat insular in a silo, but if you're not thinking about it holistically and how it connects and lines up to the business, well I don't know who approved it, for one, and then for another, it's not going to get out of the gate. So you have to put in the leg work across all different verticals in the business.
Yoz Grahame:
When you're doing that, how does UX research fit into that? Does the whole team do UX research together in the beginning, or has it already been done?
Ben Wilson:
Often times, it's already been done. We try to have product and design a bit ahead of engineering, for obvious reasons. Hopefully they have some high fidelity prototypes they're getting in front of our customers. We're also getting signal just from our customer research. That's generally ongoing, so that's how we dip into the broader business insights, and that really comes down to our product manager being connected into those worlds and looking for the big dollar opportunities for us, and then working with design on creating the experience that we're then going to test.
We also like to have developers having a seat at the table, too. A lot of why we're able to dog through these things is we're the customers for these tools. So, the Inspect team, most of them are front-end developers that had formally used Inspect at their other jobs.
Yoz Grahame:
Right.
Ben Wilson:
That's always really helpful, to make sure that... We want to solve the problems of our customers, but it's really helpful to be solving our own problems along the way.
Yoz Grahame:
Yeah, and we find that, obviously, a lot at LaunchDarkly, as well. We are often using the product just as much, if not more, than anybody else. So, meeting our own needs is how a lot of our work tends to happen. It's interesting, actually, we have something at LaunchDarkly that is... I mean, engineering has recently switched how it self organizes in squads, and especially... Well, instead of being called engineering, it's product delivery, which includes designs and [inaudible 00:29:56] people, and so they are these cross-functional teams that work on specific parts of the product.
But once a quarter, we have this week that ultimately is just a couple of days where people who've been itching to add something new or experiment with something new in the product, just pull together a team. They come up with an idea. They throw it out there, and people volunteer to join their team just for a couple of days to see what we get done. It's known as Moonshots.
Ben Wilson:
I love that.
Yoz Grahame:
And it's great for experimenting because it's this burst of energy where we come up with incomplete demos. It's very rare that something that is good enough to be shipped is produced in those two days, but there have been a whole lot of product improvements that have gone live as a result of being born in a Moonshot.
Ben Wilson:
That's incredible.
Yoz Grahame:
Yeah, happy to share more information about it. I mean, actually, this year we're thinking might want to video some of it because normally it happens, obviously, in the office, most of it. This year it's probably going to be a bit different.
Ben Wilson:
That's all right. I love how you reframed engineering as product delivery. Just having that more holistic or inclusive language can break down barriers and make it so much easier to collaborate. Our engineers have really strong opinions about UX and our designers are all really thoughtful about how something is built and engineered and know where we need to make those trade offs. It's always about having a ton of overlap there. I like that you're referring to the teams in that way.
Yoz Grahame:
Yeah. It's definitely something we don't... It's tempting to give software the engineers priority, given that majority of our customers who use the product day-to-day are engineers, but certainly not all, and there's a whole lot of good reasons to make sure that you give more level equity to different members or different disciplines within the product creation process. Doing the cross-functional thing is hugely valuable, especially if you can involve them in the UX part. So, having some buy-in not to the solution, but to solving the problem. So you don't necessarily get attached to a solution, you get attached to solving the problem, however you end up doing it.
Ben Wilson:
Yeah. Absolutely.
Yoz Grahame:
Sorry. I'll stop rambling about how we do things.
Ben Wilson:
That was wonderful.
Yoz Grahame:
Thank you. I'm glad it's useful, and I think it's very valuable for us, in long term, compare how different companies do these things and the lessons that we've learned. I think that thing around arranging into squads touches on something that I have seen more and more. Some wisdom that I've seen, which is when you get a team, a small team that works really well together, do not break that team up.
Ben Wilson:
Absolutely.
Yoz Grahame:
Those dynamics are incredibly valuable.
Ben Wilson:
Yes, and it's not necessarily easy to replicate because, again, it's about that team building trust. It's about them building a communication short hand. That's definitely something to be protected when it's working.
Yoz Grahame:
Yeah. So, this leads into the question which is, if you have squads or small teams that are working really well, it must be quite taxing... Do you take that into account when you're building virtual squads? So which teams are currently working really well and which teams are not working? Try and, maybe, avoid splitting up teams that are working well, maybe do try and use virtual squads as a way to find new groups that work well together? Sorry.
Ben Wilson:
Yeah. Yeah. I think that's where the temporary nature of the virtual squad comes back. I think, as a rule, if you have too many virtual squads, maybe your organization is just set up incorrectly for the kind of business you're trying to run because you don't want to ship your org, but you do want to try to optimize those lines so that people can move as fast as they want within those guard rails. If you have a high functioning squad, like the Inspect squad, some people were pulled out of that to work on Specs, you take that hit to the velocity, but you're also hopefully able to take the practices that they've learned there and evangelize those on the other squads they move to, and then they're going to get exposure to other teams and see how they're running their processes.
At the beginning of the retro, they're going to start with outlier tickets that... Why was this one so much shorter than we thought, or this one was so much longer? Like, "Oh, that's a great practice I can bring back to my squad," and as long as it's a temporary arrangement, you're giving them an opportunity to see another way of working which will either fortify what they love about your squad or it's an opportunity to bring in change because you can also get stale if you just work the same way day in, day out.
Yoz Grahame:
Right. That's interesting. As you said before, being able to cross-pollinate practices that are working effectively is fantastic, but how do those teams, when they start working together, and you've got a bunch of people who are all used to working in slightly different ways, how do you pick the working methods for that team?
Ben Wilson:
A lot of the times the work will help you do that. Certain projects are better suited for [Can-ban 00:36:10], certain ones are better suited sprint, and then don't be afraid to change your process if it isn't working. Right? Disagree and commit early to a way of working, and then check in. That's what retros are for, right? "Hey, is this actually serving us the best that it could or is there something new we could try?"
Yoz Grahame:
It's interesting that you use both Kanban and Sprint and possibly other methods throughout the organization. I suppose it depends on the kind of work being done.
Ben Wilson:
Sure.
Yoz Grahame:
It sounds like these virtual squads are a great way to evolve this, as well. What are the things that you've seen come out of squads, as well as the core product that they were aiming for? What are some of the interesting side effects, or some of the interesting problems that you've seen come out of these?
Ben Wilson:
Out of virtual squads, or squads in general?
Yoz Grahame:
Virtual squads.
Ben Wilson:
Ah. It's really the cross-pollination thing. I think that is the great thing, bringing those processes and things back to your regular squads. Also, I think every time it's pretty unique because, again, hopefully the virtual squads are an outlier. So, you don't get to do them too often. It really needs to be an opportunity that is important to the business and something that you're not structurally set up to accomplish. Sometimes you can just add an additional seat to an existing squad and you're good to go. Again, I would say, I haven't had a ton of exposure to these. I've done maybe three or four in a career of ten years.
Yoz Grahame:
So, they really are quite rare. They're not [inaudible 00:38:12]
Ben Wilson:
Or they exist for two weeks to accomplish something across two different teams, and they go by so fast that you barely notice it. It's a blip to your velocity on your team. You're sorting out a problem, like you're reducing your code footprint, or whatever it is that you've set out to do with this very tiny virtual squad, and it can almost go undetected, right, in your goals for the quarter.
Yoz Grahame:
Right. So, within the organization, within the overall organization, is that this is a standardized method of working in that the virtual squad is a known entity and you have a standardized way of deciding, "Okay. We think this is worth doing. This is how we're proposing it. This is how we get approval," etc.
Ben Wilson:
Yeah. I mean, we have a lot of great standardized processes in place already. We use this format called Daci for choosing difficult decisions, and then problem tech has a great way of generating briefs, and we already have these practices that we do just within our squads that you can leverage to do this kind of work. It's just the additional factors like, we can't accomplish this with how we're set up today.
Yoz Grahame:
Right.
Ben Wilson:
And then, usually the only additional meetings are those to vet the value of it and to get those approvals up the chain, but every other part of it... Once you're in the virtual squad, it runs like a squad. It's goaled like a squad. Everything about it should look the same except after that quarter, hopefully, it dissolves and everyone goes back to what they were previously working on.
Yoz Grahame:
Yeah. I'm sorry. For those who don't know, I just posted the link in the Twitch chat for Daci, which I had not heard of before I came to LaunchDarkly because there are many ex-Atlassian people at LaunchDarkly and I'll post a link to the [Atlassian 00:40:21] team playbook, which is where it comes from. Daci stands for Driver, Approver, Contributors, and Informed. I'm generally used to a Daci being a template for a one page document that explains the aim and the proposal, but it's very useful for those of you looking for a structure, especially, it's useful to have structures for proposing ideas and a common language for it especially as you grow as an organization.
Ben Wilson:
It's really helpful at putting the people that are driving it and approving it top of mind so they don't get lost in the shuffle. So, you know who you need to influence or... At the top of, at least the template we use for it, which we have a lot of ex-Atlassian folks, too, it really is about putting the people on top of everything. Right?
Yoz Grahame:
We have that, as well. It's a vitally important question when doing to the approval. It's interesting because a lot of it comes down to trust. Quite often you see the people who are enrolled, and you can go, "Look, I trust them. I know they wouldn't be wasting their time on something they didn't think was important."
Ben Wilson:
Yeah. Absolutely.
Yoz Grahame:
How much approval does a virtual squad need? What does that look like?
Ben Wilson:
I think it's all based on what the goal or outcome is. If it's a two week project, I think the engineering manager on the two squads involved, or three squads involved, can sort that out. There's a lot of this stuff you can launder through your normal working cycles, and it's easier... If the amount of effort being put in and the risk is relatively low, I think owning those decisions lower in the org is where those should be. When it's something like creating a new document type and figuring out how you're going to market that and roll it out, of course, that's on the other end of the spectrum where you really need to get approvals all the way up through the org because you're going to be making fundamental changes to the business and, potentially, committing people to years-long investment.
Yoz Grahame:
Right. Presumably, the approver isn't going to want to see the risks that you've evaluated. What do you normally look to those risks? What kind of questions are you answering?
Ben Wilson:
I think the biggest risk is how long does it take to get to signal because that is time that is otherwise spent doing something else that is, hopefully, moving the needle forward in the business, like time is the chief factor. So, you really want to frame it in like, "Hey, we can get to learnings in three months, and if it's a bust then we're on to the next thing."
Yoz Grahame:
Yeah. Let's see. By the way, just for the audience, we are talking about squads with Ben Wilson from InVision. We're going to be going for another ten minutes, also. So, please if you have any questions about this then please post them in the screen chat. Sorry, excuse me.
Yoz Grahame:
I'm sorry. I'm trying to think. One thing that was asked about earlier was when it goes wrong, because I'm always interested in failure stories, do you have any particular lessons or situations where it just didn't work out and why it didn't work out?
Ben Wilson:
Yeah. A few years ago, I tried to do something similar at another startup. I think the opportunity was right. The business was excited about it, so we had done our diligence to get buy-in and everybody on board, but there were a lot of people really excited about the project that wanted to be attached to it, and we felt like the more the merrier. I'm not going to turn down adding in brilliant people that want to help us solve this problem. Of course, you add folks, you add complexity to the communication, you add challenges around scheduling. That's why I'm now more on the side... If anything, you might want to run the squad every so slightly under staffed just to make sure everyone's really extending themselves because they understand that this is a finite amount of time where they're going to run as hard and as fast as they can.
I would say bringing in a Technical Project Manager too early, I've had issues around that. We have all these unknowns that we would like to just answer, but we're already being tasked with trying to estimate complexity and uncertainty which you can do on a per ticket basis, but it's much harder to do with overarching architecture. Again, just having a handful of people that want to run fast and treat this opportunity like a mini startup within the org is a way to avoid that because I definitely had that issue with too many people wanting to hop on to an exciting opportunity, and it just toppled over. We weren't able to get it in the window we needed to prove value.
Yoz Grahame:
Yeah. I can see how you've got to be so careful, otherwise the virtual squad takes on a life of its own that consumes more than it provides.
Ben Wilson:
Absolutely.
Yoz Grahame:
One more question from the audience. Have you considered using contractors for something like this?
Ben Wilson:
Oh. Yeah I think that can absolutely work, especially if it's Greenfield or Net New. It depends on how much you're going to be building on your existing systems or how much institutional knowledge is required to get started because ramping up folks can really be a challenge, but you need contractors that aren't going to be sticklers about having a brief for everything and wanting that well-groomed backlog. These are contractors that need to act as owners. That's a particular type of individual you're going to look to contract in those cases.
Yoz Grahame:
It's fascinating. I would love to see more work into how you get that pool of contractors and ability to extend temporarily. There are so many situations I've been in where I think this is a really nicely, tightly defined unit of work, and if we had a procurement system internally where I could just say, "Look, let's throw a certain amount of money at this and get it done," there's so many ways it could unblock things and provide because, so often, in certain organizations, the problem isn't money, it's people and time.
Ben Wilson:
Yeah.
Yoz Grahame:
It's something to...
Ben Wilson:
I was going to say, it's also really great if you've worked with those people before and you have that trust, and if they're open to contract to hire, that's always great, too. You're like, "Hey, if this thing takes off, would you consider coming on board and helping us run with this?" Again, if the contractor leaves, it's much harder to ramp somebody else up on the project. Whereas, somebody rolls of, but they still have the context of what they worked on. You can still pair them up with somebody new coming on board.
Yoz Grahame:
Yeah, that's a really good point. Having that knowledge walk out the door suddenly can be deadly for a project.
Ben Wilson:
Absolutely.
Yoz Grahame:
We need to wrap things up in a moment, but before we go, I really wanted to find out more about your craft, especially the little box and how you made it.
Ben Wilson:
Sure, yeah. I got married just about a year ago, and for our first anniversary, we were just making crafts for each other at home because of COVID. Not a lot to do and go out on the town right now. So, I made this box with our Cricut maker. It's pretty incredible. It's a plotter, so it cuts it, it scores it. You can actually drop pens in it to draw on it, and in this particular case, the concept behind this was this appears on my desk from time to time. It actually showed up this morning, and then inside it, there's always a prompt. In this case, it's "Something from your Cortada trip" because I just don the mask and run out to the coffee shop. So I'm going to have to take my Instax camera, which takes these mini Polaroids, and I'll take a picture from my walk, throw it in the box. I'll hide it somewhere in the house, and my wife can discover it.
Yoz Grahame:
Quite charming.
Ben Wilson:
Definitely recommend those. They're incredible devices.
Yoz Grahame:
Oh yeah. I never heard of it until literally an hour ago just before we started to stream, and now I'm going to put a link to it in the chat if anybody wants to find out. Neither of us are financially affiliated with Cricut.
Ben Wilson:
I just love the construction of boxes. I think like a J.J. Abrams TedTalk from a decade or more ago, he deconstructed a Kleenex box, and I was like, "I don't look at boxes enough." So I started deconstructing them, and then they just got fun to try to figure out how to make a simple one.
Yoz Grahame:
Yeah, you were saying, on your laptop, as well, you've cut out a whole bunch of stickers and things. Oh, look at that. And that's all stuff you made yourself?
Ben Wilson:
Yeah. Yeah. I love getting into Illustrator or Photoshop and working with those tools. I would love to be a designer. I don't quite have to chops for it, so I love working at a company that prizes design such as InVision.
Yoz Grahame:
You and me both. Somehow, when I was a kid, I had a huge amount of fun playing with deluxe paint on the amigo, and then Photoshop came along and I didn't understand it, and somehow let it all go.
Ben Wilson:
Yeah. That's too bad.
Yoz Grahame:
Yeah, but it's really worth playing with these things again. Yeah, boxes. I'm going to hit you up later for some more tips about boxes because that does sound fascinating.
Ben Wilson:
I'll send you one of my templates. Yeah. I've got a whole stockpile of them now.
Yoz Grahame:
Brilliant! Thank you so much! And Heidi in the chat was talking about Pharaoh drawing? Sorry, Heidi. Not sure what you're talking about. Pharaoh drawing. Do you like to paint? Oh, the Tutankhamen. Right. Tutankhamen image where it's the standard on the box of deluxe paint.
Ben Wilson:
Ah, yes.
Yoz Grahame:
Yes. Exactly. The picture that they lied to us about being able to make unless you want to painstakingly hand [crosstalk 00:53:04]
Ben Wilson:
Sure. Stipples and pixels.
Yoz Grahame:
Why not? Spend a couple of years on that. It's like the SVG tiger somehow that someone put together. Anyway, thank you so much for joining us today, Ben. Thank you for the talk about virtual squads. I have to say that I was somewhat skeptical coming in, but there's a whole load about this that makes a huge amount of sense, especially for freighting things that are co-owned by multiple parts of the organization and spreading that knowledge, making sure that everybody has it.
Ben Wilson:
Awesome. Yeah. Let me know if you end up using it. I'd be curious to hear your thoughts.
Yoz Grahame:
Again, it'd be lovely to compare notes more on how we do things at LaunchDarkly and how you work at InVision.
Ben Wilson:
That would be fabulous.
Yoz Grahame:
Thank you everybody for joining us on the stream. This video will go up within the next month or so on the blog with a transcript and we haven't decided yet when the next Test in Production will be. If you are interested in talking to us about something, you have something you want to tell the world about, how you test in production, how you keep things moving, how you test out new ideas, and then please get in touch with us at LaunchDarkly, and we would love to have you on the show. Until then, thank you for joining us. Thank you, Ben.
Ben Wilson:
Thank you.
Yoz Grahame:
And, yes. See you all soon. Have a great day.
