Tag: Launchable

  • What Donuts Teach Us About DevOps and Delivery Risk

    What Donuts Teach Us About DevOps and Delivery Risk

    Today, most DevOps teams do not think too much about their approach to risk. Usually, the typical attitude focuses on what to add to reduce risk further. In other words, “Can we add more tests? Can we deploy more carefully?” More tests, more processes and less risk are all obviously good things. Or are they?

    As a programmer, I’ve seen a lot of projects where there are so many tests and so many processes that they actually become counterproductive. Those ‘overheads’ presumably do reduce risk, but nobody knows by how much. I call this attitude ‘blind risk avoidance.’ This line of avoidant thinking usually builds up over time as we react to failures. It’s a very natural reaction.

    But when risk avoidance becomes your standard modus operandi, your delivery cycle gets slower and slower over time. Your team starts to feel they are trapped in molasses but, as time goes on, they not only gradually train themselves to tolerate this but to actively justify that it’s a good thing. In the meantime, nobody pays attention to the fact that your software is losing a competitive edge and that you’re being out-innovated and out-executed by others. Nobody pays enough attention to engineering team attrition; losing people as they drop off, one-by-one to move to more modern software development teams with less baggage. The ultimate conundrum lies here: If you move too fast, you break things. But if you move too slowly, your business and your team are doomed.

    So what is the optimal approach for DevOps teams to take when it comes to risk? The truth is, neither extreme is desirable. Blind risk avoidance leads to a failure of value delivery. On the other hand, blindly ignoring risk means crashing and burning.

    The ideal balance lies in not avoiding risk entirely or ignoring the reality of risk. Instead, a sensible middle ground can be found in taming risk.

    Moving forward, DevOps teams and developers must focus on taming risk to deliver software confidently with data-driven actions, speed and quality. 

    Automation Can Reduce Operational Overhead

    Taming risk should become a larger part of DevOps culture. One of the most famous ways this approach has been adopted is by Google’s site reliability engineering (SRE) team. 

    Google’s SRE team embraces two key principles when it comes to taming risk: Automation for reduced operational overhead and structured and rational decision-making for better, data-driven choices.

    To explore this mindset of risk-taming at Google, let’s dive into how the SREs use automation to slash waste, save time and reduce repetitious, low-value tasks and tests. 

    At Google, SREs are software engineers with an extremely low tolerance for repetitive, reactive work. (Aren’t we all?) But here’s the difference at Google: Thanks to a workplace culture of taming risk, operations that do not add value to a service are avoided or automated away.

    The vast majority of DevOps teams hold the same beliefs as Google: That automation cuts down on waste and saves everyone time.

    We all know automation allows for lower operational overhead, frees up software engineers to proactively assess and improve the services they support and boosts team morale. No one wants to spend their time or energy on repetitive, low-value tasks. Automation frees up DevOps teams to expend their energy on what matters most: Continuous quality.

    Bottom line? Automation is integral to the idea of taming risk. Automation of repetitive, low-value tasks is the perfect way to embrace a mindset of taming, not avoiding or ignoring risk entirely.

    Data-Driven Decisions

    Another way that Google’s SRE team tames risk is through structured and rational decision-making based on data. 

    Data-driven decisions are crucial to the success of any software engineering team, project or mission. Without proper data and feedback, there’s no way for software engineers to make the best, most calculated decisions and mitigate risks. 

    A data-driven decision methodology can—and should—be applied to DevOps testing cycles. 

    Another key aspect of data-driven decisions that speaks directly to the concept of taming risk? Service level objectives (SLOs).

    A service level objective is an element of a service level agreement that measures the performance of the service provider. SLOs are created (and agreed upon) between the service provider and the customer and help to mitigate disputes between providers and customers.

    Now, let’s take the concept of SLOs and apply them to engineering and QA teams.

    In traditional organizations, engineering and QA are forced to interact intentionally with a healthy amount of tension. One team produces software and the other team tears this software down. While this kind of necessary and healthy conflict between teams can lead to better results, the inherent push and pull between engineering and QA can create an excess of interorganizational infighting.

    Engineering teams will always advocate for more velocity or blind ignorance of risk, above all else. On the flip side, QA will always advocate for quality, or blind avoidance of risk, above all else.

    Of course, neither side is entirely correct (nor incorrect).

    Instead, the solution to this tension lies somewhere in the middle: The taming of risk, not ignorance or avoidance of risk. This is where an SLO, or the numeric target that represents ‘somewhere in the middle,’ comes into play. For engineering teams focused on velocity and QA teams focused on quality, creating an SLO—a happy medium to work toward with regard to risk—will create a more balanced workplace culture. In short, this approach can be considered a taming of risk.

    ‘Donut’ Slow Velocity

    Now, we’re finally going to get to the donuts. To demonstrate how embracing a mindset of taming, not avoiding, risk can create better, happier and faster DevOps teams, let’s take a look at Krispy Kreme Donuts.

    Krispy Kreme churns out millions of delicious, hot, glazed donuts every single day. However, during production, it’s inevitable that one or more of those donuts will be flawed. (I know, you’re asking, “Is there really such a thing as a flawed donut?!” For the purposes of this analogy, let’s say yes, there is.)

    One common donut defect occurs when the donuts bunch up on the production line and clog it.  Now, let’s assume this common error is caused by the speed of the line. If the Krispy Kreme team attempts to solve this problem by pushing the line even faster, tolerance gets smaller and the risk of even more smashed, defective donuts only rises. That’s certainly not a solution to this issue.

    On the other hand, if the Krispy Kreme team slows down the donut production line speed, there will be a smoother—albeit slower—operation.

    Is Krispy Kreme better served by slowing down its entire production line and sacrificing its velocity to eliminate the risk of a potential defective donut? Of course not! 

    If that’s not true, then is Krispy Kreme better served by cranking up their production line speed to go as fast as possible, regardless of the risk of defective donuts? Again, of course not!

    For sweet success, Krispy Kreme must embrace a mindset of taming risk. By baking careful measurement and an iterative feedback loop into their donut production process, Krispy Kreme is better able to create delicious, high-quality donuts at an optimal speed, producing some flawed donuts. This balance of speed with quality creates the best economic outcome and the mindset and measurement allow for a constant evolution to risk-taming in the future. As the production line changes, the optimal speed also needs to evolve.

    DevOps teams should take this same approach. Tame the risk without sacrificing speed and quality. ‘Donut’ slow velocity to fix a few minor issues!

    If you’re still not convinced, here’s another way to think about taming risk that is decidedly less delicious than warm, glazed donuts: Taxes. 

    The IRS balances velocity and accuracy during tax season as they process millions of tax reviews. While suspect returns are flagged for audits, the IRS simply cannot catch every single flawed tax return. It’s not economical or even possible to run detailed audits on every single problematic tax return, every single year.

    So, instead, the IRS tames its risk with automation and data-driven decisions. The IRS focuses on creating and using methods to detect patterns that correlate with flawed tax returns. Then, once these data-driven problem returns are detected by automation, experts can devote their precious time and mental energy to tackle the biggest of the problematic returns. 

    Again, this approach to taming risk creates an inherent balance between quality and speed and allows for an evolution of the process as economic activities and laws evolve.

    Whether you love eating donuts or doing your taxes, the bottom line is clear. Most organizations need to balance potential risks with maintaining speed, quality and team morale. DevOps teams are no different. 

    How to Tame Risk in DevOps Teams

    So how can we, as DevOps teams, tame the risk?

    The basic idea here is to do smarter testing, not just more testing. The good news is that if you have a reasonable level of automation, the data coming out of your existing automation can make your testing smarter. Approaches like predictive test selection can let you spend your computer hours more meaningfully, allowing you to improve speed and quality at the same time. Approaches like flaky test insights can let your precious engineering resources focus on the most impactful effort to improve the quality of tests.

    The Power of Taming Risk

    What is the right balance between speed and quality? This is the constant question DevOps teams face. But, here’s how I answer this riddle: Taking calculated risk is the most logical and rational approach in the workplace.

    It’s easy to avoid risk. Anyone can skirt around potential pitfalls by avoiding new solutions and sticking to the same old methodologies. But it’s so much more satisfying to take a calculated risk rather than ignore or avoid the risk outright. 

    If you want to improve the velocity and the happiness of your DevOps team, it’s time to embrace a new mindset: Tame the risk, gain control.

  • A Data-Driven Approach to DevOps: Tips for Improving Speed and Scale

    A Data-Driven Approach to DevOps: Tips for Improving Speed and Scale

    Data has an undeniable power in a business context — it can sway stakeholders, help identify pain points, and demonstrate how changes are making an impact on the company. As the creator of Jenkins, Kohsuke Kawaguchi has noticed from his conversations with business leaders in the industry that implementing a data-driven mindset can be a game changer in the DevOps journey. 

    While data may not initially seem like it provides a full enough picture for businesses to work with, it carries invaluable insights and a certain level of objectivity that allows for a smoother transition in the DevOps process. Additionally, adopting a data-driven approach helps to showcase the small wins in your DevOps journey that can help build more confidence and trust in the process. 

    In the interview below, Kohsuke teases his session, “Go Data Driven With Your DevOps: 5 Tips for Improving Speed and Scale,” at TechStrong Con.  On July 15, Kohsuke, along with fellow Launchable Co-Founder Harpreet Singh, will provide tips on how a data-driven approach to DevOps can help improve speed and scale. 

    To see the full agenda and secure your free spot at the virtual event, visit the TechStrong Con website.

  • DevOps Chat: Increasing Delivery Velocity, with Launchable

    DevOps Chat: Increasing Delivery Velocity, with Launchable

    Jenkins founder Kohsuke Kawaguchi (KK) and respected DevOps veteran Harpreet Singh have launched a new company called Launchable.

    Launchable aims to help you improve your delivery velocity by prioritizing and applying some ML and intelligence to testing. There is still much work to be done but with these two industry luminaries behind it, the expectations are high for something impactful.

    The VC community and a blue chip list of investors are already on board.

    Yes, this means KK is no longer at CloudBees (several CloudBees execs are investors in Launchable) and Jenkins, while he is still an advisory. But, with Jenkins now in the capable hands of the CDF and Linux Foundation, and CloudBees well established, he felt this was a good time to pursue an issue he thinks needs to be solved.

    Hear from KK and Harpreet themselves in this great podcast.

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel for devopsy.kinsta.cloud, and I am here, you’re listening to another DevOps Chat. We have some really great breaking news on this DevOps Chat. I’m really happy to have, snagged a dynamic duo of industry veterans in the DevOps space who have just started what promises to be perhaps a game changer in the DevOps industry. But they’re gonna tell us more about that, I don’t know.

    Let me introduce you to Harpreet Singh.

    Harpreet Singh: Hello.

    Shimel: Hi, Harpreet, how are you?

    Singh: Very well, thank you.

    Shimel: Thank you. And Harpreet is co-CEO of the new company, and his co-CEO is none other than my friend, Kohsuke, K.K., founder of Jenkins, CloudBees and all of that good stuff. K.K., welcome.

    Kohsuke Kawaguchi: Hello. Thanks.

    Shimel: Okay, so, let’s talk about the big news. We have a new company in the DevOps space called Launchable.

    Kawaguchi: Yeah.

    Shimel: Is that—and the both of you are co-CEOs?

    Singh: That’s right.

    Shimel: And, of course, with your track record, I’m sure, you know, it wasn’t as hard as it is for a first time entrepreneur, but Launchable’s already raised some venture capital to help it get off the ground, including some high profile angels.

    Kawaguchi: Yeah. We’ve been very lucky.

    Shimel: Talk a little bit about it—who’s involved, who’s put some money in?

    Kawaguchi: So, there are two big institutional investors. One is Barclays Ventures, and that comes from Harpreet’s long relationship with their partner, Gomesh. I think, in fact, your wives know each other. Like, it almost feels like an insider. [Laughter]

    And then another VC is the unusual ventures, and that’s started by Unusual Ventures, and that’s started by John Vrionis. And John actually has been also an investor at CloudBees, so his people have seen us in action and know us well enough so, you know, you get their validation and then you endeavor it. It’s been—I’ve been truly grateful.

    Shimel: Sure. Well, I’m familiar with Battery back in my day, it was a guy named Gerry Conlon out of Battery Ventures. I don’t know if either of you know Gerry, but he was instrumental early on in Battery. But yeah, they’re a great company. It sounds like two, you know, kind of blue blood venture capital firms in there.

    There’s also some high profile angels including Sacha—Sacha Labourey, CEO of CloudBees, right?

    Singh: Yeah, yeah. So, I think what was exciting for us as we were talking with people was just, you know, the phenomenal backing that we got from investors as well as—you know, these marquee investors as well as individual angels, right? So, we both have been at CloudBees.

    So, I don’t like to think of ourselves as first time entrepreneurs, because we built CloudBees from less than 10 people to whatever it is today.

    Shimel: Yep.

    Singh: I had a sojourn to Atlassian, where I spent about a year and a half really learning from that phenomenal company. So, we were very lucky when people from CloudBees like Sacha, Michel—Michel Goossens, who was the VP of sales there at some point came in and invested. Bob Bickel, who’s been an industry veteran invested in us. And on the Atlassian side where the CTO is Sri Viswanath and Noah, who’s the head of tech teams, which is Jira, Bitbucket, Opshimi and all these comfortable investing in our capabilities and our mission.

    Shimel: Absolutely. And make no mistake, you’re not first time entrepreneurs, because first time entrepreneurs don’t raise money that easily, guys.

    Singh: [Laughter]

    Kawaguchi: [Laughter]

    Shimel: I mean, I think there’ll be a lot of people who listen to this podcast who are first time entrepreneurs and say, “Man, if we only had their background and their resume and their experience, it wouldn’t be as hard as it is.” I think a lot of first time entrepreneurs struggle—struggle with doing that.

    But that’s great. It’s always good to have money in the bank when you start a venture, because it’s needed, but as we were talking about off camera a little bit, I’ve never met a successful startup entrepreneur who did not think what they were doing was in some way changing the world, making it better.

    And so, I wanted to ask each of you individually—what really got your juices flowing? What really got you excited about what you guys are doing at Launchable?

    Kawaguchi: Sure. Alright, so I’ll start. So, you know, one of the things I started—I created this sort of thinking and I felt like I put the state of the automation and the software development power to the next level in the world. And this automation, they produce a lot of data. And what I realized after a while was that, you know, in the rest of the world, in the rest of the business world, data is increasingly being used effectively to drive decisions and make people more efficient and so on.

    But whereas in the software development, I feel like that actually hasn’t really happened. And I felt like this was a great shame, one as somebody who, you know, helps people produce a lot of data with these automation systems, but also, you know, we are the number people, we are the data people, right? We are the pride of ____, at least I think of it that way.

    Shimel: Mm-hmm.

    Kawaguchi: Yet, everywhere I look, I feel like we are making decisions, engineering decisions based on gut and instincts, and this can’t continue. And so, that’s what I kind of started thinking about after a while, and then this idea kind of grew and grew on me. So, yeah—so, that’s probably where my, how my juices got flowing.

    Shimel: Excellent.

    Singh: Yeah, very similar. I think Kohsuke and me used to sit next to each other in the same office room at CloudBees and we used to talk about this all the time. We got the opportunity to see sales and marketing really be completely numbers driven, and we would come back and say, “Oh, if we could only do this on our engineering product side of the house, it would be so much better.” And the answer always was, “Well, it’s a craft.” And we think bringing data in there is important.

    Shimel: Right.

    Singh: And so, that’s sort of what got us both going. My personal anecdote was, after I left and moved to Atlassian, I was talking to somebody out in my customer base there who had this challenge where their delivery velocity was slow and, you know, their aim was to put a few engineers to go in and look at it and how to improve it. And having the DevOps background and you understand CI/CD, I felt like—there has to be a better way to do this than just, “let’s allocate a few engineers and see what comes out of it.”

    Shimel: Right.

    Singh: So, that’s sort of the problem space, and that’s what excited us.

    Shimel: Excellent. And it is, it’s almost ironic or oxymoronic, even, when  you think about it, right?

    Singh: Right.

    Shimel: Because—so, my background’s in information security, right? And one of the things we have seen in security is information overload, like data overload.

    Singh: Right.

    Shimel: The noise to signal ratio. But there have been—there have been a lot of security startups over the last, let’s say five years, seven years, who have really tried to fine tune that dial to get more signal to noise, to be able to automate going through the mounds and mounds of log data, for instance, right?

    Singh: Mm-hmm.

    Shimel: So, you get a company like a Splunk that can just suck a lot of data in from everywhere. And then try to figure out, in an automated way—because there’s just too much to go through by hand—

    Kawaguchi: Exactly.

    Shimel: What’s important from a security point of view or maybe even from a network operations point of view. But as you guys said it, I’m thinking—we don’t really do that with our software development, do we?

    Kawaguchi: Yeah. And I mean, when you describe it like, it might sound a little abstract program, but idealized, it’s actually connected in so many ways to frustrations that I have every day as a developer, right?

    Let me give you an example. You know, I was working on this Jenkins project, and it’s a sizable project with lots of test cases, which is great, but what that means is that every time when anybody wants to make, like, a ____ change, the first thing that happens is, the CI system comes in and they run the whole one hour test cycle before the code review happens, and then somebody makes some observations or a suggestion that, “Oh, you should change this part to something else.” And then you follow that and then another whole hour of testing. And then that’s basically, like—two hours is a long time to wait if you get some change in, actually. And that happens all day in that area.

    Shimel: No, no—I mean, so, let me be a half glass full kind of guy. It’s better than—the one hour is better than the one day it used to be before we automated some of this stuff, right?

    Kawaguchi: That’s true.

    Shimel: I remember back in my StillSecure days and we would—we didn’t even have a big enough infrastructure to do the testing, we would have to outsource, like, unit testing and all this stuff.

    Kawaguchi: Yeah, so, let’s talk about that one big thing, right? Because that’s actually probably an even bigger program. And you said that that’s before automation, but I’ve seen teams every single day that actually have tests that run for more than a day, you know, [Cross talk].

    Shimel: With automation?

    Kawaguchi: Yeah, like an auto maker company putting a car together, a lot of big software. If you test them all, it’s in that cycle for weeks. So, there are a lot of pieces of software getting assembled together into something big, and that test gets even bigger.

    So, what I started doing is, like—okay, so, every time you do this, it’s not like everything is changing all at the same time, right? There’s only small parts of the system it’s changing, and then when we re-run the whole test cycle. So, what if we could ____ the right subset for that test to run? They’re most likely detached programs, so they’ll not only finish quickly, but they also run cheap, and then you still get, like, a pretty sizable, meaningful feedback. You know, you’re not gonna get 100% coverage, but you might get 95%, and that’s plenty good, and that cuts the execution down in, let’s say, half.

    And so, these are the kind of things I thought the data would actually enable, and I’ve seen some prior work, I’ve talked with teams who seem to be on the cusp of doing these things, and I felt like—yeah, this clearly makes sense. More and more people need it, and I need it. And so, that sort of became the founding idea behind Launchable.

    Shimel: So, that was the itch you were looking to scratch here, as I say, right?

    Kawaguchi: Yeah, right.

    Singh: And you asked, like [Cross talk]—

    Shimel: I’m sorry, go ahead.

    Singh: Yeah, and as we were sort of thinking about this, right, we identified this problem and we’re thinking about, like—so, what’s the company’s mission, right? And we realized that every sort of software teams in the future or even today will drive every significant human achievement there. It’s really hard to think about anything that’s not being software delivered.

    And our mission now is to take this artisan teams and actually make them data driven scientists to drive their velocity, you know, and deliver software confidently. So, that’s sort of our big itch and our big mission.

    Shimel: Absolutely, got it. So, let me play devil’s advocate a little bit. You know, one of the things we always used to hear—I heard it in security, I heard it in QA—was, “Look, we don’t have enough time to do a full test, full testing. Let’s just test 80%, 70%, 90%”—take your pick, I don’t care what number you pick.

    You know, Murphy’s Law says whatever you don’t test, that’ll be the thing, somehow, that breaks, right, or that causes a problem. And when we say, “Oh, my God, because we didn’t test that”—why didn’t we test that?

    Kawaguchi: Right. So—

    Shimel: “Why shouldn’t it get done?” Right.

    Kawaguchi: Yeah. So, if you think of testing in isolation, then yes, that’s naturally a concern, because, you know, we need every help and every confidence we can get out of the test. So, like, why would you skip that? That doesn’t make sense.

    But I think where it does make sense is actually, if you think about it, the software development life cycle is composed of a lot of different tests at a lot of different points. So, collectively, they should be seen as a whole system, right? I mean, this is things like—so, the code review, right? If that’s the only point in which you are getting tests run, then you want to run them all. But what happened is, after the cold gets reviewed and merged, then another set of the same tests will come in. So, it is really important that you run all the tests before the code review and spend one hour, or are you okay with 80% of the confidence that happens in, like, five minutes, right? Then knowing that the rest of the 20% get code immediately after.

    I think there is an argument to be made that, overall, you’d be better off, even if some program slips down into the ____, so long as it gets eventually caught before the customer sees everything, so.

    Shimel: So, I guess then that that begs the question is—can that be accomplished? And, to accomplish that, what’s it going to take?

    Kawaguchi: Mm-hmm, yeah, and that’s what we are working on. I think, you know, the—so, I have some preliminary numbers, and they look good. Because if you think about it, the baseline that we are competing against is basically people running all the tests in a random order, and so, literally, you cannot do any worse than that. So, and instinctively as a developer, I know that certain tests are designed to catch certain programs in some specific things.

    So, really, the only question is how well a machine learning model can learn these things over what amount of data. And that, over time, I think I’m sure is gonna get better and whatnot. And I don’t know exactly what kind of impact we can create or what product, but overall, I’m feeling pretty confident. You know, it just needs to be good enough to start making an impact, and it’s only gonna go up from there.

    Shimel: Harpreet, what does success look like for you?

    Singh: Well, this has been a question that’s been asked to us while we were raising funds. I like to think in terms of—so, we’ve done this before. We’ve helped companies get successful. What’s in it for me is actually solving a problem for customers.

    So, if you are able to get and solve a software team’s problems everywhere, to get their products in the hands of customers first—that’s success for me. I know it’s not sort of putting the typical Silicon Valley 100 million to 200 million ARRs. That’s not where we are. That’s not where my head is at. It’s really helping people who are struggling with delivering software.

    Shimel: Got it. K.K.?

    Kawaguchi: So, you know—

    Shimel: What about you?

    Kawaguchi: One time I was working in San Francisco Airport, and then somebody was, you know, working behind me and she said, “Oh, you got a Jenkins thing. That’s nice. Where can I get it?” Right? And that, to me, is like a success. So, it’s gonna be a difficult one to beat once more, but you know, I feel like it’s worth giving it a shot.

    I mean, that’s the kind of—I guess I sort of think that the sign that you made a big enough impact in the world, and some people, and touched some people in pretty deep ways. And that, to me, is success. That’s what I’m itching for, yeah.

    Shimel: Okay. Let’s—let me hold both of your feet to the fire a little bit. So, you’re now launched, this is—you know, it’s out there, the website’s out at Launchable Inc, that’s L-A-U-N-C-H-A-B-L-E-I-N-C dot com, right? When can people hope, maybe, to see a beta? When do you think you’ll be out with something people can actually start using?

    Singh: You’re really holding our feet to the fire, right?

    Kawaguchi: [Laughter]

    Singh: You have a product manager and an engineer, here. I would like my engineering head to give me the dates on deliverables. [Laughter]

    Shimel: You know what? Classic. You’ll make a [Cross talk].

    Singh: Boy, you and me on the same side, here.

    Shimel: That was a great CEO move right there.

    Singh: [Laughter]

    Shimel: Alright, Mr. co-CEO, he threw you under the bus. What do you think?

    Singh: Jokes apart, I think one of the things that we are actually doing at the moment are, we are actively talking to prospects and customers. A lesson that we’ve learned over the years is not build a product in a vacuum and then hope that we’ve solved the problem.

    So, we are actually—there is actually a beta invite list button on our website. What we are looking for is actually partners who can come with us and tell us if we are solving the right problem and work with us to solve the right problem, right? So, that’s sort of where we are today. I’ll leave it at that and I’ll put the dates to you.

    Kawaguchi: Yeah, so, you know, we have preliminary numbers, like I mentioned. We made some models that made some impact, and now what I’m really hoping to find is event partners where we can apply the same technique on their system, their projects, and their source code to see what kind of impact does it produce. And then, so that’s—you know, that may be fundamental in these teams who are willing to work closely with us, and—

    Singh: Is that some number that you can share on preliminary numbers?

    Kawaguchi: Yeah. So, I mean, there is no guarantee that it’s gonna apply to your system. But, for example, while I was able to do this, select 10% of the subset for the best case use and it’s gonna catch like 40% of ____ right off the bat. So, I guess, you know, that’s—yeah, that, to me, is a pretty promising number, and you can only go up from here, so.

    Shimel: Excellent. So, look, both of you have garnered a ton of good will, not only among your peers as evidenced by the angel, you know, the investors’ list here, but also in the community at large, and K.K.—I mean, it goes without saying within the Jenkins community how well respected and, I don’t wanna use the term worshiped, that’ll go to your head, [Laughter] but you know, how honored you are in the community.

    What, people maybe from the community listening, what can they do to help, here?

    Kawaguchi: Yeah, I think giving us their feedback probably is the most. You know, we are working on something that we think is pretty exciting, and then we wanna hear that, or if that’s not the case, then that’s also great to hear. So, so far, the conversations we’ve had with people who are interested in this space who are thinking about this space have been incredibly valuable.

    So, if—you know, if you feel like some of what we discussed here is you and your challenges, we’d love to hear from you. And also, we are hiring—wink, wink. So, you know. [Laughter]

    Shimel: Everyone’s hiring.

    Kawaguchi: Yeah, so if you—

    Shimel: Alright. Is it on the website?

    Kawaguchi: It is. You know, one thing I got a lot more passionate at, you know, CloudBees and Jenkins is sort of passing back onto the next people, right? I felt like I got a lot more joy out of talking to the junior engineers and folks, we steer and mentor them. So, I feel like what we can offer—and I know it’s true with Harpreet, too, so I feel like what we have right here is an incredible opportunity to work, you know, sit side by side with these people, you know, people like us who, I think ____ creativity. We’re also passionate about mentoring other people. So, you know, I think if it sounds like your cup of tea, then…

    Singh: I’ll jump on that. So, I think, CloudBees was a fantastic company. You know Sacha, Alan—he’s just a great leader. He built a fantastic company. So, we learned a lot of good lessons on what it means to be a good company.

    Then I ended up at Atlassian where, you know, I learned the same things from Scott Farquhar and the other folks, and we’ve tried to bring in all the great points from these two companies into this company, right? We are sort of values driven. We’ve really thought hard about the kind of company we want to build, the kind of impact we want to have in the world, and we are looking for people who share that sense of mission, right, to come on our team, right? And if you find some of those guys on our team, that’s fantastic.

    On the former side of the house, again, we are looking to solve problems for customers. We are not looking to do this in a vacuum. So, there’s a general profile of people who are like, “Yeah, I hear this. I wish I could partner with someone and help you define what—go solve this problem for me.” If you’re that person, we would love to talk to you and we’d love to partner with you through those things.

    Shimel: Fantastic. Guys, we’re way over time. I promised you 15 minutes. We might be coming up on a half hour; I apologize.

    But let me close off by saying—you know what? Congratulations. Someone once told me new companies are like boats—the best days are the first day you get ‘em and the day you sell ‘em. [Laughter] But that being said, it’s also a lot of fun sailing ‘em. So, enjoy the sail, guys—change the world. If there’s anything, of course, we can do here at MediaOps, you know you can count on it. I couldn’t think of two nicer people for this new adventure and to take on this challenge.

    Harpreet Singh, K.K.—co-founders, co-CEO of Launchable, you can find out more at Launchable Inc. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat.

    — Alan Shimel