Guests:
Brian Squibb (LinkedIn)
Justin Hartung (LinkedIn)
Company: Qarik Group (Twitter)

New York-based Qarik Group was started by a team of Wall Street and Google executives and partnered with a Chicago-based investment firm, PEAK6. The company is focused on solving complex business challenges with cloud technology and tools for some of the world’s largest companies using experience and expertise. Qarik Group recently acquired Stark & Wayne, one of the most promising players in the cloud-native space helping companies with their digital transformation and cloud-native journey. We hosted two partners from the Qarik Group LLC, Brian Squibb and Justin Hartung, to learn more about the company, what does the acquisition mean for the ecosystem and what plans do they have in place to stay ahead in this dramatically evolving cloud-native space.

Here are some of the topics we covered in the show (watch it on YouTube above)

• A quick intro to the company.
• Companies often get overwhelmed with new technologies and want to use them because everyone else is using them. How does Qarik Group help such companies with staying focused on what they need vs the next shiny object in the tech space?
• Culture or people problems pose a bigger challenge than technology. How does Qarik Group look at the people problem and how does it try to solve it?
• Security has become the top priority in the cloud-native space. How is Qarik Group helping companies with building strong security practices?
• When it comes to security, it’s very important to understand the open-source software supply chain. Do companies really understand the software supply chain? How does Qarik Group help them?
• Talk about the Stark & Wayne acquisition: Do the two companies share the same value so that they continue to serve their customers?
• With major changes at Cloud Foundry, what plans does Qarik Group have for the future?

[expander_maker]

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya, and welcome to TFiR: Let’s Talk. Today, we have two guests from Qarik Group, Brian Squibb and Justin Hartung. Justin, Brian it’s great to have you both on the show.

Justin Hartung: Thank you. Thanks for having us.

Brian Squibb: Thank you so much. Really excited about this.

Swapnil Bhartiya: Yeah. I have been looking forward to talking to folks from Qarik Group ever since you folks acquired Stark & Wayne, because they are one of the most promising companies in… It goes beyond just cloud foundry, they are doing so much work. When you talk about Cloud Native space, you cannot just talk about one component, there are so many things to do. So, there are so many things we want to talk to you today. But before we go there, I want to just quickly talk about the company still. Tell me what does Qarik Group do? What do you folks all about?

Justin Hartung: Well, thank you, Swapnil. Well, Qarik Group, we call ourselves a transformation and modernization company, but that’s fluffy. So, the best way to describe it is if you go back to our genesis story. Brian and I had an incredible privilege of working together in the early days of Google Cloud, helping build out the business and working with a lot of different customers that were coming over to the cloud. And we noticed in a lot of companies that were coming, they kept asking for more than just the technology Google provided. They asked, “Can we be a little bit more like Google?” And I kept thinking to myself, “You probably don’t want to be like Google because Google is a unique kind of company.” But there are a lot of amazing aspects of Google, that when applied to an industry or a company can be very impactful. And so that’s one of the genesis is how do we bring more of that Googley-ness to companies?

Another interesting study that we did was we looked at companies that decided to go all in on Google and this is in a lot of the early days. And we would track the progress for the next 12 to 24 and 36 months. And these are large household name companies. And what’s interesting is we noticed that a lot of these companies would double or triple their market cap over the following two or three years compared to their peers in the same industries that were maybe increasing by 10 or 15%. And so it was a really stark difference between those that did and those that didn’t. And we concluded that it wasn’t necessarily the Google technology that drove this, but it was really the desire to be an innovator early, and accept something with rough edges and know that they’re going to learn along the way. And we’re going to partner and learn together so we learn from each other.

And so there’s a lot of these core things that we started seeing. The last thing that I’ll say is that we also heard it in a lot of executive briefings companies and executives say, “Can we come and leapfrog our competition?” And the problem with that is you can’t just grow up one day and be an expert in what you set out to be. It all comes back to the fundamentals. So we take all these different ingredients. That’s really the Genesis of Qarik is, “How do we start to work with companies to develop different behaviors and habits of digital native practices?” And over time that leads to a transformation across the company. And so I think that that’s the key takeaway is that we helped through delivering tangible outcomes that create the behaviors and habits, at multiple levels in the company, that lead to an ultimate transformation for a company.

Brian Squibb: Yeah. I was just going to add to that. Well, first of all, thank you so much for this interview here, it’s really great. And secondly, I was going to add that one of the things that we really focus on is that we work with our clients not for our clients. So we resist the urge to take a big SOW with super in-depth, very, very specific deliverables that stretch 12, 18 months in the future, because, honestly, you can’t really predict what’s going to be true in 12 to 18 months. So instead of looking at it that way, we try to understand, “What is it that the client is really trying to do,” as they start to get closer and closer to this notion of digital native. As Justin said, what are the next five or six things that they think they want to try? And how do we enable the team with the right technical skills and the right mentality to give it a go and feel okay about it? And that’s a combination of working with the top of the house and then also bringing the technical expertise on the ground to win over both the engineers on the ground and the executives that are running the show at the top.

Swapnil Bhartiya: So, one thing that you mentioned was that it’s not about technology it’s more about what client wants. So sometimes people get overwhelmed, about “Hey, we want Kubernetes, we want containers, we want this and that.” But the thing is, what do you really want to achieve in that? So if you really look at the company, when you talk about modernizing them, transforming them… Let’s start with a very basic, what kind of companies are you helping and how do you really help them in the journey so that it’s more or less about what they really need versus the next shiny object.

Justin Hartung: That’s a great question. And a lot of times companies do come with us thinking that they have this idea of what they want. And if you go around and talk to a bunch of people on the team, you often find that actually, there’s not a clear understanding of, “What are you trying to accomplish?” And any kind of transformation or any move to the cloud needs to be rooted in a why. Like, “What’s the outcome or the business driver that’s pushing it?” And that’s one of the things that we do. And in fact, we codify this in our Newton process where we have to start with establishing the north star. “What is the vision or the purpose of what we’re accomplishing?” And do we make sure that it’s crystal clear so everyone understands why? Because if you don’t understand the why, then things fall apart later.

Then it really helps us understand, “Okay, so given that north star, where are we, what do we need to accomplish next? And let’s just choose one small component to work on.” And then it’s focused on that. And then we measure and we improve. So it’s really, really this… There are things like you mentioned, how do you containerize something and move it to the cloud or jump or move to Kubernetes. These are great technologies that help you on this journey, but they’re not the end state. People aren’t saying, “Oh, I just have my software and I want to run it and just somewhere else,” that doesn’t give you the true benefit. But what it does do is when you start being able to jumpstart and use the cloud right away, you start learning all the muscle memory of what it means to use cloud. Because inevitably you have a situation like the first time a customer moves to cloud, they treat it like a data center because that’s the context they have.

It’s natural for humans to say, “Oh, it’s just another widget.” And of course, as I’m sure you’re well aware, if you treat a data cloud like a data center, you just get another data center. You don’t get all the elasticity and all the benefit for that business agility that the companies really want. And so that is like a stepping stone of, “How do we use these tools to really start working in the cloud?” And then we start to modernize our methodologies, the software, and we re-platform where it makes sense, we modernize or transform or re-implement where it makes sense.

Brian Squibb: I think I might add that what we really try to do, in all the areas we engage, is we try to treat the projects that we’re on like products. So for example, if we’re helping a client with a CSED system, we don’t get so caught up in the feature function of the CSED. It’s more, “Who are end users of the system?” And generally speaking, the end users are going to be the engineers that are trying to ship product within our client’s organization. And, “How do we understand what really will delight those end users? How do we figure out how to make them more productive, happier, and make the tools do more of the work and reduce the toil for them?” So it’s less about the specific end point and more about how do we, again, get back to what is it that we’re trying to accomplish here, and what is the right path we need to be on for that goal?

Swapnil Bhartiya: When we talk about this transformation as much as it’s about technology, it’s more about people, cultural aspect. People have been doing the same thing for so long companies may have challenges to either retrain them or find new talent. And then there is already a crunch, there’s a gap between supply and demand. And not only that, even the modern Cloud Native companies who call themselves totally flooded, even they are going through the whole developer, DevOps, DevSecOps… We are trying to say that we are breaking old silos. The fact is we are creating new silos. It’s still about skillset. You like security so you go to DevSecOps teams. So there are still sellers. So let’s talk about the nutrient process and how much role does the culture-human aspect plays there?

Justin Hartung: I think that the culture and human aspect, that’s an easy question. I think that’s the majority of the challenge with any of these com transformations is really, “How do we help bring people along and provide an environment for people to be amazing?” One of the analogies I like using is it’s like you’re going to a factory where those people on the factory floor are physically working with the widgets, and you’re now going to robotic automation. And so you’re going to go from a large factory with lots of people that aren’t doing really high-valued work to a smaller number of people doing really high-valued work. And that’s a transition that’s going on and so I think if we look at that analogy, companies need to recognize a few things.

One is the cost for that labor on an individual basis is going to go up because there are a lot higher skilled, but they’re also a lot more capable of so you’ve got a lot more output for it. Second is you have a lot of domain expertise on that factory floor that are actually very valuable and needed. So you have to provide an environment that allows those people to really latch on to the skills they have and learn the new skills. And some of those people are going to be able to make that transition. And you have to, of course, encourage that and reward that successfully.

We see this a lot in situations where you’re going from an operations culture to an SRE culture. Too often leaders just call the team’s SREs and think that they’re done. But a lot of people don’t realize that SREs are actually engineers as opposed to operators. And so how do you also provide them the tools, techniques, and opportunities to learn and grow?

Brian Squibb: Yeah, I was just going to add that the mentality shift is also happening on the developer side. Developers are used to developing stuff and handing it over to operations and sometimes aren’t used to the notion of having to run the things that they built. So in general, we totally agree with your assessment, Swapnil, that it’s really about the people.

So oftentimes our projects are technical in nature. We’re building CI/CD systems, we’re helping automate the whole process end-to-end. But, really, what we’re trying to do is have an excuse to have a change management conversation via a technical project, right? And we do that by bringing the best engineers we can find, Google caliber engineers, to bear on solving really, really hard problems. But then we do it by embedding directly in with the teams and taking small steps where we say, “Actually, if we take this small incremental step towards SRE,” In the context of engineering. Or on the other side, if we’re embedding in with the operations team, helping them get a little bit closer to the development. Interacting directly with them in the tooling that we’re trying to produce.

But you hit it directly on the hat, it is really about people. And if you look at the challenges that a typical organization faces, particularly in a COVID-remote-first world, where competition is super intense, supply is really low on the market right now. And firms are facing these simultaneous convergence of really hard problems to solve. You mentioned containerization in the face of the legacy fleet that isn’t containerized, but is revenue-producing with expectations for customers. So how do you think about containerizing that and up-skilling your team to do that, while moving to the cloud, while taking security as a first-class operation to heart, knowing that you can’t end up on the front page of the Wall Street Journal? So you have to increase your capacity for security across the entire software supply chain.

And you have to do all of these things simultaneously. That’s scary. It’s not so scary to take one of those things and move incrementally forward via a technical project that adds tremendous value to the firm, and repeat. That’s basically what we do. We try to build the foundation of capability, the foundation of trust within the team itself by helping them just take the first few steps. And in general, we don’t want to be there forever. We want to be there long enough for the client to pick up that capability on their own and even have a clear end date. Like, “This is the date that Qarik leaves and we’re going to be okay, because we’ve built up that capacity within the walls of our firm.”

Justin Hartung: One of the key criteria, we have success criteria for our projects is that you can kick us out because we’re no longer needed. And what we’ll actually say that, “Don’t hire us because you need more bodies to fill this. We’re going to be way too expensive, it’s not going to be strategic for you. Use us where you want to see and build the team that this is a core capability you need to be successful in the future.”

Swapnil Bhartiya: Oh, there’s one more thing that you, Brian, talked about was security. And these days we hear a lot about security. So when you do help companies with modernization transformation, everybody wants security, right? Nobody will say, “Hey, we don’t want security,” but security is something… Once again, it’s moving into the developers’ pipeline. It’s very easy to preach, but it’s very hard to practice. So where is security in your radar? How do you help them with that as well? Because security is not… You cannot just let go of it. Security is something which is a ongoing process forever.

Brian Squibb: So security is obviously front and center in everyone’s mind right now. And that situation is exacerbated by the fact that security professionals are very expensive and hard to find. Much more so if you think about security directly integrated into the flow of software engineering. So what we try to do, again, is the same thing that we mentioned before. We take our security professionals, embed them directly in with the core engineering teams. We have them articulate back to the client and work with the client’s security teams that are in place already to understand, “What is the environment that this particular client works on? How do they think about security? What are the tools that are already there in their enterprise? And how can we think about shifting left as much as possible towards the actual developer experience?” In an ideal world, there are security tools that are directly embedded within the ID, telling developers, in real time, that, “The thing that you’re about to do could potentially cause a security vulnerability, so don’t do it.”

It’s hard to do that because it’s hard to change the day-to-day behavior of the developers. IDs are a thing that you usually don’t want to mess around with, particularly in a fashion where you dictate the choice. With that said, what we try to do is inject security as far to the left as we can. So we always insist on putting it into the software supply chain in the CI/CD system, both in the build, and then obviously in the deployed.

So what we ended up doing is looking at security architecture end-to-end. “What is the security posture for the firm? What are the current threats that a firm is looking at,” combined with the things we know about based on our ear to the ground, with our security folks. And then how do we start to embed that thinking directly into the engineering team? And again, make sure that the engineers that are building the things in the first place realize that they can’t delegate the responsibility of keeping the firms safe to some extra security team. That’s part of their job every day to make sure that they are putting in a new features functions that are, to their best of their knowledge, are adhering to the best practices that the security community has. But we have to make that as easy as possible for the engineers to do. So every day, we have to try to increase the overall level of automation that we’re injecting into the system without causing too much pain and toil on the day-to-day engineering community. And it’s hard to do that.

And if you think about the context of a typical enterprise organization, there’s a myriad of security tools that are in place. So a firm like Qarik can’t come in and just say, “All of your problems will be solved if only you do X.” No, actually you have to take a sense of what’s actually going on. What is the skill level of the team on the ground? What are the things that they are looking at right now to increase the overall security of their CI/CD system? And then how can we help? How can we amplify the existing efforts or supplement things that might need supplementing?

But at the end of the day, security has to be at the top of mind for everybody involved in producing software. That was a bit of a soapbox. So sorry about that.

Swapnil Bhartiya: You used the term software supply chain. Sometime in the legacy world, they just think about binaries, you’ve got it, big [inaudible 00:16:40]. You have to deal with… The modern Cloud Native architecture is more about microservices. It’s a lot of different components framework that comes from different places. So you also have to… Even containers you don’t even know what a library is, what our frameworks are there in the container. So it’s very important to understand the whole supply chain to say… First of all, do you think that companies do understand the whole software supply chain in today’s modern world? Number two, is that, how do you help them, as you also said, that they need to understand, so it has to be an ongoing process. So what do you folks do for that awareness education aspect? Also, which once again goes back to the human-cultural problem.

Justin Hartung: I think that’s a great question. And I’ll jump on, instead of Brian, to answer this one. So two things is, do companies know their software supply chain? Oftentimes no, companies don’t understand their full software supply chain and you see this playing out time and time again, when there’s some kind of compromise and everyone’s scrambling to say, “Do we use that component? Do we use this software?” And people just don’t know, and it takes weeks of effort to sometimes uncover that. Second is what does that awareness or what do we do? And I’ll say that there’s this broad shift that we’re seeing where just like in the early days of big data, that companies had a bunch of silos of data and the concept of big data was, “How do we start to unlock the information across our company from all these silos?” We’re seeing a similar movement with software where it… I’ll call it big code, for lack of a better term of, “How do you understand where all your software is and what goes into all your software, and are you actually generating the right results with the inputs?” So we’re spending a lot of time with enterprises building platforms that actually support engineers in and visibility into their entire supply chain.

Brian Squibb: And I think in terms of helping, oftentimes some of our clients lack an end-to-end picture of what actually needs to happen for, let’s say in the extreme case, a brand new engineer arrives onsite and gets a laptop and is ready to go, how long does it take for that engineer to produce code that goes into production, and what are the steps that need to happen? And sometimes just writing down all the steps and all the things that a typical engineer has to do is eyeopening, right? And this gets us back to the notion of focusing on the user, our user is that engineer. How do we make that engineer’s onboarding experience amazing and get them as productive as possible as soon as possible, as secure as possible, using a holistic notion on software supply chain. And yes, there are going to have to be some bespoke branches of that supply chain to handle the legacy things that aren’t containerized yet that have specific deployment targets. But in general, we should start to converge our notion of, “What does it take to get software into production and make it as automated, repeatable, secure as possible?”

Swapnil Bhartiya: Looking at what you just explained, how you help companies in modernizing and transforming. Why did you folks acquire Stark & Wayne? Where does it fit in your story?

Brian Squibb: Yeah. So as with everything else, it really begins with the people. So first of all, the people at Stark & Wayne are amazing, and you’ve spent some time with them so you know what I’m saying. They have an amazing brand within the Cloud Foundry and Cloud Native space. They’ve sold some really tough problems, in particular with the notion of migrating from PCF to other places. And we looked at that and said, “Oh, wow, okay. That is pretty interesting that there’s these great people solving these similar problems to what we do.” And then we looked at it again and saw the amazing market opportunity.

If you think about all of the firms out there that are on PCF today and are trying to figure out what the next five years looks like, there’s some portion of them that are going to look for non-PCF alternatives. So that could be OCF as an opensource alternative, or there’s some nascent work that’s happening in the Google kf space. In general, they’re looking a way points to give them optionality as they move their PCF estate to something else.

And of course, as a move from PCF to something else, that fits right in to the modernization transformation story that Qarik tells and is our bread and butter. So we think of Stark & Wayne as an amazing entity on its own and we have no intention of killing the brand. We think that the brand is really amazing. In fact, we plan on enhancing it. We think that the motions that they have in the market are successful and will be much more so with some injection of capital and maybe some new ideas. And we think that there’s going to be quite a lot of opportunity for cross-selling between the Qarik modernization transformation story and the stark and Wayne PCF story.

Swapnil Bhartiya: When these kinds of acquisitions happened… And I talked to, of course, the Stark & Wayne team also, there has to be some kind of alignment with the values, the vision, the goal, the problem solving. So where do you see you folks have the same value, so you both feel that it is the same team that we are working with. A perspective of how you’re operating.

Brian Squibb: Yeah. I think it comes back to both firms have an obsession with helping clients achieve their goals, right? We both take a similar approach that we prefer strongly to work with our clients and leave our clients in a place where they can handle the task at hand on their own. We have a similar focus on hiring really great people that are good at their jobs, but also good human beings that are easy to work with and fun together. So I think that there are a lot of similarities between the way we think as humans.

And when we started interacting with them, we felt like we were at home because it was just so similar. It was everything from the way that they ask questions when we’re doing Town Halls and they’re very vocal about their questions, they’re very pointed about their questions. And that’s us too. And that’s what we’re used to from Google.

So I’d say we’re very, very aligned culturally in terms of how we think about the world. We’re aligned in terms of what we’re trying to do with our clients. Their market motions that they have with the PCF stuff that they do. They’re best in class in what they do. And we like to think that we’re best in class, what we do on the modernization transformation side too. And I think that they just… The vision fits really well together. Stark & Wayne looking to be the best possible organization to help with PCF services, us looking to be the best possible modernization transformation. Both organizations partnering effectively with all of the cloud providers. And I think with the acquisition and the combination of the two organizations, it’s strengthens our play with the cloud providers. We have deep connectivity into the major cloud providers. So do they, and we can combine the two stories to make a pretty powerful play for them. And then also for firms that are looking to keep some percentage of their state on-prem. But we find that 100% of our clients are looking to do at least some decent percentage of their estate in cloud

Swapnil Bhartiya: Introspective of how people look at Cloud Foundry, especially with Chip Childers moving out, and that Cloud Foundry will be absorbed within Linux Foundation under whichever umbrella they choose to be. But the fact is that even today, people use UNIX. Mainframe is still… If you’re doing any massive transaction, it is going through mainframe. So sometime people they don’t talk about things which are not shiny and things…. So the same thing is that the Cloud Foundry will also remain for a long time. But the fact is that market will change. Kubernetes will play a big role and then something new will come up. So if I asked you folks that, how do you see the future is going to look like? Though, one thing that COVID has told us that don’t talk about future too much at once, but just that what plans do you have for future, so that you are like, “Yes, we do know some transition will happen from PCF to other things.” So if I ask you, what plans do you have, or what does the future look like?”

Justin Hartung: What plans do we have? Well, our plans are to develop incredible learning muscles so that we can continue to… And that’s what we do with our customers, because we don’t know what the future holds. But I think there are a few patterns. One thing that I’m seeing more and more, and that we’re seeing more and more, is that initially people thought AI was just another form of data analytics, but really AI is just another form of writing software. And so as we get more to a place where technology can elevate humans to make the decisions. Like for example, an AI, you’re deciding which data do you use to make decisions on, and you feed that into the model to train it. So I think we’re seeing a similar evolution just in how software is made.

And also on the overall shift left is how do we let technology handle things on the right, so to speak, the manual processes, the manual factory floor, so to speak, so that we can start to inform and help give insights to humans to make decisions on the left. Right now, that’s more about observability and how things are working in production to make decisions, but what’s next after that? And it’s, “How do we tie in the way software’s running to the outputs of the business, and how do we then give insight so that that leadership and executives can understand, ‘Where do we invest next?’ And how do we enable that so that they can move faster?” And we’re going to see a whole slew of tools that are going to help in each of those segments, whether it be AI that’s helping augment developers to do automated paired programming. Or if it’s going to be even more thorough security and the signatures of, “How do you make sure that the code that’s authored by a specific individual is the actual code that’s then now running in production and know everything that happened between it? There’s a lot of tools that are coming up to make that even better and easier.

Brian Squibb: I completely agree with all that. And I’ll add that the notion of software supply chain I think is solidifying, or will start to solidify over the next few years. What does it actually mean to have a modern, robust end-to-end software supply chain that is appropriate for an enterprise audience? I think PCF did a fantastic job of providing an attraction for developers to really just focus on code and not have to worry about the infrastructure, the scaling, the security, the compliance. And as we enter this next chapter, whatever that might be, I think that there’s an opportunity in the market for folks to define what that next phase is.

And as folks move from PCF to other things, I think that there will be opportunities for lots of new product offerings in the software supply chain. I doubt any vendor’s going to own the software supply chain end-to-end because it’s too fragmented, too complex. But I think that there’s a lot of room for convergence on approach in the software supply chain, because right now if you go and pull a hundred enterprise customers, you’ll probably find 700 different ways of writing software, and it probably doesn’t need to be that complex and that hard and that bespoke. So my guess is that that over the next five years or so, we’ll start to see some convergence on the craft of software engineering and how to do that effectively in the software supply chain in an enterprise context.

Justin Hartung: I’ll just echo that could come. And I mentioned earlier about big code is, is we’re seeing a lot of this need where some of the companies we work with they’re decent sized companies, they have about five to 10,000 engineers. And a lot of them have millions and millions of lines of code, and we’re helping a lot of them move to systems like Monorepos, where rather than having a bunch of different things that are in silos, how do we bring them together so that you have one unified view of your entire code space? And now when someone makes a change you can easily track all the impacts that that change will have throughout your organization. So this is again, “How do we give more visibility?” And then it just forces you to build all the tooling to automate things.

Whereas when you have 10,000 different git-repos, you’re forced to use policies to keep things consistent. And we all know that policies and humans enforcing policies break down quite a bit. So a lot of companies are starting to say, “Well, okay, let’s find a way where we are almost forced to put the right tooling in so that our humans can be humans rather than having to just broadly follow policy.”

Swapnil Bhartiya: Brian, Justin, thank you so much for taking time out today. And we actually talked about so many things, so many important topics that we need to discuss in cloud and the world, because not every company is a green or a broad field deployment. They have to move from traditional legacy IT boards. So we need to talk about [inaudible 00:29:28] and those are the majority ones.

So thanks for sharing those insights, the challenges that are there and how you folks are helping them, not only with the technical solutions, but also the people solutions. And I would love to have you folks back on the show because there is so much more to discuss. So thanks for your time today.

Justin Hartung: Well, Swapnil, thank you so much for having us. It’s been a pleasure chatting with you.

Brian Squibb: It has indeed, thank you so much. Looking forward to future collaboration with you. Thank you so much.

[/expander_maker]