How to Train Devs to Disrupt Industries

Not all dev orgs work in all situations. Especially if your dev org is looking to completely reshape and disrupt an entire industry.

That’s why we were so excited to talk to Chris Bee, CTO of Lessen.

Lessen is looking to change the way property owners hire vetted professionals for renovation, maintenance and turn services. That means so much of what their programmers are building hasn’t been built before.

Chris opened up about how the company trains and empowers developers to design and build things customers didn’t know they wanted. He also goes in-depth about how to bring those new ideas to market when it can seem like the ground is shifting every minute.

Episode Highlights Include:

• (1:35) Growing opportunity to solve less obvious problems
• (6:32) Engineering ride-alongs
• (13:53) Choosing a market to disrupt
• (23:13) Chris' Discover/Design/Develop/Deploy model
• (29:27) Phased approach to building products and features
• (36:35) Having engineers talk to customers & vendors

Conversation Excerpts:

Advice for team leads: don't forget the big picture:

Conor: What do you want the engineering leaders, the developers, and team members listening to take away from this conversation?

Chris: Yeah. Yeah, I think there's lots of things I could mention. I think the big thing is really... we're talking about a lot, but just the customer empathy and understanding the problems that you're trying to solve, especially as you get into engineering leadership roles or kind of mid-level engineering leadership roles. It's easy to lose sight of that, right? You're really bogged down in the details of your architecture and the precision of your monitoring, and team management, dynamic time. But while all of which are very important, being able to take a step back, look at the big picture, make sure you're prioritizing the right things, you know, because you can make a, you know, very well-reasoned argument many times for something that's purely a technical project or purely an infrastructure project that wider business stakeholders are going to say, okay, shrug, I guess we have to do this and we're going to use every engineering team to do it. But as an engineering leader, understand the big picture, especially being an early-stage company, right? And how the company makes money, how revenue is generated, and where the growth opportunities are. And keeping that frame of reference in mind is you're making prioritization decisions for your team I think is really important, which is again to back to the ride alongs to why we do that, why we get so excited to see like, here's who we're building software for. Kind of everything else is secondary. And, you know, of course, it's a balance there. You want to build robust infrastructure that's it's going to last. But in the same breath, you've got to make sure you're solving the rate problem. So that's probably the biggest thing, getting your team acclimated to a high-paced environment, getting your team acclimated to a world where there's a lot of opportunity. I think is interesting, when you're in an early-stage company, kind of the directions you can go are kind of boundless. And as a leader, help focus the team down on what the most important problems are, and what the most important areas to focus on is. I think one of the key things.

Dev methodologies are outdated, and don't really matter:

Conor: What prompted you to come up with this phased approach to how you're building product features and working with your engineering team?

Chris: Yeah, I mean, it just has come from the years or decades, I guess, of experience here, where you start to realize that you do need to have some structure around how you approach problems and how you build software, yourself you form a life cycle. And surprisingly, you know, there really isn't a sort of golden process out there that is the standard. There's you know, everybody talks about Agile, Scrum, and this sort of thing. And like, yes, sure. It's, I don't know, 22 years old now or something like that right there. Jon Manifested in 2001, I believe. So, you know, and coming from a time of waterfall and more boxed software with hard release dates and this sort of thing into more of a web world made a lot of sense at the time. But that is still like the predominant framework that people refer to, which there are merits to it and there are pieces to it that make a lot of sense and we leverage some of that in like that developed phase. But it doesn't account for how you do user research. How do you do a lot of your discovery? How do you make sure you're working on the right things? Adding code to stuff and committing to a road map because, you know, like it or not, you know, most business stakeholders and operational partners sitting at the end of the day, the main question you want to know is when is it going to be done? Like, that's just the question as a leader, you kind of have to be able to answer whether you like it or not. The answer of, Oh, we're running this agile process and it's on our backlog and it'll come up in the next couple of sprints like that doesn't fly. A lot of times when you've got specific deliverables, you're committing to customers and you've got a marketing plan you needed to stand behind, or you've got expectations from users on when someone's going be available, they might be deprecating another tool to use what we're building. So yeah, we have failed to produce dates that we can stand behind. So from some of that pressure, you start to create the steps needed to get to a point where we can confidently commit in, in timelines and road maps.