Security Confidential S11 E7 Ben Johnson

Manoj Tandon (00:01.207)
Hello everyone, this is Manoj Tandon, your host. Welcome to another episode of Dark Rhino Security, Security Confidential. Today we have an awesome guest joining us. He is Ben Johnson. Ben is a serial entrepreneur. He’s got a long track record of success and a ton of hands-on open source programming experience. He’s 20 plus years as a software developer and leader. Ben is the CEO and founder of Particle 41.

a dev firm founded by industry veterans that aims to help companies accelerate their initiatives through software development, DevOps, and data science. And I’m really, I took a pause there because that name particle 41 is really interesting. I want to know that in fact, welcome to the show, Ben. Thank you for taking time out of your busy day to join us.

Ben Johnson (00:51.379)
Yes

Ben Johnson (00:54.646)
Yeah, Manoj, thanks for having me. I’m really happy to be talking to a security professional such as yourselves.

Manoj Tandon (01:00.435)
Oh, I don’t know if we’d go so far as saying as we’re professionals, but sure, we’re in the security space. But I gotta tell you, particle 41, I have to ask about this. With a name like that, where did that come from?

Ben Johnson (01:05.341)
Hahaha

Ben Johnson (01:19.606)
Sure, no problem. So I was reading a Daniel Suarez book and in the opening chapter there’s a lab 41 that creates antigravity, right? So I’m a little bit of a sci-fi novel. But then I started looking into, okay, this idea of something accompanied by a number. We started looking at the periodic table and the 41st element is an element called niobium.

Manoj Tandon (01:32.181)
Oh.

Manoj Tandon (01:48.052)
Okay?

Ben Johnson (01:48.278)
And in the metallurgical process, niobium is added to steel and it makes steel stronger, gives it a little bit of a flexibility, and it also gives it a sheen. So you can anodize niobium and make it blue, depending on how you anodize it. So in that kind of foundry process, we found this usefulness of you adding small amounts of niobium to your craft there, makes it

maybe look a little better, stronger. And so we like this idea of adding Particle 41 to your business, maybe stronger and more flexible. And so we kind of gravitated towards that concept and have created a brand for.

Manoj Tandon (02:31.415)
very cool and of course the domain name had to be available as well.

Ben Johnson (02:36.394)
Of course, of course, yeah, all those squatters out there, you gotta get, you gotta be original.

Manoj Tandon (02:41.943)
You do. I’ve done five companies myself, Ben, and I kid you not, one of the things we’ve thought of so many cool names, but a lot of times the domain is not available, as silly as that sounds. But give us a little, tell our audience a little bit about yourself. CEO now, you’ve been a leader and you’ve actually been a developer too. So what’s your journey?

Ben Johnson (02:57.198)
Sure.

Ben Johnson (03:11.786)
Yeah, so typically I work with, or in my past, I’ve worked with early stage companies. I built an online travel company right out of college called One Travel. Brand is still around today. I went from there to a travel marketing company. And hang on one second, I’m gonna let my dog out. This will have to be edited.

Manoj Tandon (03:32.812)
No problem.

Ben Johnson (03:39.626)
Yeah, so then I started a travel marketing company called Travel Ad Network, was one of the first vertical ad networks. So think of all these travel guide publishers and travel advertisers. We created the technology platform for the travel bloggers to monetize their content through well-targeted ads. So I was in the online advertising dark art for a while. I did a similar type of company in finance.

And then most recently I did a legal services startup and sold it to legal zoom And so I’ve been industry wise I’ve been a little bit all over the place But what emerged from that was one my relationship with an Indian national gentleman named SD. So we are partners in the business He’s in India. I’m here And he and I had been working together for 20 years I’ve since partnered with two other CTO types. And so our business is run by industry veterans what really means is we’re

Manoj Tandon (04:14.551)
Wow.

Ben Johnson (04:38.562)
four CTOs that have run Fortune 5000 businesses or had successful exits. And I started Particle 41 in 2012 really out of a desire to create the kind of teams that I like to work with as a CTO or technical co-founder. I wanted to start to create those kinds of teams. And of course my network kept calling me up and saying, hey, can I have one of those teams? And so it did kind of fall into place.

Manoj Tandon (05:04.695)
Eve.

Ben Johnson (05:08.367)
And then over the years, we’ve diversified into the DevOps, software engineering and data sciences, our three core service areas.

Manoj Tandon (05:15.315)
Oh, very cool. Very interesting story there. I got to ask you, in your ideas, when you started the travel firm or legal firm online, what was the origin of your ideas? What’s your inspiration? What drove you?

Ben Johnson (05:33.898)
Yeah, that’s a great question. I don’t think I can take credit for the ideas. Normally when you’re a technical co-founder, and I certainly am, I like to be a running back behind a really good blocker. Or the running back paired with a really good QB. So football analogy, American football analogy here. But the legal services startup, I actually joined that on a bet because the other founder,

said if I went and checked Particle 41 LLC with the state of Texas, it wouldn’t be in good standing because most people in their first couple years of business, they don’t do their annual reports or the necessary secretary of state things. And so the state puts you in a kind of a default status. And so certain enough, I went and checked online, I was in default status and I called him back and he said, see, this is the opportunity we have.

Manoj Tandon (06:23.075)
Okay.

Ben Johnson (06:31.29)
to make sure that people stay in good standing with the Secretary of State. And sure enough, that turned out to be a really good venture and idea. So we really like to give the ideas of our clients, you know, a fuel and really embrace their ideas and let them provide the direction while we manage the execution of the solution.

Manoj Tandon (06:52.259)
Okay, that’s very, very cool. But that also puts, there’s a heavy responsibility on you because the execution is equally critical. It’s one thing to have a good idea, but if the execution is poor, then you’re not gonna have much success out there and you’re doing core dev.

Ben Johnson (07:12.042)
Yeah, for sure. And, you know, that’s really our privilege to be under the pressure to execute well. And so we’re happy to do that. That’s what we want. I’ve always I always say, you know, we love to crush the mountains of work. So if we can get all that work organized into a backlog somewhere and just go after it, that’s where we do our best. In fact, my teams are the healthiest when they are overloaded with work. And so that’s really the part we like.

Manoj Tandon (07:42.807)
So there’s an innate sense of urgency on all of them to get it done, get it done well.

Ben Johnson (07:48.37)
Yeah, our core values are visibility and velocity. Those are our first two. Vision is our third. But velocity and visibility are kind of baked into the way we execute our service. And very important to all of us, an internal mantra is make everyday count. And we feel like if we do that in the software development process, then we gain the result of those three things. The first one is the ability to see

visibility, velocity, and vision, we get dependability, and that’s what we really want to be perceived as the most, is a dependable part.

Manoj Tandon (08:25.547)
And that brings us to a question here. One of the things with outsourcing DevOps, and I’m gonna speak from my own personal experience, is often…

Manoj Tandon (08:39.611)
If you’re able to black box it and make the specification really tight, then it can work if you have well-defined inputs and outputs. But if you’re having them take an outsource party, take the creative element of what it should look like, we’ve had struggles with that in the past. Now, maybe it’s a cultural thing with overseas and how overseas cultures work.

But it seems like you might have had this thing figured out. So where do companies go wrong? You know, what are some myths here in DevOps that we believe, just like what I described, that are not true?

Ben Johnson (09:20.11)
Sure. Yeah, so I think one of the misconceptions about DevOps is that DevOps is solely about tools. I think that’s a fundamental incorrect thinking. Tools are a big part of DevOps, but they’re not the end-all be-all. Really, DevOps is a methodology. It’s about communication. It’s about breaking down silos. It’s not just about…

Manoj Tandon (09:32.48)
Okay.

Ben Johnson (09:48.21)
about the tools. And inevitably in every DevOps conversation, there’s this big tools discussion. I think a couple of really helpful players in the space have put this kind of like periodic table of elements together where all of the different options for version control, for example, were in a row, you know, in a column down this periodic table. And so sure, there are a ton of tools.

But I think it’s more about the process and the communication and this idea of continuous improvement and being part of that and having the DevOps teammates come alongside the developers and help them focus on their features. But then while they’re focused on feature development and velocity, they need to make their needs visible to the rest of the team. And…

And then we’ll always have this healthy discussion about, is it the platform, is it the code, and how can we work together to improve both simultaneously? So I hope that answered your question. I think…

Manoj Tandon (10:54.519)
So how do you, yeah, it does.

How do you get into the head of your client, Ben? Because ultimately, if you’re developing an application for us, we might have some starry-eyed vision for it, and we may not be very good at articulating it. It’s like us saying, hey, you know what? I want a mobile app that does A, B, C, and D, and you’re like, okay, first of all, Minoj, that’s not gonna work. But there’s a vision, I guess, in our minds and a context. How do you get that?

translated into feature development at the developer level. That’s a big bridge.

Ben Johnson (11:35.79)
Sure. So there’s always this high level to the actionable stories and there’s a product owner role, kind of this product person in between is just so key. The organizations that have those individuals, they’re super fortunate, those bridge type roles. We have folks like that can be incorporated into a client engagement. And we have frameworks for things like total cost of ownership analysis, which is really

fancy name for a scope analysis to take the features that you’re thinking about, deconstruct them a level, t-shirt size them, figure out the anatomy of a team, put that on a Gantt chart, and that’s kind of your commercial reality, right? You have these dreams, these features, we’ve t-shirt sized them, we’ve done some estimation theory on them. And now we’ll give you this thing that every C team wants, which is this Gantt chart of possibility.

And it’ll also come with an equation that based on, you know, this much work with this kind of team, we think you could be about here by when. And then the client obviously also has levers. So they could say, well, I really want to work on two things at once, which means you’re talking about two scrum teams and then how that shifts the plan. So one of the first things we do in an engagement is think about that commercial plan or the commercial outcome that’s desired.

And then we work together with the product owner and the dev team to break that down into actionable stories. And we’re accountable to make sure that the sprints don’t get away from the project schedule. And when you’re a service company, the great thing is you get to focus on that, the means in which the service is executed. When you’re internal to a company, say you’re on a team and you have a bunch of internal engineers, you’re all.

W2 employees of the same company, that company really cares about some very different things than the craft of software development. They care about their share price, they care about their cost of operations. There’s a lot of other things that they care about. But inside Particle 41, we really care about those methods and methodologies of the craftsmanship that we’re executing for our clients. And since we think about that, we think about how to have good engagements.

Ben Johnson (14:00.33)
we come with a certain bag of consulting tricks that maybe isn’t obvious to folks that are working on one or two big initiatives a year. We’re seeing 20 big initiatives happen simultaneously. So it’s an economy of scale that working with somebody like us gives you.

Manoj Tandon (14:19.863)
Ben, that is a fantastic description of your process and your approach. And it’s very cool to hear that you have mastered that approach. So then the question becomes, is in a successful development cycle, is it the t-shirt size stories or the specifications, let me say, or is it the process that’s going to really determine the outcome, which is more important here?

Ben Johnson (14:50.122)
Yeah, and unfortunately, you can’t disambiguate those. We can have a fun dichotomistic discussion about the dichotomy between process and specification. But those two things go very well. What we would say is that the specification takes a slight backseat because the agile process is so flexible. So we would rather.

speak to you and get enough understanding of a core capability that you want to target, something that the platform needs, and we could go ahead and get started on that. This kind of, we know we’re going to need something that does this. You’re trying to work on an e-commerce company, we know you’re going to need a shopping cart or a base set of things. But then we really need the process to kind of pull out feedback.

And we need to do that agile feedback loop. And we really do need subject matter experts from the business who know their business and are willing to make a decision. The way we like to describe it is the client provides direction. We need that direction because you are in the end, you own your business. You need to own the direction that you want the software to go. You also own prioritization and a bunch of other things. So…

We certainly don’t want to be in a rudderless ship or a driverless car. So specification, I think, is how you bring in those critical details. But we do create a process that prevents having to have all those specifications up front. We want to create a process that learns from the customer, learns from your internal stakeholders, and moves and adapts quickly.

I would, just because of where we sit in the game here, I would index on process, but I can tell you that my introductory proposal underscores the importance of folks on engagement from the customer that are involved in the feedback loop or providing specification, alignment, clarity, validation, those types of things, because those are just things that only the owner of a project can provide.

Manoj Tandon (17:07.371)
Absolutely. And it’s the fact that you’re able to hold that project owner accountable because there has to be some accountability there on their side in terms of being able to provide that guidance. Then what you’re suggesting as an agile approach makes all the sense in the world. And it avoids the entire pitfall of analysis paralysis. There’s so much of that happens in these dev projects where they can’t get started because they can’t.

They’re like, well, once we have the specification, we’ll get going on this.

Ben Johnson (17:39.946)
Yeah, one thing I’d also add is we’ve seen both. We’ve seen the, we’re building up requirements so much so that probably all of this is Yagny. Yagny is an actor, you ain’t gonna need it, right? And so they, you know, it’s really hard once somebody kind of dreams up their master plan to get them to agree on a first release. And so, you know, it feels like I’m trying to have something premature. And so you’re trying to kind of

ratcheted down to that MVP or that first release, just so we have a good starting place and everyone can feel accomplishment. But we always know what that end goal is. And we’ve also seen the opposite, which is internal teams who are so focused on building the perfect system, that they lose alignment with the core business objective.

And so they may be building for this amazing scale, but there hasn’t even been a go-to market yet. And so we also see that the solution needs to be right sized for what the business is really trying to accomplish. And we’ve recovered some projects that were just over-engineered. And so I think the over-speccing and the over-engineering can both happen if you’re not careful.

Manoj Tandon (18:58.411)
Yeah, and they’re both, that’s worth the price of admission here. Things to avoid and know about before you go into this and you’ll have a much better outcome. Having you guys at Particle 41, when you started this discussion, you said you wanted to build teams that you wanted to work with. I’m paraphrasing, but that’s just a bit. What makes a great DevOps team? Are there certain…

characteristics of the participants.

Ben Johnson (19:33.71)
I think a great DevOps team is one that’s really focused on continuous improvement. The idea of blamelessness is something that I think makes a really good DevOps team. That doesn’t necessarily come from the team themselves. And so I’ll explain blamelessness just a little bit. And I’ll use…

Manoj Tandon (19:59.811)
Peace.

Ben Johnson (20:01.626)
I’ll use a medical metaphor here. It used to be in medicine. You’d go to the medicine cabinet in the ER and something that would help you would be right next to something that could kill you. Both things started with the letter A because it was in alphabetical order. Then you’re in the heat of an emergency and a ER nurse grabs the wrong one.

and then doses the patient with the wrong thing. And there’s a horrible, fatal, tragic complication in the emergency room. Well, the issue with blame is that if you said, hey, ER nurse, you did the wrong thing. It’s all your fault. And even if they said, yeah, I grabbed the wrong one, I dosed them, that’s the root cause. We now know what happened and I’m to blame. Unfortunately, that person would be in…

could potentially be in some really serious legal issue, you know, life ruined over a simple mistake. And so blamelessness is the idea of saying, okay, at least we know how this happened, but what actually happened, or the way to actually improve is to say, man, the system really set that person up for failure by putting those two medicines right next to each other. A mistake could have occurred.

Manoj Tandon (21:00.511)
Yes Yeah

Ben Johnson (21:27.642)
And so we need to now separate these medicines. We need to think of a different framework other than alphabetical order. We need to change this environment so that someone can’t make this critical mistake. So the question in IT would be, if somebody came in and tapped on the keyboard and down the system, production has crashed and it takes a few hours to get back up. And then there’s a post-mortem discussion.

And Jimmy, he says, I made a mistake. Well, what if that happened again? Jimmy made that a second time or Jimmy made that a third time. Eventually, Jimmy’s going to get fired. The organization has done nothing except lose somebody who was willing to make changes and somebody who probably had the expertise to make those changes. And so the idea of blamelessness is saying, OK, even if we have human error, we’re going to pull blame out of the situation.

Okay, shouldn’t we be responsible for putting Jimmy in that situation three, four times? And we need to make some changes to the system. So I think a general understanding of that, that DevOps folks are not there to flip switches and keep the system alive through, you know, system style defibrillator, you know, continue to shock the system to make sure that it stays up and running, but they’re really there to make sure that the

Manoj Tandon (22:46.886)
Yeah.

Ben Johnson (22:52.43)
platform is supporting change and that change can be can be done safely and quickly. And so DevOps teams are measured on how fast they recover from incidents and how well they work together with the dev team and keep everybody kind of in line and not blaming each other. And we look for those root causes and those improvements.

Manoj Tandon (23:19.659)
You know, what you described there is even a great approach to leadership, Ben. Now, if you can, that the approach of blamelessness, I can see it having a lot of merit and value in accelerating continuous improvement and enabling open dialogues in teams in very difficult situations.

maybe reduce the CYA factor a little bit.

Ben Johnson (23:53.182)
Yeah, perhaps. I do think that regardless, humans need to be, I’m a big ownership person and just ownership is, you know, do you own it, then you own it. And so, you know, extreme ownership is important to me. And so the humans involved, while they can’t be blamed for something going wrong, because normally when something goes wrong, it’s a bunch of different factors coming together. It’s not just one thing.

So we extract that, but then we put in this amount of responsibility. Like you guys are responsible for executing the continuous improvement. So we are universally responsible or maybe even we individually own something. That doesn’t go away just because we took blameless, uh, you know, just because we implemented a blameless culture. We just said that we wouldn’t stop with.

Jimmy did something and it broke the system. We would continue to find out how can we be responsible as a team and as individuals to carry through and make it better. So, it is a fact as a leader that you also have to tell people when they are performing below expectations. And so blamelessness is not a culture that takes that out, takes away responsibility.

Manoj Tandon (25:09.335)
Yep, sure.

Manoj Tandon (25:18.192)
You just mentioned extreme ownership. Please dive into that a little bit you believe in

Ben Johnson (25:24.343)
Yeah, I feel like extreme ownership is a little bit cliche. I’m a fan of Jocko Willnick and my team has heard me talk about this stuff so much they roll their eyes at me now. But extreme ownership is just this idea of really taking responsibility for what is put under your control.

Manoj Tandon (25:37.091)
Well, I still hope they listen to this podcast. Ha ha ha.

Ben Johnson (25:52.746)
The way I like to explain it is imagine that you’re frustrated with your boss. You’re like, man, you know, I’m just, I’m in this bad situation and it’s all my boss’s fault. If you just took for a minute and said, well, what if you were your boss? What would you tell your boss to do? Or what if you were your boss’s boss? What would you tell your boss to do? And then think about that for a minute, because a lot of us just have, we have a funk with authority, right? Like.

We have this authority, they’re asking us to do stuff we’re not necessarily bought in on. But if you just took a minute to think, what would you want your boss to do? So if it’s, I really want them to hire an additional person on my team, because then I could meet my goals. Why don’t you go tell them that? Because in many cases, we’re kind of over here slogging away and we’re not actually taking ownership of our area. We’re just looking for who to blame. Oh, it’s not me, it’s them.

It’s a very natural thing. And so taking a minute to say, okay, what, what could the company do for me to help me? What are my needs? And then going and telling your boss like, Hey, this is what I need from you. Many times. You realize that what you want your boss to do, you could actually do yourself. You could provide more strategy. You could manage up and say, this is really the plan. I think we should, should do these types of tasks. Can’t be left alone. They’re being ignored right now.

Those are things that you might want your boss to own, but you in fact own that. And probably they’re expecting you to own that as well. So that’s what I think of extreme ownership is don’t limit yourself to a role, but think what you want the role above you to do and then see if you can do that or you can ask them and tell them that you need them to do.

Manoj Tandon (27:39.175)
When you instantiate this on a team, do you get any pushback from people?

Ben Johnson (27:47.258)
I do, but normally that pushback is rolled up in a capability issue. Like folks don’t have a framework. They don’t have a way of thinking about what they need. The problem is too abstract. And so that’s, that’s usually not necessarily a, an ownership problem, but some training is needed or something. And so the pushback usually comes from trying to figure how to make those tasks seem easier.

Manoj Tandon (28:13.62)
Okay. And.

Getting back to the DevOps process, you had mentioned that having those bridge type people is people are organizations are lucky if they have those. If they don’t, are you guys at Particle 41 providing them as part of your development cycle and embedding them into the client’s work? With some of these.

Ben Johnson (28:21.654)
Yeah.

Ben Johnson (28:40.982)
Absolutely. So since we get to see multiple engagements, I mean, if you’re an enterprise and you decide to do a container, you know, an app modernization and you want containers, you’re going to roll out Kubernetes and you’re going to roll it out once. We’ve rolled it out 15 times. So by working with us, we have reference architectures and we can kind of show reference architectures to the stakeholders and the technical folks at a client and say,

We call our Kubernetes our main kind of flagship container architecture. We call it titanium. And then we have a lighter weight one that’s probably more appropriate for a startup or smaller app. And we call that aluminum. And so we bring these reference architectures with us and say, hey, here’s a starting place. Can we get started on this? And most of the time, yes. But we need a different type of database or we have these other things that we’re thinking about as…

dependencies. And so then we incorporate those very easy for us to add, add those nuances, but we at least start with a great best practice. And that’s the wonderful thing about DevOps is you have people all over the world trying to get better and better at this cloud stuff. And so we can bring those best practices with us. And that usually closes the gap really quick.

Manoj Tandon (30:04.695)
So let me ask you, in your opinion, you’ve done so many app devs, it’s probably uncountable. Is there a benefit to being first to market with a concept?

Or what have, was just your experience showing you? I’m sure you’ve run into this.

Ben Johnson (30:22.397)
Unh.

Ben Johnson (30:26.082)
Sure. I think it is, I think the best market example is like Uber versus Lyft, right? So you have Lyft as the second comer. Uber really pioneered the whole idea of the two-sided marketplace and transportation. If you’re Lyft, are you disappointed about competing there? I don’t think you are. I think you also got that benefit of that pioneer, right, to kind of burst through.

So I think depending on your idea, you kind of have to decide which one you are. Chances are if you are first, there’s gonna be somebody right on your tail. And so I think you can be the second comer and kind of follow along. But you also understand the size of the market. Like you’ll probably always be a split of the market share rather than the market share itself.

Manoj Tandon (31:24.483)
which monetization and that’s a whole topic in itself. But I’m curious since you’ve worked with open source, how do you monetize? Give us some strategies. How do you monetize open source?

Ben Johnson (31:43.638)
So there are a bunch of different patterns that we’ve seen. So we have seen dual licensing, you know, pretty often where, you know, you can use it for free, but you don’t get support. You want support or a commercial license. So we’ve seen that. Some are, you know, some make a lot of sense and some don’t, right? The dual licensing, like…

The one I don’t like is, well, I want to use this for real customers rather than some kind of dev project. And that always seems kind of vague to me. But most enterprises need to have support in order for them to maintain their compliance rules. So they will go ahead and upgrade to the commercial license just out of a safety measure or a safe passage. And so certainly we see that support and maintenance.

come in as a monetization strategy. You also see consulting and customization where you’re not necessarily charged for the product itself, but the services around it. Of course, you know, your big NetSuite, Salesforce, those kinds of things have a whole consulting ecosystem associated with them. And so this, you know, AWS, becoming an Amazon preferred partner.

is something that you seek after so that you can help with the adoption and charge for your service. There’s also premium features and add-ons. So maybe a particular part of the open source project that moves you into a paid strategy. And then you’d also see hosting, like if you want to be hosted on our cloud, MongoDB.

is a great example of this. I really like their Mongo Atlas product, and it’s a managed cloud installation of the MongoDB database. It answers that idea of being a managed service. It is a managed service, it’s managed by Mongo themselves. Then you just use a VPC peering to get access to it in your AWS environment. I think that’s a great success story of…

Ben Johnson (34:05.878)
using the hosting and support of that. Another great example is WordPress is a free open source tool, but Atomic is like the product side, and so it’s a non-for-profit entity paired with a for-profit entity. And I don’t think you’ll hear any complaints for them on how they’ve structured that. So these are some ideas with how to monetize open source.

Manoj Tandon (34:31.907)
that you know in the cyber security industry we have a lot of open source tools that are available and this that I wanted our audience to hear it from someone who’s been in this business as to how someone’s got to make money on this somewhere otherwise they can’t keep developing you can’t just be all free all the time

Ben Johnson (34:52.702)
Yeah, but the beauty of the open source is the collaboration. And when the idea is young, you’re getting a bunch of free feedback. You’re getting almost like free specification to fill the thing out with features. And I think that early stage community building can be totally valuable. And then certainly the businesses that need that extra insurance are going to pay for the support. And

you know, pay to have access to the people who built it.

Manoj Tandon (35:25.603)
There’s one element that we have talked about on the show where design for security, and since we’re a cybersecurity podcast, we’re a little biased on this thing, but we often hear anecdotally, we don’t have formal numbers that security is usually an afterthought in application development.

Is that genuinely usually the case or is it more that it’s just not understood what security needs to look like for the story that’s being told by that application?

Ben Johnson (36:08.238)
I will say that the maturity of a product and its security usually go hand in hand. One thing we’re working, since you’ll understand this, one thing that we’re really working with all of our customers on, and we have a DevOps model, a DevOps maturity model, and it has five levels. And you know, level one, you’re rolling your own all over the place and you’re just deploying your applications with some repeatability.

By level two, you’re at least starting to get the infrastructure included in there. You’ve codified your infrastructure. One of the kind of determining factors to go from level two of our opinionated maturity model is whether you’re doing static code analysis. Are you looking at the supply chain of that code coming in? And we saw Neo4j, we’ve seen these things pop up from time to time. And it’s so,

I’d just get out the box of popcorn because you’re watching people become aware that they’ve just pulled in all this code from unknown sources and they just trusted it blindly. We’ve also worked with a few partners that knew about that because they were following our recommendation to do the static code scanning. Then they could tell where all the Neo4j stuff was, which is great. Yeah, log4j.

Manoj Tandon (37:12.78)
right.

Ben Johnson (37:32.598)
But it’s all over the place. They knew where it was. But then their high availability of their build and release system wasn’t quite there because they had to go release everything in a matter of a few days. So concurrency in the software deployment pipeline was way below what it needed to be. I mean, thousands of applications for this particular enterprise.

And if they had to go release all thousand, I mean, that’s just, you’re releasing one at a time, mostly there’s no concurrency in typical daily business. But when this emergency raised its head, the great thing was they knew where the problems were the next level of difficulty was they need multiple Jenkins servers. They need a load balance. They needed more runners to push the code. They’re just, they just weren’t ready for a full rollout of every application. Even some of the historically old ones.

So that was a really just a really cool learning. But so we see static code analysis as an afterthought. The great thing about the DevOps process is you’re just kind of plugging in to that existing pipeline. So static code analysis, sonar cube, check marks, JFrog has a great one. These are great just things to plug in. We’re actually

really great partners with JFrog. We love some of their tooling and so that’ll plug into and kind of help you create that fully secure kind of DevSecOps process. The developers and the development frameworks should not be treating that like a second-class citizen. I mean most of the frameworks these days are preventing SQL injection.

They’re thinking about some of that thing. And we’re big on software development frameworks. We want to be using, you know, if we’re on PHP, we’re trying to use Laravel. If we’re on Ruby, we’re going to use Rails. If we’re on, you know, we want to follow the best practice for that particular type of coding. So we definitely want to leverage the open source framework that pairs with the language we’re trying to work in.

Ben Johnson (39:47.178)
And by doing so, we bring the security learnings from the framework with us. And then right around go-to-market time, we want to get pen testing rolling. We want to get some of that offensive testing. Alert Logic is great to have on the cloud environment to make sure that all the I’s are dotted and T’s are crossed with the way that your AWS is set up. So my guess is developers…

Their number one goal is to crank out features. They need to crank out features. So the surrounding system needs to keep them safe. And we need to enable them to crank features. Velocity of features is the number one KPI for a developer, right? At the end of a sprint, I’m measured by my story points. And so we need to create a system for developers to hit their story point goals, sprint after sprint after sprint. We can’t be…

Manoj Tandon (40:33.827)
You’re right.

Ben Johnson (40:43.05)
You know constantly distracting them with this other stuff because it just we’re asking for favors and asking for favors never works So as a DevOps team, you know We want to take care of some of those things by plugging it into the process and shifting it You’ll hear that shifting left, you know We want to hear see all that come in early so that if there are mistakes they can be easily correct

Manoj Tandon (41:08.043)
Yeah, because oftentimes, like as we saw with Zoom, when they hadn’t designed the system for security, it was a substantial heavy lift for that organization to go back and redo.

Ben Johnson (41:20.306)
Yeah, that’s a great example. Yeah. I think the offensive testing is really important right around go to market. And there’s so many great partners like yourself that would gladly run some pen testing, help people do some offensive checking. And so yeah, we encourage that right around that go to market phase so that you can see those things and find those things.

Manoj Tandon (41:46.239)
What do you think about the Biden administration’s plan to hold developers or the software developer, not the individual, but the company responsible for security gaps that arise in the system?

Ben Johnson (42:02.961)
I think that matches in with the idea of blamelessness and ownership. As a company, I am responsible for the customer data. The customers entrust that with me. Then, as the brand, I am responsible. I think we see that in most announcements from a brand.

you know, where it’s pretty buried if they say, well, we were working with a consulting company and the consulting company messed up. It’s typically not a time to shift blame. It’s a time to say, hey, this happened on my watch and, you know, we’re doing things to improve this. So yeah, I think the brand that’s got the terms and conditions and the privacy policy is the right level of responsibility.

Um, you know, of course, um, you know, we, we also want to take ownership and responsibility if we introduce errors or omissions and take care of that as well. So I think we just got to help each other. It’s a crazy world and the, and the bad actors are always getting smarter. So we need

Manoj Tandon (43:17.671)
Oh yeah, they’re a very intelligent group of people. Right? This is the run-of-the-mill mugger that’s coming along the street saying…

Ben Johnson (43:21.839)
Right, right.

Ben Johnson (43:27.594)
That’s right. That’s right. There’s a level of sophistication. And so a good process probably too is bug bounties, you know, go ahead and have a vehicle because it may not be the person who finds the issue may not really have mal intent. And if you have a bad buddy about bug bounty program that’s available, and I was just speaking to a firm this week on a managed bug bounty.

I think they’re on the early stage of having a really cool SAS tool that you kind of just drop in and boom, you have a bug bounty terms and conditions, everything about your bug bounty program already set up. And so those independent third party researchers that may sit on the fence between black and white hat testing, they go, oh, bug bounty program. All right, here’s what we found. It’s all, you know, encapsulated within there. You give them a reward.

for finding the issue and making you aware of it. So I think bug bounty programs are a really cool thing too.

Manoj Tandon (44:32.459)
I think that the tricky part of what’s being proposed and holding software developers responsible is the heavy use of open source libraries in a lot of dev cycles, right? I mean…

How far does it go? Like, where does it?

we’re using off the shelf libraries. So, you know, if Java has a problem, like we saw in the log4j application, then there was, we used the platform and now where does the accountability lie? I think there needs to be some delineation there as to, you know, I like the concept of blamelessness, but I don’t know that attorneys will like that concept.

that they are motivated a little differently.

Ben Johnson (45:25.615)
Sure. And I generally want, as a capitalist here, I generally want the consumer to decide. So if there’s enough regulation to at least preventing me from being secretive, I do like the idea that if you have an issue, you need to report it to the users.

Manoj Tandon (45:48.045)
Yes.

Ben Johnson (45:49.194)
And so this kind of negligence is a legal construct that already exists. We don’t need to add to it. The idea, though, that there’s extra layers of regulation usually gets messed up by age, but they don’t age well. Even whenever I help clients with CAPEX, they’re looking at accounting laws and accounting gap regulations that were written.

before agile was even a thing. So they have very firm language around the definition cycle or the planning cycle, the work cycle and the maintenance cycle. And these are in-gap accounting and then you apply agile to it and you’re like, whoa, what is this? Right? And so a lot of these regulations, they just don’t age well. So I think that will have to be that there could be some pitfalls. And so I would agree with you.

Manoj Tandon (46:20.067)
Sure.

Ben Johnson (46:47.054)
But if we are disclosing these things to the consumer and the consumer says, Whoa, Facebook is not being safe with my data, then Facebook will see a retraction in market share and the kind of the population will decide.

Manoj Tandon (47:03.307)
like that part of it. I think that that’s fair. Let the marketplace, the market makes its own decisions and let the market make that determination. I just, you know, in a past life, I was in the aircraft industry and I saw the general aviation industry got killed off because attorneys sued them into oblivion. It had a horrible ending.

Ben Johnson (47:06.143)
Yeah.

Ben Johnson (47:14.487)
Yeah.

Manoj Tandon (47:31.071)
in many respects. And now it’s come back, but it’s no longer true that an average American can go buy an airplane. And that used to be true. There was a time when it was true. And it has to do with liability. And it has to do with legal teams seeing an opportunity to mine for gold. And that’s the only thing that worries me.

Ben Johnson (47:53.622)
Yeah, it will work. It will work. I mean, you know, if you were traveling 10 years ago, and you wanted to get something healthy to eat in an airport, you were just out of luck. You know, you had donuts and pizza, those were your options. Now you go to the airport, that you know, if you’re in a good airport, you know, most airports will have a healthy restaurant in there. And certainly, if you go into the convenience stores, there’s at least some healthy snacks.

Manoj Tandon (48:05.737)
Yeah.

Ben Johnson (48:23.898)
And that happened like overnight, like just one week we were traveling, there was no healthy options and then it just seemed like bam, now you can get a healthy snack at an airport. And that has to be from consumer demand. So I say educate consumers and then they will decide as a general regulations tend to not age well.

Manoj Tandon (48:52.607)
Last question, you’ve been very generous with your time here. Entrepreneurs who are successful and those who are not so much so. You’ve been down this road many a times. Give us characteristics you think that make one successful and maybe not so much on the other side. What’s your experience showing you?

Ben Johnson (49:18.659)
Yeah, I mean, I think you have to be goal driven. From my perspective in what we do, right sizing the solution is a core skill. So we’ve worked with partners that how they think of what they’re going to sequence the sequencing in which what they’re going to release to market. So Forte is a really one of my favorite.

customers. Forte, they just entered the market, they went live a few months back. We helped them build an in-lesson experience for music tutors, music teachers. And so it’s a one-on-one music lesson. So we needed to build a better than Zoom video conferencing for this music lesson to take place.

And so we wanted to amp up all of the sound quality features of an online video conference. And then we wanted to take away, like have the thinnest bezel possible, like take away all the other features. Just have student and teacher working together with a sheet of music. And then we even incorporated the phone so that you could have this other view of the hands. And we really tailored this experience for a music lesson. And…

They could have gotten, you know, when we started this project a few years back, they could have said, and scheduling and billing, and really tried to go live with the full marketplace. But instead, they smartly went live with the in-lesson experience, brought in teachers. Now they have those things. You know, now time has allowed them to do the billing and scheduling and start to go to market as the two-sided marketplace.

But what I really like about those guys is how they sequenced. They were able to get users very quickly. I think within our first 30, 90 days, we were testing with users of being engaged with them because they had such a great idea of, hey, let’s just do this piece first. And they sequenced their build in accordance with user demand. And they just did a really good job. Now, the dichotomy of that or the other side of that would be somebody who’s looking at that next best competitor.

Ben Johnson (51:36.058)
And they’re saying, that’s what we want to be. Let’s build all of those things. And so they’re overloading features. Their appetite for features is way beyond their budget. And if the only way to go to market is to have what’s on the horizon, then they will never go to market, just because the appetite is bigger than the budget. And so to me, as an entrepreneur, especially in the software game,

You need to figure out a small thing, get active with users, get live as quickly as possible, and then listen to each user and essentially let them give you the specification. Let them tell you what is important to them. And so that is, I think that’s make or break from what we’ve seen, is the right appetite, the right amount of features, that understanding of an MVP. Those are key.

Manoj Tandon (52:32.679)
understanding of an MVP, understand your market, understand its need and right size for that. And there you have it. That’s a great formula.

Ben Johnson (52:46.322)
especially now when capital is so expensive. Quite frankly, I’m not sure that we have a choice otherwise. But you can also think, go back to 2000s, early 2000s, where there’s all this bootstrapping content, we need to get back to that with a with the interest rate what it is right now. I think that concept of bootstrapping, you think you have an idea, put an ebook out, you know, do something small.

to test the waters and learn more and start to build an audience. We have social media. We didn’t have that in the early 2000s. Try your ideas out in social media. Also see if you can offer a service and then tech enable that service, rather than thinking about a two-sided marketplace off the jump. So imagine Uber if initially they had gone live

being a dispatcher to coordinate the rides. They could have made revenue from the first day because they were doing a service for their customers. Now, this is a very bad example because of course everyone would view them as wildly successful. But what if success to you is to not have to go raise billions of dollars in capital? It may just be that the two-sided marketplace needs to come later.

Manoj Tandon (53:47.958)
Yeah.

Ben Johnson (54:11.87)
Right now, you need to focus on the service, tech enabling the service, and then evolving to a two-sided marketplace over time. And that may just be the reality that we’re in with such a high cost account.

Manoj Tandon (54:24.643)
That’s very good advice. Very, very good advice. We’re down to the last minute here. We wanna give you the floor to plug whatever you would like. Let our audience know what’s on your mind and where you’ll be appearing or anything. What’s going on, Ben? What would you like them to know?

Ben Johnson (54:42.258)
Oh, sure. So we will be at the JFrog conference in September. So they have a pretty cool concept called Swamp Up. I’m also going to be at the All In podcast that same week, the All In podcast. Some people really will know that one. If you want to reach out, you have, maybe you want to, what we’re doing right now is we’re offering four advisory sessions with me.

For free, complimentary advisory sessions. If you have an initiative, a software project, maybe an app that you’re feeling that maybe you need to modernize, maybe you’re even thinking about an acquisition and there’s some kind of software asset involved. I will run an advisory playbook with you, four sessions, about 45 minutes each, completely complimentary. You can reach me at ben at particle41.com.

or you can find me on LinkedIn. And we’re offering that right now with any CEO or CTO that has an initiative that they want some extra advice on.

Manoj Tandon (55:51.363)
Fantastic. Well, Ben, thank you so much for taking your precious hour with us here today. You’ve given us some sage advice and would, you know, as things change, if you ever want to come back, you’re always welcome.

Ben Johnson (56:07.394)
I appreciate it. Thank you so much. Thanks for the kind words and the questions were great. I really appreciate you, you know, pulling out some really, really cool topics.