Guests: John Amaral, Kit Merker
Companies: Slim.AI, Nobl9
Show: Let’s Talk

The creation of a high-impact advisory board has become a hot topic over the past few years and companies like Slim.AI and Nobl9 have both jumped on the bandwagon to accelerate their business agility. Swapnil Bhartiya hosts John Amaral, Co-Founder, and CEO of Slim.AI, and Kit Merker, Chief Operating Officer at Nobl9, to discuss the practicality of advisory boards and get a few tips from these leaders to maximize organizational effectiveness.

Slim.AI is a company focused on helping developers create, build, deploy, and run cloud-native applications more efficiently while Nobl9 is about taking reliability data connected to business KPIs and helping companies run automation to make their services more reliable.

Merker recently joined the Slim.AI advisory board. The primary focus of this board is split into three main categories: The product (which is developer-facing), the culture (bringing people in to help the company build and work better), and the ability to relate to and create content and product focus that brings value to developers.

According to Amaral, advisory boards make it possible to “bridge conversations to a broader audience within the company where the advisor lives, to learn more.” He adds, “And it’s really all about learning quickly. And folks have been super generous with their time, but also making introductions for us and giving us some insight from inside there.” Also, such boards make it possible for those in charge to hear about the problems developers face. So from a practical standpoint, these boards can open up new avenues of networking and communication for companies.

From Merker’s perspective, the software supply chain is pretty broken across the industry as a whole, and it has been for some time. Merker mentions his time with Google and Kubernetes and how it was “very clear across every ecosystem that there are vulnerabilities in the supply chain of software. And we don’t know what’s running anywhere.” He then focuses on Slim.AI, saying , “I see Slim.AI and the popularity of both the DockerSlim project and then now with the team and the product they’ve built. I see it really addressing a very core problem, a very focused problem in developer productivity, leading to production stability, that whole concept of knowing what’s in your containers, what’s in the artifacts.” From an advisory perspective with Slim.AI, Merker makes it clear, “With my interactions with John and the rest of the team, they always come to me with an agenda and things they want to talk about and very specific questions where I can weigh in on, give my thoughts, make an introduction, help them hone their priorities.”

Talking about  the role of an advisor, Merker says, “You have this arm’s-length relationship with the company and you’re really building the relationship with the executive team and the key people. But you don’t really get to do any work.” He adds, “You get to spend a little bit more time really doing the thinking, the strategizing, but it doesn’t become this thing where you’re grinding away every day, which is what I do in my day job.”

For those who are planning to create an advisory board, Merker and Amaral offered up a few tips. First, according to Amaral, it’s important to understand why you want an advisory board. For that, you’ll want board members who have the background and knowledge and can fit into (and help improve) your culture.

Advisory boards, according to Merker, must always come to meetings with an agenda. To that, he says, “It’s easy to get overwhelmed and it’s fun in the first couple of weeks, but then as the months drag on and you keep having these new conversations and everything, it can become something where there is a time pressure. And so I’ve had to be very particular about it.”

Amaral mentions that it’s very important to set expectations internally that everything learned will be put to work right away. He also adds that an advisor must see they’re being heard.

Finally, Merker closes by reminding us that it’s okay to discard bad ideas.

Summary for this interview/discussion was written by Jack Wallen

Here is the rough, full transcript of of the interview:

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya, and welcome to TFiR Let’s Talk. Creation of advisory boards is a relatively common practice among startups, but what purpose do these boards serve, and how can startups get most out of it? Today we have two guests with us to discuss this topic. John Amaral, co-founder, and CEO of Slim.AI, and Kit Merker, chief operating officer at Nobl9. Kit, John, it’s great to have you both on the show.

John Amaral: Thanks, Swap.

Kit Merker: Nice to be here.

Swapnil Bhartiya: So I’ll start with you, John, I would love to remind our viewers, what is Slim.AI all about?

John Amaral: Slim.AI is a company that’s focused on helping developers create, build, deploy, and run cloud-native applications more efficiently. Today, we’ve built a combination of open source and SAS products. Our SAS is in early access, our open source has been out for a while and it really helps developers, and DevOps to some extent. Folks optimize containers as part of the application build life cycle. We see a lot of manual effort, and a lot of rework and inefficiency in that life cycle of creating cloud-native apps from containers to running apps and infra. And we want to bring a better mouse trap to that for helping them build prod-ready containers and services.

Swapnil Bhartiya: Right. And today’s spotlight is more on Slim.AI, but since Kit, you have joined their advisory board, and we have hosted Nobl9 so many times, but just a quick reminder to our viewers, tell me quickly about Nobl9 also.

Kit Merker: Well, Nobl9 is about making service-level objectives and error budgets. This is all the rage right now with site reliability engineering. Basically, we take your reliability data connected to business KPIs, and we do it using the principles of getopts so that you can run automation to make your services more reliable, and also keep people sleeping at night instead of chasing the pager.

Swapnil Bhartiya: Now, let’s deal with the elephant in the room, which is advisory boards at startups. John, you folks created this advisory board, talk a bit about what role do these advisory boards play at startups? Are they more or less, just for the sake of creating a board, or you actually get real insights and wise advice from seasoned folks who join and at Slim’s board, there are some really impressive names there. And of course, Kit is there too. So let’s start with the role of advisory boards.

John Amaral: Kit is pretty impressive, right? So advisory board, three main focus for us. One is product, and it’s all about developer-facing products for us. We’re thinking about the developer and we have a lot of folks on the board that really have a lot of experience there, Kelsey, Kit, and others have really got the chops in understanding both how to build products for developers, but also how to think about these products being used as developers. The second is culture. We want to bring folks in that help us build our company better, build how we work together better, and have done that at companies that focus on building for developers and open source, and also in building commercial products and with the way folks work today, we’re a remote-only company, understanding how to build an organization well, that way is another important part.

And the third is just being able to relate to and create content and product focus that brings developers value. And those folks do that. We’ve been pretty intent on engaging with these developers, knowing them personally, these advisors, and knowing them personally. Being able to relate to them. They come on our team calls, they work with our engineers directly, they do product interactions, we work with them to really hone our messages. They’re working with us every day, but you got to put in effort from the company side to make that happen. So we have regular calls set up, we talked to them weekly. It’s been a really fun ride. And these folks have given us a lot of benefit

Swapnil Bhartiya: Is this relationship between the individual who has joined the board, or does it also open doors and bridges for any collaboration between the companies as well?

John Amaral: In many cases, we’ve been able to bridge conversations to a broader audience within the company where the advisor lives, to learn more. And it’s really all about learning quickly. And folks have been super generous with their time, but also making introductions for us and giving us some insight from inside there. And that takes the shape, sometimes, of us working with some of their development teams to hear the problems they face or it’s introductions. Kit’s made several for us, to other folks in the space around marketing and getting our name out there, which we’ve learned a ton from. And it’s been super exciting.

Swapnil Bhartiya: What did you see in Slim, that you agreed to join the board, and support the company? And if I look at, from your perspective, how do you help companies like Slim?

Kit Merker: When you look at the software supply chain, you want to call it a software supply and delivery. It’s really pretty broken across the whole industry and it has been for a long time. I mean, I’ve been doing this for longer than I’d like to say, but then I think back to my time at Microsoft and my time at Google, working on Kubernetes and the things that happened when Docker first emerged, one of the things that became very clear across every ecosystem is that there’s vulnerability in the supply chain of software. And we don’t know what’s running anywhere. There’s also an important trade-off every developer has to make between what do they put on their box for debugging and for being able to actually be productive versus what they put in production. Where they need to maintain a smaller attack surface and when they use more resource efficient versions of those software artifacts, and that whole process creates… there’s a lack of transparency, a lack of productivity in that whole process of going from what I need in my box versus what I need in production.

And so I see Slim and the popularity of both the Docker-Slim project, and then now with the team and the product they’ve built. I see it really addressing a very core problem, a very focused problem in this developer productivity, leading to production stability, that whole concept of knowing what’s in your containers, what’s in the artifacts. And I’ve been working in these areas for quite a while, but the team has really impressed me with their focus. I would say from an advisory perspective, they make it actually pretty easy. I think a lot of companies probably fail to organize their advisory board and it’s more, trying to get names on the board. I see with my interactions with John and the rest of the team. They always come to me with an agenda and things they want to talk about and very specific questions where I can weigh in, give my thoughts, make an introduction, help them hone their priorities.

And that is, really, a great feeling because as an advisor, you have this arms length relationship to the company and you’re really building the relationship with the executive team and the key people. But you don’t really get to do any work, I guess, is the way to look at it. That you ended up doing a little bit here and there where you can help. So I really enjoy the process because you get to spend a little bit more time really doing the thinking, the strategizing, but it doesn’t become this thing where you’re grinding away every day, which is what I do in my day job. I got my own startup to look after, but it’s been just a really fun experience advising and working with the rest of the team. And I think it’s, hopefully, going to be rewarding. We’ll see what happens with the company and hopefully everything will be super successful. Well, I find a personal reward too. It’s just the act of helping other people along the way has been a rewarding experience.

Swapnil Bhartiya: Yeah. And one of the interesting thing is that you also get to work with one of the best folks in the industry in that space. And it’s learning for both parties, a lot of cross-pollination happens and you also learn from each other as well. So now let’s talk about, you mentioned a couple of points, you pointed at some pain points, also. If you just focus on containers or cloud native, automation, I think, is the key moving forward. Without automation, a lot of things, you cannot do that. So if we just look at these problem areas and ask you both, how do you folks look at it? Of course, Kit, you alluded to that a bit, but if I asked you though, how companies should look at automation, we talk about a lot of practices, a lot of paradigms, DevSecOps and everything else. Talk about automation, not only from technology perspective, but also processes or culture perspective and how companies should embrace it so it becomes part of their culture as well.

John Amaral: I think a critical thing we talk about internally is just the ability to create automations and workflows that remove friction from these development workflows. So developers, for instance, and especially around containers, one area we’ve excelled at is doing automated optimizations of the container footprint. Being able to know exactly what software is in there to be able to pull out software, you don’t need, that’s what Docker-Slim’s been all about. And then let developers understand easily what changes have been made to containerize softwares or a set of containers so that the downstream work of accepting that, understanding it, putting that to work into production is certainly less subject to manual error, less subject to supply chain error, meaning that the software in there is the software I want.

A lot of that work today, is done by hand. We talked to developer after developer that if they want to remove software that has vulnerabilities or has a risk surface potential, this is really some smart developer who goes in there and uses their own knowledge to pull that apart. And we think that anytime you can reduce these manual efforts, the better outcome you’ll get. And downstream for teams like the work that Kit does to help teams better make this stuff work in production and understand it in production, I think that’ll lower some of that burden. So it’s really about taking friction out of the whole workflow,

Kit Merker: I think, just building on that, the friction and the automation is such an important part of what people do, but there’s this paradox, I don’t know if everyone’s familiar, but the paradox of automation which basically says that as you increase automation, human involvement is reduced obviously, but the criticality of human involvement goes up. And you can see this when you ride in an automated car, right? It’s great until that moment when you need to grab the steering wheel. And the same is true in our DevOps automation. And so what we see organizations doing, I talk to customers all the time that are just trying to automate everything, not realizing that they’re going to run straight into that paradox.

And what you actually need is the automation to be in a position to help you take those well-known rote tasks off your plate. Some people call it toil. And that use of automation is very powerful. However, if you remove the judgment and you remove the human from the monitoring, what we really need is a set of abstractions. Or we can look at the system from a higher vantage point. And the automation is doing the tasks we need, but not removing our power or our judgment over those systems. And maybe an abstract way of looking at this, but in a practical level, what this really looks like is having great telemetry monitoring, service level objectives are a key part of this, having goals for your system, and then having the automation supporting that, to drive the business outcomes, right? It’s not about trying to get a perfect system. It’s trying to find those major issues. And this is exactly what John’s talking about with the tasks that today, we actually aren’t very good at automating software tasks, right?

We’ve automated so many other industries, but software tasks remain manual. And this is a surprising fact because wouldn’t you think that the people who are building the software would be in the best to automate? But, I mean, maybe it’s a cliche, but the cobbler’s children have no shoes kind of a thing, right? So we’re seeing this now happening more and more, where the automation is coming up. But let’s also not forget the pressure that are on these teams, especially having gone through this pandemic, their brute forcing their way to reliabilities. Every business has gone digital. Consumer expectations have gone through the roof in terms of the quality they’re expecting. And they’re also building a system that’s constantly changing. Keeping up with all the open source, all the latest frameworks, there’s react review, all these things that are happening in developer’s minds. And then on top of that, to automate these tasks that keep changing underneath them. So I think it’s a really complicated area and definitely deserves the kind of investment we’re seeing from developers in the automation space.

John Amaral: Following on Kit’s point, the developers who use our automation to optimize containers have asked us, well, you’re doing a lot of the heavy lifting for us to make containers more efficient, more secure, smaller. Now we need tools to understand what’s changing to the automation process, but also as they adapt their software. So to his point, they need more tools and more telemetry and more understanding of change, so they can understand when things go wrong or how to know that the outcomes that they want are actually taking shape. And so we’ve been doing a lot in our SAS to give developers more of this visibility and tooling.

Swapnil Bhartiya: Right. And talking to your paradox, it’s more or less like, with great powers comes great responsibility or whatever you want to call it. Yeah. You mentioned supply chain and I want to understand because supply chain become a very interesting topic, especially after the Biden’s executive order where bill of software, bill of material is becoming important. So from your perspective, how much awareness, especially when you look at containers, right, people will pull containers they don’t even know what is in there. There may be hard links. For a lot of companies, it may be okay, but if you are looking for acquisition, you may be in violation of some code and you don’t know about security. So can you talk about how much awareness is there about supply chain and how do you folks help organization or what should be the best practices so they should have very good visibility of what code is flowing through their services and products?

John Amaral: If you look at container best practices, and we’re really trying to build tools to help people do this easier, right, here are container best practices. In the top two or three things they say you should do, the first one is if you’re using public images or containers that come composed from public software, understand it, know what it is. And the second one is only put the software that you need in the container that you shipped to production, right? So these two things are difficult to do, especially when you have a complex build for a container. So I’m pulling some base image. I use some parts of it. I construct it into my own new set of containers and go on from there, making it easy for a developer or a DevOps engineer to really just see quickly what’s inside there, understand the composition.

How it’s built is something we focused a lot on with our SAS platform. And we know that, by talking to lots of folks and interviews and actually having developed big SAS platforms ourselves in the past, most engineers, most teams, don’t understand that full scope. So making that easy is super important. And especially in today’s security landscape, knowing the software you’re shipping is super important, not just for downstream later or when, maybe, you’re acquired, but it’s really for operational assurety, today. But it’s not that easy to do generally. So, yeah, I think folks are aware of the need, but less capable of doing it. And we’re trying to help bridge that gap, especially for those first two points.

Kit Merker: Yeah. My biggest fear with the software supply chain security is that people think they can solve it using spreadsheets and traditional methods and without retooling their delivery pipeline. This is my fear because I think people are clearly aware of the problem. They’re clearly aware that there’s Bitcoin mining code making an inset, the top Android apps, right? These are things that are in the headline news and we’re seeing it. The SolarWinds hack, et cetera, this stuff is everywhere. But when you look at the organizations, if their solution to the problem is to do what looks like security theater, or inventory, et cetera, it’s not going to be tractable.

And what people really need to do, I think, is they need to take a first principles approach and ask themselves these questions, like how are things even getting in there in the first place? And what level of tolerance and risk are we willing to take, given the different pieces of our systems? And I don’t think that there’s any one solution in the market that’s going to solve all the problems, to be honest, right? It’s going to be a combination of tools, a combination of technologies, the great stuff happening in the open source space, lots of companies addressing different parts of this problem, but it really is something that needs to be thought about end to end, right.

And also, going back to this point about, you can never make anything a hundred percent anything, right? It can never be a hundred percent secure or a hundred percent reliable. And so having a strategy for fast response and eradication, having audits, having ways of questioning our own biases about what’s in our systems, this to me is really the critical piece that will lead to that higher-level security. And by the way, this is a universal gut. This is something that vendors should be working together on. We should be thinking about collaboration because it doesn’t help anybody other than the attackers, frankly, for us to fight over the best solution, right? We should be collaborating and finding ways to coordinate across the industry, to help organizations get better at securing their supply chain and making their software better. And that’s good for everyone.

Swapnil Bhartiya: John, can you share with us… Of course, you have created this advisory board, in today’s time, it’s really hard to ask how things will look like in one to two years, right? This is what pandemic has taught us, not to talk about it, but if I look and ask, what would be some of the, either interesting, important milestone, what roadmap do you have laid for yourself that you can share with us at this point?

John Amaral: Sure. Well, on the Slim.AI company perspective, we’re continuing to become more present in the industry and this fall, we have a number of great appearances and announcements coming out. We’ll be, by that time, announcing our first GA platform, which is the extension of what we’ve been building, we’ll be at CubeCon and a number of the other conferences, making ourselves available there to be with developers and show off what we’re doing and help them use what we’ve been doing. We have our early access program right now. We’ve got users signing up and we’re certainly learning from them. Of course, we’re building more features. Building more features, both on the ability to understand and inspect and diff and understand the composition of containers.

We’ll be growing that, so that it has a natural connection to our open source capabilities. We have this pretty successful project called Docker-Slim, and we want Docker-Slim users to be able to also engage with our SAS platform together, so that they can optimize containers, understand them, keep track of them, manage them, et cetera. And you can come to Slim.AI at http://www.slim.ai to see how we’re changing. We try to keep things pretty open and show people what we’re doing as well. But I think it’s just more about building great capabilities that developers can use to solve many of the same problems. Just expanding on that as we go.

Swapnil Bhartiya: Excellent. I’ll wrap this interview with the focus, which was about advisory board. And if I ask you folks, if you can share a few tips or, I will not call it playbook, that you would like to offer to founders of other companies who are planning to create their own advisory board, what would those be? And of course, both to John and Kit share your insight to that.

John Amaral: Sure. Well, the first thing is just, understand why. The why behind the advisory board. And I think for us, it wasn’t enough to think about it as just names on a list that we put on the website. It was about solving problems for our business and for developers. And it really starts with product, for us. Everything comes from product. Build something useful. Be assured that you can do that and then be able to talk about it and let people know it’s out there and connect with the developer community.

So we always seek folks who have that background, that knowledge. Kit’s a perfect example, his background just has these great stops and his knowledge of our space, his knowledge of developers, the work he’s done throughout his career, and even now has made an invaluable to us. And then find great people that you love to be around, on the advisory board, because you’re going to be working with them if you’re trying to seek our goals, right? And we want people that fit with our culture to help us build a better culture. And Kit’s been all these things for us.

Kit Merker: It’s funny, John and I, when we met the first, I remember because we got introduced through his co-founder, who I’ve known for many years. And first time we talked, it was like rapid fire, like we’d known each other for a long time, just covering the industry and everything else. And it was very broad conversation. I remember starting the discussion there. But it’s very true that when we formalized the relationship for the advisory, it became very focused, right. We picked a couple of very specific areas around the go-to market, developer advocacy, messaging. These are areas that I enjoy doing and I can be a good sounding board for, and so those were great areas for us to focus on. Like I said before, the team has an agenda every time we come to a meeting, they remind me what the agenda is and what preparations I need to do to make sure it’s effective. So I think it’s really important. I think if you look at it from the advisors angle, and this is one of the things I’ve had to wrestle with is also being very clear about the time commitment.

And I think it’s easy to get overwhelmed and it’s fun in the first couple of weeks, but then as the months drag on and you keep having these new conversations and everything, it can become something where it’s a time pressure. And so I’ve had to be very particular about it. I’ve also been very transparent with my exact team, making sure that they don’t see it as a conflict or a diversion of priority, right. And as I’m doing more investing and advisory work on the side, it’s just something to be mindful of. Right? You got to make sure that you’re putting your effort into the things that are going to make a difference and that you’re very upfront and transparent about where your interests lie and where you can actually make a difference. And then, you don’t want to burn yourself out taking on too many side projects, which is something that I’ve done before. So there you go.

John Amaral: I’ll add one thing to that. We also set expectations internally that we’re going to put what we learned from these advisors to work right away and use it. And I think from an advisor, and I’ve been an advisor as well, and in other contexts, it’s great when an advisor sees that they’re being heard, that work’s happening and that it’s valuable to the team that they’re advising because it brings the value to bear. And I think that everyone, especially folks around software development, like to see their stuff being used and that’s something we take very seriously.

Kit Merker: Without adopting the ideas just for the sake of doing them either, right? It’s okay to discard the bad ones, which is also fine as well. Not every piece of advice…

Swapnil Bhartiya: Excellent. Yeah, that’s true. You both had, at some point, being advisor and on the both sides. So thanks for sharing those insights from both sides and also talk about the whole supply chain and the challenges that are there for containers. So thanks for a great discussion, Kit and John. Thank you. And I would love to have you back on the show and that you know already, right?

John Amaral: Awesome. Thanks for your time. Really appreciate it.

Kit Merker: Thanks, Swap.