Today we chat with Ilya Bodner, Founder and CEO of Bold Penguin, a firm that builds exchange software for the commercial insurance market. He spoke about the pros and cons of choosing Ruby early on and deciding between building or buying your core cloud infrastructure.
Ilya brought a host of good topics to the table. Bold Penguin went from one offshore developer, to one key dev, to one team, to multiple teams, multiple leaders, multiple external teams, to having a complete reboot only to go through it again. Ilya explains the lessons learned along the way.
If you’re trying to grow a software startup, you have to understand and adapt your business. Bold Penguin had to figure out if its focus was being a platform, a product, a SaaS company, an enterprise technology solution company, or all of the above.
You can check out Bold Penguin here and find Ilya on LinkedIn here.
Our lifeboat badge of the week goes to Gibin Ealias, who helped to solve the enternal conundrum: Flex align-items: center not centering.
Ilya Bodner Well, I'd say the number one thing that we run into is there is a huge shortage of Ruby ICEs. And I just talked to a recruiter last week that told me, sorry, we can't work with you at Bold Penguin because we have another customer that just said, "we want to hire 1000 Ruby developers in 2021." I laughed, I just said, I don't think there are 1000 Ruby developers [Ben laughs] that will be of the skill level you want. But it's obviously very competitive.
[intro music]
Ben Popper Hello everybody! Welcome to the Stack Overflow Podcast. A place to talk about...
Sara Chipps Heeeyy.
BP Hey, Sara! How you doing?
SC Hey Ben, how's your day?
BP I'm being tortured because I do the podcast from this nice little window alcove I have, and I actually take a lot of meetings here. And it's May so it's turkey season.
SC Turkey season!
BP And I can go I can go hunt these turkeys. But I just see them walking across my yard and I'm just working. And they're just haunting me.
SC What do you do when you hunt the turkey? Do you eat them?
BP Yeah, we eat them. We make turkey tacos, they're delicious wild turkey tacos. So I'm just being taunted right now. There's a turkey just strutting, strutting across my property. [Sara laughs]
SC That's great.
BP Yeah. Okay, so we have a cool guest on today. His name is Ilya Bodner. And he is the founder and CEO of a company called Bold Penguin. We're gonna keep it bird theme today, I think.
SC That's great. Hey Ilya! Welcome.
BP Welcome to the show.
IB Hi everybody. That is definitely not the entrance I was expecting here. [Ilya laughs]
BP I like to keep you on your toes. But you reached out to chat. So tell us a little about who you are. And what it is you do. I see you're listed here as an anti-disrupter, which I think Sara and I can get behind that. We're too old to be disruptors at this point.
IB Well, thanks for having me on this. Yes, I've obviously reached out to you guys, and excited to share the story. Currently, the founder and CEO of Bold Penguin, we're a commercial insurance exchange, we help build software for the insurance industry, very specifically for when insurance companies try to issue insurance to small businesses.
BP So I know that this is actually kind of an interesting area in the sense of you have to calculate a lot of risk and make a lot of future projections, you got to crunch a lot of data. What's that? What's that sort of role called where you're making the insurance, like making that calculation?
IB Actuarial science?
BP Yes! That's what I'm looking for. So is that what some of what your software does? Is like actuarial science?
IB We don't do that part. The insurance companies do that and very well, and there's hundreds of them. The part that we help build is think of it this way, every insurance company has their own secret sauce to Actuarial Science way to determine how much to charge a customer for the insurance that they're offering. Insurance is bought primarily by small businesses, whether it's the owner of the company, or it's your gig, or your freelancer, or your small business, usually, it's bought through an intermediary known as the insurance agent, or a broker, or some website that acts as the middle of that equation. So when a small business owner goes to find an agent, or broker or distributor, than then goes and shops around the bids to the insurance companies, that process it's oftentimes manual takes a lot of time. Put a little bit simply there's no Expedia-like site for where you can go and put in your flights and get a couple of options back. So we provide that but only for the intermediaries, only for the agents and brokers. So when a small business does end up going to somebody that uses the Bold Penguin software that can happen a lot faster, because they're bidding it around digitally, rather than by pen and paper.
BP Gotcha. So you're trying to create this, this marketplace of offers and sort of real time bidding and a lot of things that the internet has enabled for, yeah, everything from ads to plane tickets.
IB You got it. Yep.
BP Cool. Well, I could talk business all day. But this is a software podcast. So let's geek out on that a little. And Sara, I know this is near and dear to your heart. Ilya sent over some ideas, says Ruby with high performing individual contributors made this decision early on and stuck with it. So Sara, I know you skipped Ruby. We could review why. And then maybe you could tell us why you think it's actually something that the high performing folks in your firm should use.
SC Yeah, that's fascinating. Can you tell us more about why you chose Ruby?
IB We chose a language that we thought we could get into quickly, that could be flexible, and that could provide a stable infrastructure for our company, at the time, it so happened to be that we had a couple of early hires that were loving Ruby, build other projects in Ruby and felt like it was the latest and greatest that provided them the flexibility they needed. And we sort of went with it and decided that this is fine. It's not an antiquated language, it's it's going to go places, and provides us that sort of expansion that we'll need later on. So it was two parts. One is people felt good about it. And two is we felt like if we're going to choose it, we're going to get stuck with something that'll be very difficult to support.
BP How long ago did you make that decision? And has it been contentious or sort of like second guessed since then by newer people?
IB Sure. So Bold Penguin started five years ago, five years ago, yesterday, actually, that was our anniversary over Cinco de Mayo. But we made that decision a little bit before starting the company. The second part of it is, has it been argued or debated or did we even second guess ourselves. Absolutely. All the time, every time by everybody. It went from as little as just a "should we use this to move forward?" to completely replatform to what is sometimes called a religious debate about, or philosophical debate about where we should be spending our time and energy. And every time we had this argument, no matter how big or small, we always came back to the same conclusion that what we have now is great, and we need to continue to invest in ourselves. Everyone has a different opinion. And there are certainly parts of the code that are not Ruby, because of how we integrate and support some of our customers. But the core is, and you know, if you ask me today, if that was the right decision, and at every step that we re evaluated, if that's the right decision, I honestly don't know the correct answer. I think what actually made us stronger as a company, is the fact that we had the debates, we got it all out on the table, we duped it out. We told everybody how we felt about everybody in that room, in so many ways. And then we sort of you know, quote, unquote, held hands and went into it, being teammates and team players and stuck through it.
BP Sara, you're you're about to take a turn and go back into engineering management and engineering, you know, I guess—are doing both IC management in the near future? Is that the goal?
SC No, just management.
BP Just management. Okay, so you go into the room, and everybody turns to Sara, we're doing Ruby. How are you gonna handle that philosophical difference? To put it politely?
SC Yeah, I guess my question would be why? And it sounded, it sounds like Ilya, you have a good why, which is that your early engineers really liked Ruby, were very comfortable there and felt like it was a way that it could scale with your company. And I think those things make lots of sense when you're thinking about what you want to build on. What kind of challenges do you run into now building on Ruby? Do you find it something, do you find it easy to recruit for, is it a little more difficult? What are some of the things that you've run into?
IB Well, I'd say the number one thing that we run into is there is a huge shortage of Ruby ICs. Folks that really know it, not just something they did for a couple hours, or two projects ago, they were a part of, but those are living and breathing it and are deep in it. And I just talked to a recruiter last week that told me, sorry, we can't work with you at Bold Penguin, because we have another customer that just said, we want to hire 1000 Ruby developers in 2021. I laughed, I just said, I don't think there are 1000 Ruby developers [Ben laughs] that will be of the skill level you want. But it's obviously very competitive. In that sense, and very few people actually have the experience that we look for, you know, we're dealing with the boring 100 year old industry where everything is held together by shoestring and bubblegum. So we do need those type of folks that have lived and living and breathing in love it, embrace it, and can not only maintain our platform, but also interact with our customers platforms.
BP So yeah, I mean, that's such an interesting sort of dichotomy there, where it's like, it was the right choice for you, because people were into it, you know, like, now you have a team that's, you know, sort of solidified around something. But at the same time, right, there's always the supply and demand and the market. And I guess, maybe, right, if Ruby falls out of favor among young folks, and they're not learning and getting experience, then it can become a constraint down the road. Would either of you know like, let's say you did have to port like, what would it take to port to a new language where there's more where there's a better supply of young developers or talented developers?
IB Oh God, I think, I think I'm just gonna fall over. [Ben laughs]
BP Sorry, I'm not trying to give you nightmares.
IB You know, and by the way, we debate this probably every couple months. We think that you know, early on, yeah, sure. It was cool slash affordable slash flexible slash enough people knew it that it made a lot of sense. As you go further, further, it just becomes so big that the idea of replatforming is so expensive, and such a distraction that it becomes just kind of completely out of reason for even a startup, let alone in a multi billion dollar company. And so what we decided to do over time is to, of course, break it out and have different components and parts of our company they built in different languages that coexist and interact with each other. And so if that, you know, terrible, terrible day does come, where we have to completely jump off and go with another solution, at least not 100% of the code bases Ruby, and that it could be broken down and being a little bit more digestible.
BP Start to toe you into microservices. And and before you know it, you're totally modular, no problem, just switch right over. [Ben laughs]
[music]
BP So if you're listening to the podcast, you probably work in software, or know someone who does, they can now check out Stack Overflow for Teams, that's a private, internal instance of Stack Overflow just for your company or organization, your group of friends learning to code, you can share questions and answers, build up a great database knowledge that makes it easier for people to solve their own problems. You just search, find a solution, leave an answer. That way, everybody in your Stack Overflow for Teams instance, can collaborate remotely. And asynchronously, you get up to 50 seats for free forever. So you can try it out, see if you'd like it, head on over to stack overflow dot blog slash teams, and tell them the podcast folks sent ya.
[music]
BP So I have another question here that I'll throw out to both of you that Ilya suggested and I think, again, is sort of applicable Sara to where you're headed. But also Ilya can talk about such as engineering teams, we went from one offshore developer to one key dev to one team to multiple teams, multiple leaders, to a complete reboot. So I guess, Ilya, walk us through, you know, where you started, and sort of that evolution, and why that reboot came around. And then Sara, you know, I'd love to hear from you. yeah, what your experience has been like with engineering teams here at Stack Overflow, and kind of what you're hoping to work on and to build in your next gig.
IB I would, I'm going to start out with these two terrible, terrible words that are taboo that everyone tries to say they don't have. And that's technical debt. Every company, no matter how emaculate the code base is, no matter how smart you are great you are and well funded you are and this that, and the other has some kind of technical debt. We obviously minimized it. And we worked very hard to make it as close to zero as possible. But there are some things that are just inevitable. So knowing that, in the back of our mind, we just kind of knew that at some point, we'll need to scrap and redo or upgrade or take some zigzagging to make a right minimize it, of course, and try to make it as little as possible. But with that in mind, through that evolution, like many other startups, we started off as a project on nights and weekends, was an idea on the back of a piece of a napkin, brought in a couple of folks that were doing it by the hour, they messed up some things and didn't do the v1 or the MVP correctly. And then it took us a couple of tries. And so we're finally ready to do something that's client worthy, that could be presentable to customer. And at that point, we evolved from an early engineer that helped bring the effort to having multiple engineers. And then we got so big that we needed to have managers running various teams. And having folks in the office and out of the office, very good natural evolution, our company, our product, or company grew. And so the the need for feature updates started becoming competitive. There'll be internal projects and internal things we wanted to do. Some of them were quality of life, others were just necessary system upgrades. And they were external. And each client had, you know, they're all that of demand. So being the traffic cop in the middle became a tricky job. But somebody was able to funnel it together very nicely. I got to the point where it made a lot more sense for us to break up into teams to work on features. And those features could come together and sort of continue to scale our platform. And that was a very pivotal moment. That was a very important point in the history of Bold Penguin. And I often find that a lot of companies don't take that leap. And they try to stick with the same approach and same direction, because they know how that works. They're comfortable with the history of it. And they're just not comfortable breaking up into being a little bit broader. We did it. We certainly had a lot of hard days ahead of us when we first started. But I'm happy to report that after, you know, maybe it's been a year now the whole idea of having multiple teams and kind of rebooting our approach towards how we prioritize various features has actually helped bring velocity into the production of the product.
SC That's really neat, what are some of the different teams that you have work on your software?
IB We, you know, very specific to Bold Penguin, we have different parts of our platform that we can measure that have a good output. So something that we call, quote starts the number of applications that are being submitted, or something that we call, quote yield, which is a number of applications that return back a rate, system health, which of course, checks for making sure things work correctly, and on and on and on. So we structure the team around very specific business goals that conveniently support the different parts of the platform. And that actually helped clean up a lot of the ambiguity into what's important and what's not, because for the first time in a long time, we were able to say, okay, if we do this, it will have a direct impact on this number of clients, which leads to that much in revenue, and help to get everybody on the same page. Certainly still have room for improvement, and no company has ever done. There's always an evolution of that, but just clearing that up between the sales and marketing, and engineering and back devs, cleaning that up and getting that communication going a lot cleaner, smoother, at least everyone focusing for the same Northstar helped make those teams run faster.
SC I was gonna ask how do how do different features get prioritized? How do you work on that as a team?
IB So that's an evolution of its own. Certainly, if you asked me today, and then if you ask me in three months from now, the answer will be different yet again, we constantly try to tweak it. Bold Penguin for a long time was a b2b software company, enterprise software company. So we had a very small number of very large clients that we tried to maintain through a platform, we have made a conscious choice about a year ago to move to having many clients, hundreds and 1000s of clients and become more of a product that's available in the space, we have many big and small insurance agents login and do their various quoting, not as large institutions. And so because the client base started expanding, we started collecting feedback from all the different clients that goes into one central place, we then have team leads that get together with the CTO and a couple other implementation and business managers. And we hash out based on a point system, a little bit of intuition, but more and more in a point system of what becomes the thing that I like to call 'build for one, sell to many'. What is that one thing that is going to move the needle that we can build for a small subset of clients that will impact everybody. And then we of course, open it up for feature flags and global releases. So as of today, it is gathering all the feedback, internal and external, put in all and rank file for priority and work on those top two or three, broken down by month by quarter by sprint and down to the ticket level. Today, that works really well for us, because we have more and growing number of clients, and a really good foundation of our platform now, that leads to continuous improvement, but we're not constant having to reinvent the core platform.
BP Alright, so yeah, I'm gonna throw out one more question. The thing you suggested, which I thought was interesting was choosing vendors. So you were just talking about, you know, going yourself from being like, you know, serving a small sort of boutique group to wanting to be a platform with a lot of customers. And then on the other side, thinking about how you build software and how you sort of, you know, maintain your, your service? Do we go with the everything AWS? Or, you know, is there some core competency or differentiation, you want to build internally developer tools, you know, external client facing systems? So talk to me a little bit about how you make those decisions? When does it make sense to rely on other folks and, you know, therefore get, you know, the the cost savings and the speed and the scale that they offer? And when does it make sense to say this is the thing we're going to be building? Because this is going to be, you know, our moat, our differentiation in the market?
IB Yeah, that one is such a hard one and vary so much for I don't know, the audience of startups or big companies, or everything in between, I would imagine it's everything in between. But there are just such wild differences of opinion on what to build internally, what to outsource and what vendors to rely on, that it is a constant evolution. So let's start with the big ones. Like, did you go to AWS? Today, that's a no brainer, I think, in my opinion, and many people opinion on at least some of the, you know, their core offerings. But then from there, we constantly wrestle with is what we're building our differentiator, or is this something that, you know, in a year, there's going to be more companies out there that we could buy it on a SAS license fee a lot cheaper. I think what worked well for Bold Penguin was being able to get in a room, talk about it openly, at every level at the company to decide if what we're doing platform enhancements, or a feature that we're very proud of, that we think is going to move the needle short term and long term, or is it something that just feels good and maybe just have some short effect. Once you get through that conversation, we're able to go back and say, okay, we're gonna invest in building or we're gonna invest in partnering with the vendor. If we go down the path of partnering with the vendor, then for us, it's an easy to segment, we always just look for in that respective category for two or three that are the best for by talking to other people by getting actual references by discussing with, you know, someone who markets or comes back from a Google search fastest, getting real experiences, getting good demos, getting a you know, some kind of a short trial, to put something together. And that vendor select a process, you got to be able to hire slow and fire fast. You know, there, there's a lot of learning lessons of having the wrong vendor where you got to stop, drop and roll and get a new one. But I think it's just the constant evaluating and re evaluating you drive yourself a little bit crazy. But being able to do that allows you to really, really chisel down to building the things that are, as you call it, your moat, versus the other things that are just table stakes that you have to in order to be part of the industry.
BP Sara, can you relate to that? I know people yeah, pilots Stack Overflow for Teams. And often it's kind of a Bake Off with a bunch of other solutions that they have from other vendors as well as Yeah, often their own sort of internal role your own knowledge base or QA.
SC Yeah, that definitely makes sense. I think what we do focus on that a lot, as well as the features that will set us apart from other knowledge management solutions, and what our customers are asking for, balancing those things. It's always a challenge.
BP I was gonna say, Yeah, like I said, I think I know we have a little bit of a roll your own thing here at Stack Overflow, right? There's a lot of systems that we built over time that maybe looking back on it, we wish we had gone with a vendor, we did our own email, our own search, our own everything.
SC Yeah, we replaced those a lot. We did our own email, our own out of office tool, all types of things.
BP Yeah, our own billing. Yeah, we built it all. Engineering culture through and through.
[music]
BP Alright, folks, it's that time of the episode, I'm going to shout out a lifeboat badge winner, that's somebody who came on to Stack Overflow and answered a question that had a score of negative three or less, and their answer got it up to a score of 20 or more so save some knowledge on the dustbin of history and made it something useful that everybody can touch. Today we have a lifeboat awarded yesterday to Gibin Ealias with a really beautiful duck avatar. "Flex align-items: center not centering items." Sara, I know you've been here. Centering.
SC Yes, centering. It's the hardest. [Ben laughs] It's the worst.
BP It's the worst. Alright, y'all check out the life boat in the show notes. I am Ben Popper, Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper, email us podcast@StackOverflow.com. You can find this podcast anywhere fine podcasts are sold. And please, if you liked the show, do leave us a rating and review really helps and share with your friends. Thanks, Ilya, who are you? And if you're on the internet and want to be found, where can people find you?
IB Just boldpenguin.com or on LinkedIn you can find my profile as well.
BP Terrific. Sara, who are you?
SC I'm Sara Chipps, Director of Community here at StackOverflow. And you can find me @SaraJo on GitHub.
BP Wonderful. Alright everybody, let's turn off our recording in 3, 2, 1...
[music]