Fireside Chat: Creating Impact Through Partnership

There's been a fundamental shift in the way companies ingest customer data. As a consultant, Kyle Rowland, CEO of TechMentor, sees under the hood of a lot of companies. Kyle’s services have helped organizations create software faster, create more innovative products, and create higher quality products. Which is why I'm excited to talk to him about how companies are trying to solve the messy problem of customer data ingestion.

Fireside Chat Transcript

Kirat: Hey everyone, welcome to another Osmos Fireside Chat. A little bit about me. I'm Kirat Pandya. I'm the CEO at Osmos. We are building the next generation external data platform that helps organizations basically build and maintain more data relationships to scale how they deal with external data. Today I have with me Kyle Rowland, who is the CEO at TechMentor.

Kyle, welcome on board. Can you tell us more about TechMentor?

Kyle: Sure. Thanks, Kirat, for having me. I really appreciate it. It's fun to come out and chat. TechMentor, basically what we like to say is that we make building custom software products easy. So whether that means up-leveling your game in architecture or software craft or how we work together, we help to provide that discipline to get to excellence through effort. We don't pedal silver bullets. We're basically your personal trainer. So that's kind of it in a nutshell.

Kirat: Got it. That makes a ton of sense. So Kyle, the reason that, what brings us together is, Osmos, we've been seeing this fundamental shift in how companies deal with external data. What have you been seeing out there when it comes to external data and how companies deal with it?

How are companies dealing with external data?

Kyle: Yeah, it's fascinating, because there's so much going on with that. There's so many systems and they integrate in so many different and exciting sort of ways. And everything from high level military or financial things, all the way down to social media apps and how they connect. So some of the stuff that I'm seeing that's different from the past is really as, I mean it's almost obvious to say, but just the scale of data. So the amount of data that's coming through and the complexity of it just drives a lot of interesting organizational behaviors and is very fascinating from a solution space kind of thinking.

The amount of data that's coming through and the complexity of it just drives a lot of interesting organizational behaviors and is very fascinating from a solution space kind of thinking.

Kirat: That makes a ton of sense. You mentioned the scale of data. I think we've been dealing with that for... It's ever growing exponential graph that just never seems to go away.

Kyle : Yep.

Why is it so painful for companies to ingest external data?

Kirat: Beyond that side of it, what makes that the space painful from your perspective?

Kyle: Yeah. I think the complexity and the scale and everything, really to me, what it really does is drive some interesting organizational behaviors, and particularly the horizontal versus vertical thinking. So for those that aren't familiar with that, is the horizontal thinking is thinking about technical interests, orienting our architecture and our teams around, "Hey, this is the database. This is the API. This is the integration layer," versus, "This is our feature set, and this feature happens to use these technical bits."

So when you orient around the horizontal aspects rather than the feature aspects, what happens is, again, because of Conway's Law, the architecture gets monolithic, the organization gets layered in the wrong sort of way, and you have the scalability problems. So that's one of the big pain points.

Because of Conway's Law, the architecture gets monolithic, the organization gets layered in the wrong sort of way, and you have the scalability problems.

Then you also have delivery speed problems. So if you think horizontally, and your work cuts across the whole organization, then the whole organization has to get involved whenever you do a release, and that slows things down. Now again, I said the complexity of the ingestion and the integration, really it sort of hits that and makes that worse, because we as humans sort of react that way when we come up with a complex technical issue.

Kirat: Makes so much sense. You got me thinking about, you look at the biggest players in industry out there, and you'll see these two different strategies. There are companies who are like, they use this term "one blank" to describe the systems they build. "This is the one thing. Our organization will use that." Then at the other end, there's the ones that have 15 different implementations of the same solution across 15 different parts of the org. Honestly, it's interesting to see how different customers for us, from what we see, the ones who want the one platform end up with months to get started to solve anything. On the other hand, the people who go extreme on the other end and have 15, 20 different implementations, they're quick to get started, but then they have a lot of redundancies.

Kyle: Yep.

Kirat: How do you reason about that when you talk to your customers and how you help companies?

Kyle: Yeah. No, that's a fantastic point, because that also hits on... The idea that's connected to that architecturally is the microservice idea. The same exact problem comes up in that space. People get, they say, "Oh, monoliths are bad, and now we've got five billion microservices and how do we handle it?" So it's kind of the same problem. So there's a certain degree of wisdom and thinking that has to come into play to balance those things.

One of the big players out there that really a number of years ago got really overly popular and now it's maybe a little less popular is the Spotify group, when they were talking about their methodology for software development. One of the ways that I thought was really clever that they balanced that, was they broke groups down into small bits, but then they had people that talked to each other across those small bits. So it's really, whether you call it a community practice, or I don't remember what Spotify's term for it was, having that cross-communication is important while still orienting the organization around the actual capability and value you're providing to your customer.

Kirat: Yep. Yep, makes total sense. So if you apply the lens of that, we've been talking about around how external data comes into play here, you get to see under the hood of a lot of companies. How do you see companies solving this problem? What do you see out there?

How do you see companies trying to solve this problem?

Kyle: There's all the common suspects. So there's folks that go full on and solve it themselves from scratch. You've got some products out, or some companies out there, that are using products that are sort of really self-serve and not quite complete, and so they're basically just using another sort of domain language to solve for it. Then they've got beautiful tools, like Osmos, of course, that really provide a well-thought approach to actually solving this. Because there's a sort of build versus buy thing, which I think I saw blog posts from you guys recently on that, that's out there.

But it's not quite that simple of a question, because people in both the build and buy situations, I've seen both get hung up on really largely the same concerns. If that's due in part to the underlying concern of not being vertically sliced well enough, or if it's that the tool doesn't have the right opinions about how to attack the integration problem. So yeah, broad spectrum and the kind of suspects you'd expect.

Kirat: Yeah, to add to that, you got me thinking about a recent conversation I had where customers we're talking to were like, "Yeah, when it comes to build versus buy, one of the things we're always thinking about is control, and when things go wrong, what can we do?" That's usually given as one of the reasons for doing sort of the build thing.

Kyle: Yeah.

Do you really have control in a build scenario if you don't have the resources to step in and fix the problem in the first place?

Kirat: What got me thinking was, do you really have that much control in a build scenario if you don't have the resources to step in and fix the problem in the first place? Are you actually better off?

Kyle: Exactly.

Kirat: I don't know. So from that perspective, there's a bunch of common reasons people choose to build a bespoke solution. Things like, "Hey, I want to run this offline, or I need FedRAMP," or something crazy like that. What comes to mind for you other than those sort of common ones?

Kyle: Well yeah, and you mentioned that. So from a use case perspective, I think you mentioned the things that would come to mind when you need to have control of the data. So if there's a regulatory or moral ethical reason for needing to control the data. But your other point was right on as well, in that really, to me, there's a question of, do you have the time and the talent for it? And we always overestimate both of those radically usually in the software world.

There's a question of, do you have the time and the talent for it? And we always overestimate both of those radically usually in the software world.

So I think there's a really good case to make to building a bespoke solution just in general, in the sense that when you do that, if you build something, there's a lot of unknown, unpredictable business advantage that you can get out of it no matter what part of the stack that is.

Steve Jobs, in the Isaacson bio, had a really interesting principle. He called it the full widget principle. Again, just like the vertical slicing, you could blow it out proportion, and Jobs did for sure. I remember there was a story about him getting really uptight about the color of the paint on the wall of the next factory.

So you could take it to an extreme and stuff. So to me, there's always a sort of a case to, there's some unpredictable value that you can definitely get. But again, you have to be brutally honest, to use Collins's words, about your estimates, about your time and talent. To your point, if you can't step in and fix it, did you really have the time and talent to go and approach a bespoke solution?

Kirat: Yep, agreed. What you were saying got me thinking about, I think what we're seeing in the market is a shift from the hard choice of build versus buy to the next generation of software products, SaaS especially. That has enough escape patches and hook points where you can have all the controls that you need while not having to build the, quote, unquote, the hardest parts of the widget right away. Look, at some scale, if you're Google, sure, everything looks good to build, right?

Kyle: Yep.

Kirat: Another example of this that comes to mind is Tesla. Most people don't know that the early, the Model S, and I think to an extent Model X, most of the switch gear came from Mercedes.

Kyle: Oh really?

Kirat: Oh yeah, absolutely. Yeah, absolutely. Tesla's now moving towards a model of, "Hey, we're going to take raw ore in one end and put out a car on the other." But it took them a decade to get there, and they would've been dead if they tried to build the switch gear to start. So things like, "Oh, when you open the door, water gets in the switch gear. Now what?" There's all these details you have to think about. So I think build versus buy from that perspective has gotten a lot more nuanced than it used to.

Kyle: Yeah, absolutely.

Kirat: In one of your newsletters you'd mentioned... I'm going to quote here. "Every software-delivering organization in existence has areas that if improved would yield even greater value and return for their efforts." How do you see this applying to data, especially external data where you don't control one side of it?

Every software-delivering organization in existence has areas that, if improved, would yield even greater value (and return) for their efforts

Kyle: Yeah, so the areas in particular that I was talking about in the newsletter was definitely around the fundamental general areas that we talked about. So architecture, workflow automation, software craft, process. I think, like we had mentioned in the beginning, one of the big challenges with the nature of ingestion is just the impact that it has on human beings when they respond to it.

Because we've got that curve that you were talking about, where data's just getting so huge lately that it inspires such a certain kind of response, that really getting processed more and more in better shape. Everybody knows about agile now. It's 2022. We know about these things, but are we practicing them well? Can we be improving in those spaces? Is our architecture as clear as it needs to be? Again, we talked about the difference between the monolith and the microservice.

The idea that it's a continuum, and are we in the right spot on that continuum? All of those things feed into as sort of inoculation that an organization can have against, not that ingestion is a disease, but it's sort of a catalyst for some bad behaviors, that if you don't build your organization right, that you can sort of trip over.

So I think in that sense, in all of the same areas that an organization might prep itself for just general software development, the better that they're at at that, even if they do, if they're not building the ingestion solution themselves, if they're buying an off-the-shelf solution like Osmos, if they're structured in a way where they're not tripping over the idea of ingestion, they'll be even more wise about how they choose to use Osmos or whatever the solution is.

If they're structured in a way where they're not tripping over the idea of ingestion, they'll be even more wise about how they choose to use Osmos or whatever the solution is

Kirat: Yeah, it makes total sense. I keep coming back to, I keep telling our team, "The goal is not to put rails on it for customers but to give them flexible pathways that they can mold to sort of meet in the middle on process."

Kyle: Yep.

What advice would you give to companies/teams trying to solve their messy external data ingestion problem?

Kirat: So wrapping this up a little bit, what advice would you give to teams trying to solve this messy external data problem?

Kyle: Yeah. My advice, and I feel like I'm probably repeating myself a little bit here, is to

1. Really focus on the fundamentals of software
2. Partner with the people that can get your prototypes and things to market faster. Don't be too precious about building your own thing, but at the same hand, be ready to build what you need to to make the use cases that you have really shine.
3. Make sure that you're doing all of the hard thinking work to really understand your domain, the value proposition that you have for your customers, and then think about how the ingestion and the ingestion tooling can really make that more successful.

Kirat: That is so true. Having that sense of clarity of, "Hey, these are the points of value I'm delivering to my customers. Everything else is just enabling me to do that. I'm going to focus on my differentiation."

Yeah, that's so absolutely key. And you see winners and losers in every industry, the ones who got that and understood it and the ones who didn't. So yeah, it's crazy how much you see the same problem repeating itself again and again.

Kyle: It is. It really is, absolutely.

Kirat: Hey Kyle, I wanted to thank you so much for taking the time to speak with me. If people want to get in touch with you, how can they go about doing that?

Kyle: Yeah, absolutely. Kyle@TechMentor.us, or you can call me or text me at 360-328-1067, or you can go to our website at TechMentor.US.

Kirat: Fantastic. Thank you for taking the time to speak with us, Kyle. This was great.

Kyle: Yeah, this was fantastic. Thanks, Kirat.

Kirat: Yeah, absolutely. Thank you everyone for being there to tune in and check this out. So thank you.

Summary

A big thank you to Kyle over at TechMentor for speaking with us. You can learn more how they help companies improve the effectiveness of software development orgs. After evaluating Four Areas of Competence, Kyle offers coaching, collaboration, and future advisory services for organizations that are looking to multiply value.