Skip to main content
Gun.io Home

Using a F.A.I.L. Mindset in Scaling Organizations with David Shapendonk of IMAX and Maestro Games

No stranger to screens big (very big) and small, David Shapendonk was the Direct of Technical Ops for IMAX before flexing his entrepreneurial muscles.

He’s now the CTO of Maestro Games, a startup helping to build technologies that incorporate music therapy with VR gaming to help people with anxiety, PTSD, autism, and other stress-related ailments.

In this episode, David and Ledge chat about the differences in scaling between small and large organizations, having a F.A.I.L. mindset (first attempt in learning), and utilizing a “trust and verify” approach to technical hiring. 


David Ledgerwood
David Ledgerwood
· 18 min

Transcript

Ledge: David, thanks for joining us today. Great to have you!

David: Thank you so much, David, for inviting me! It’s a pleasure to be here.

Ledge: Fantastic! Just for the audience’s sake, why don’t you tell us your two-minute story and then get to what you’re working on now.

David: Excellent! I’m a longtime suffering IT individual. I started over twenty years ago in information system. I started out in gaming structures, worked for IMAX for over twenty-seven years building out systems cumulating with development of virtual reality centers that we’ve rolled out and then also contribution system.

I currently went over to my new gig, Maestro Games, and I’m the chief technology officer there developing virtual reality music therapy for the medical space. We are primarily focuses on PTSD and occupational therapy for our start; but we’ve had discussions to branch out into autism, Alzheimer’s, Parkinson’s, and a number of other challenges that folks have out there where music therapy can make a difference.

So that’s two minutes.

Ledge: Fantastic! Thank you so much. That’s great interesting stuff there. I wonder, just from your standpoint having worked for the big dog there and then the startup, what’s the path of VR?

You’ve probably been doing it kind of on the ground, maybe longer than some of the hype cycle that people would be aware of. What does this really look like when you’re kind of deploying it and starting to build that technology?

David: I think as this is a fairly new technology, you have to sort of pick your point of entry and start small and then sort of build out your business plan. I think that’s key.

Everyone sort of gets hang up on the technology. But how are you going to bring this force to consumers and others and make it meaningful to them?

Ultimately, if you’re going to succeed in the business, you have to have something that people want to use or desire; and I think for any sort of technology, especially for what we’re doing, it’s really sitting down with our audience and customers and saying, “How can we make this work for you?” And that’s something that I think we’ve been successful in so far. I think every organization, no matter what the field, that’s something they have to tackle.

Ledge: You’ve been on the management leadership track at a big organization; now, you’re doing the startup thing. I just wonder, what lessons of team building and hiring and sort of building out the human infrastructure have you taken with you?

It’s not easy to hire project managers or consultants or developers. So what heuristics do you use there?

David: I think whether it’s a large organization or a small organization, you have to understand what you’re mission is, number one. What is your goal? And then, build a complementary team where you have everybody bring a specific skillset.

You want to make sure that the group, as a whole, works well together. You have to understand individuals and their characteristics and make sure that you bring individuals in who can work with one another because I’ve seen that, oftentimes, groups implode simply because you have one or two who have been brought in who just don’t match.

That’s true especially for small organizations because you just don’t have the latitude to deal with the extra-curricular stuff that might crop up when people just don’t get along. You just don’t have the time or money.

So it’s really key to pick your teams well. And don’t necessarily get hung up too much on experience. Look for core value sets.

So if you’re building an engineering team out, does somebody have, say, documenting skills or conceptual skills that are strong and they just need some additional work on to programming language, that sort of stuff you can give individuals through courses, etc.?

It’s really key to focus on building your structure with the team. Once you know your mission and get your team set up, you’d be surprised what you can accomplish.

Ledge: And how does that work with maybe remote or contract resources? We’re in that business so we’re always evaluating people and thinking about maybe a non-traditional kind of way to work. You’re not maybe always going to be in the same room. You only need an SME for a certain amount of time.

How do you thread that needle because you don’t want to invest very heavily in cultural fit for somebody who is maybe not on the permanent long-term team?

David: I think you still have to go through a little bit of that cycle because, ultimately, if you have somebody who doesn’t communicate well with individuals in your group, things are going to get missed. Even if they’re a contract or short-term resource, I think one of the things you do as you go through the industry is you start to build a rolodex of individuals who have worked really well in specific areas and you see if you can start bringing them back in even on a part-time basis.

I have a number of individuals who are working with our current organization who are with UFC or other organizations that are giving us some of their time.

But as a small organization, we’re looking for a cohesion of tasks that don’t necessarily consume the entire day of the individual’s time. So, for us, it’s really still about finding the right fit, and then managing the time as to what we can afford.

Ledge: From a management-team perspective, as the CTO, are you out there meeting with customers as well? Are you also the chief product officer?

We’re seeing a lot of people talk of those in the same sentence now.

David: When it comes to operational effectiveness, you have your COOs, etcetera, becoming much more involved in the product cycle ─ even the same thing with marketing, etcetera. You want everybody to sort of be at ground zero to understand how it’s being developed. It helps them to do their jobs better.

So, yes, I’m very much in the mix with customers, product demos, etcetera. It’s not just because we’re a small organization. I think, in some ways, because, in small organizations, individuals have to wear multiple hats, that integration tends to work much better than in larger organizations. But I still think that even in big companies, you need to have engineering and marketing and operational folks involved in the process from the get-go because, ultimately, you have to listen to what your customers are saying and make sure you meet their demands.

If you do that, then, obviously, you have a very good chance of being successful.

Ledge: You talked to me off-mike when we originally spoke about sort of a trust-and-verify disposition to hiring and managing. I would love if you would expound on that a little bit.

David: Sure. Trust and verify, what does that mean? It’s basically when you bring in an individual into your organization whether as a contract or an employee or an outside partner and you start to say, “Okay, what is it that we need to achieve?

You agree upon that and then you give them your tasks. And you don’t wait for four weeks before you try verifying if they’re meeting their goals. You start small and you start to do immediate goals like are they meeting everything that’s expected of them?

And, very quickly, you’ll understand, is this an individual or is this an organization that can do the job that we’re putting in front of them?

So trust and verify, start small, start with small tasks and verify as you go.

And then, the other core is to let go. You have to be able to say, “Okay, as long as you’re meeting your obligations and we’re verifying the steps as we go, I’m going to trust you to do your job.”

For some folks, it’s very hard let go, and that goes back to the team cohesiveness. If you have somebody who is micromanaging and you have a group that’s not used to it, it can cause a lot of problems.

And then, whenever you come out with your final product, I think the last four items have always been “whatever you release, there’s probably going to have something wrong with it.” So accept that.

The acronym I learned a long time ago was the word “FAIL” which is “first attempt in learning.”

So you basically would want to be able to go out there and say, “We’re going to try to hit as much of our mark as we can but we’re never going to hit it precise.”

There may be occasions when somebody can do that, but that is not something people should expect.

And then, there’s the question of repeating the cycle and saying, “Okay, how can we make this better?” whether it’s a product or a service and go through that cycle again. And every time you do it, it’s like a golf game. Every time you whack the ball, you get a little closer to the hole but you, generally, never get there in the first swing.

Ledge: And you’re going to take a bunch of feedback from a bunch of pre-customers as you’re developing the product; and, ultimately, once you get the one out there, you’re going to take more feedback and then continue as your customer base grows which could be quite large.

How do you think about and recommend prioritizing customer feedback because you don’t do everything that every customer wants and you can’t fork your product in ten different directions to meet each customer need which we see startups do?

Sometimes, they’re chasing the revenue from anyone and ending up with sort of a mixed-bag product.

So how do you think about prioritizing one customer feedback from another?

David: First, I think it’s product focus. For example, for Maestro Games, as I’ve said, it’s post-traumatic stress disorder and occupational therapy space, for example, people who are just stressed at work; that’s our opening gamut in the market.

And so, we tell our customers that’s what we’re doing first. So people are coming at us for autism and Alzheimer’s; we’re letting them look at our demo product and say, “Start thinking about what it is that you’d like to see change or done to this without having to commit resources to that process.”

I think that’s way you can let people through. Give your customers something to look at and work with and have them start providing feedback even if that’s not your focus. But you have to prioritize your structure.

And I think as you go down the road, obviously, the larger population you’re going to affect with the change is something you will always focus on first.

Also, for your architecture ─ for our populations, we’re looking at having something in our architecture for software that we can change fairly quickly. So we’re anticipating that we’re going to get feedback from clinicians and from patient groups who are saying, “Can you make this small change because we think we get better effect if you ─ for example, for people who are suffering from PTSD, maybe there’s a large group of them who had occurrences that were started at night.”

One of our programs starts at night. We changed it to actually go back to start at daybreak or so; and these are visual stimulating in the VR space.

We’ve designed our structure. So those sorts of changes that can be done within half an hour. So those are sort of changes we’re anticipating in these structured environments to sort of meet goals.

So if your customer base is something that is going to request a lot of changes, then you have to sort of think about how you can structure that so your environment can meet those goals that your customers are going to throw at you.

Ledge: That’s a great product lesson. You can always architect in a way that allows for and encourages change. To be easy, you don’t always have to make that change but understanding that you don’t know everything when you set out is probably a good disposition.

David: The other thing is you just negotiate. For example, the development of VR scenery is probably one of the more time-consuming elements in our design.

So somebody will come back to you and say, “I would like a different VR scenario with different pieces of music. In this timeframe, you might go back and say, “Well, we can’t give you the new VR scenario right away. But how about this? We can input the music into something else and modify that structure so you get fifty or sixty percent of the way there?”

There’s nothing to say that you can’t negotiate; and most customers, if it meets their goals, are quite willing to compromise.

Ledge: You make a great point. I’m getting down to “What’s the real goal?” because people are going to come in very often and customers are going to pre-prescribe what they think the solution is without discussing the goal and it takes that sort of analysis to get to “Why do you want to make that change and what are you trying to accomplish?”

That’s very important; and, sometimes, I think that gets missed.

David: I think, too, that a lot of people have different conceptualizing a lot of stuff and data structures or user interfaces in virtual reality or visual arts. So one of the things that we find very effective is doing mock ups and giving them something that they can literally get their teeth into and give you feedback on.

I think one of reasons why Agile is so successful as a methodology is you take it in very small bits and you sort of feed through a process; and then, as you sort of go to the next iteration, the changes are small even as you work your way further down the road because they’ve gone back to the customer for verification.

Sometimes, you don’t get it right and you have to sort of figure how you’re going to manage that. But I think, with Agile, you have lot less risk of having a major stumbling block down the road than you would under waterfall or other methodologies.

Ledge: And “waterfall” is a dirty word. We can’t say that, right?

David: It’s no use.

Ledge: It is no use.

David: There are systems in there that have been doing it for thirty years; and changes is tough, sometimes.

And that’s the other thing, too. I think whenever you’re doing any type of work based solution you have to be able to bring change into the process. And that’s, oftentimes, difficult to manage even in small organizations.

Ledge: Absolutely! In every person you add is another sort of entire network chain between all the other people in that person so it quickly adds up to be difficult. And you don’t to have be talking about thousands of people in an organization. Even if you get up to fifteen in one room, watch what happens.

David: Just think of the old adage I used to think about. The more people you invite to a meeting, the harder that meeting is to plan. And that goes back for project work as well. It always goes back to my “Start small and keep everything as small as you can with your groups or your teams and even your customer bases.”

So, obviously, having a user group of two thousand to three thousand people is pretty unwieldy. So if you keep your user groups that are sampling product to fifteen, you might miss some things down the road but I think you can, at least, get a very good idea of what it is that people are looking for.

Ledge: Fantastic! David, thank you so much for joining us. Thank you for the insights and best of luck.

When does Maestro Games anticipate a production product?

David: Definitely, Q1 of 2019. That’s what we’re targeting for right now. Hopefully, we’ll be on time.

Ledge: We look forward to getting the secondary update after the production launch.