Free Form AI

Michael Berk (00:00)
Welcome back to another episode of Freeform AI. My name is Michael Burke and I do data engineering and machine learning at Databricks. And I'm joined by my lovely co-host with his fancy shirts. His name is...

Ben (00:10)
I'm Ben Wilson. ⁓ I write proto definitions for open source REST interfaces at Databricks.

Michael Berk (00:19)
Cool. Yeah, I think, sure, probably. Today we're speaking with Mary Moore-Simmons. Mary studied engineering at Harvey Mudd and after graduating, she entered industry taking several projects and engineering managing roles. In 2019, she joined GitHub as the director of engineering or one of them probably. And most recently she became VP of engineering at Kibo, the AI agent for cost performance optimization on Snowflake and Databricks.

Ben (00:19)
That's a new one, right? I haven't used that one before.

Mary Moore-Simmons (she/her) (00:36)
you

Michael Berk (00:45)
So Mary, before we get into the AI stuff, what did you do for Kona Coffee Farmers Association?

Mary Moore-Simmons (she/her) (00:52)
I love this. This is a deep cut. Yeah, so I worked on, this was Wack when I, so I started out as a chemical engineer actually. And so this was a project I did with the Kona Coffee Farmers Association to build a better way for them to dry their coffee beans. So all the coffee beans for Kona, they have like a Kona coffee, and now I'm gonna go into a whole rabbit hole about coffee. Kona coffee is like very good. It's sort of like known.

around the world to be very high quality and they do things pretty old school and so they dry their coffee like in air. So they just once they pull the fruit off the coffee beans they dry them on these concrete pads but sometimes it rains in Hawaii and sometimes it's humid. ⁓ So they would sometimes have problems with molding if they and then they just you have to throw it out. So ⁓ I worked with them to develop a better way to dry

there are coffee beans on their concrete pads.

Michael Berk (01:49)
that work.

Mary Moore-Simmons (she/her) (01:49)
We actually, worked exactly like we just installed. ⁓ You know how in houses they have like the hot water going through the floor to like heat your floors? We did the same thing and it worked incredibly well. So, yeah.

Michael Berk (01:58)
Mm-hmm.

so like roasting from the top and the bottom, but not roasting, just drying. True.

Mary Moore-Simmons (she/her) (02:05)
You're not roasting, just drying, because it has to be gentle because

you don't want to roast it then. You need to dry it first before you roast it, otherwise you ruin the whole thing. So it's like a gentle drying. Yeah, a lukewarm drying method. Yeah.

Michael Berk (02:13)
So a lukewarm roast.

That's

super cool.

Ben (02:18)
passive radiant heat that's brilliant actually

Michael Berk (02:21)
All right, and then you decided to pivot a little bit. So ⁓ I'm curious, how did that transition, like, sounds like a fun project, but you sort of transitioned into project management specifically. How was that?

Mary Moore-Simmons (she/her) (02:25)
Hahaha

Mm-hmm.

Yeah, so ⁓ I was working as a chemical engineer for a company that made spectrometers. ⁓ our manufacturing department, it was a very small company. a ⁓ spectrometer, so essentially it uses light bouncing off of molecules to tell you what is in a thing. ⁓ So you bounce a particular ⁓

Michael Berk (02:48)
What's a spectrometer?

Mary Moore-Simmons (she/her) (03:04)
frequency of light off of a substance and like based on what like type of light it bounces back, you can tell what's in that thing. ⁓ So we like, yeah. It's physics, applied physics. Yeah, when I hear about, ⁓ my gosh, when I hear about the fact that like there's like ⁓ intricately linked particles that like if you can spin one one direction, you know that the other one is spinning the same direction like light years away.

Michael Berk (03:14)
Black magic, got it. Black magic, got it.

Ben (03:16)
That's physics man. ⁓ Yeah.

Mary Moore-Simmons (she/her) (03:33)
It's physics, but it sounds like black magic.

Michael Berk (03:36)
Yeah.

Mary Moore-Simmons (she/her) (03:36)
They're actually

Ben (03:36)
Yeah. Not only

are those pieces of equipment insanely expensive, but I can neither confirm nor deny that I got in trouble many, years ago for putting samples that shouldn't be put into our mass spectrometer just to see like, what's in this cookie out of a company. They're like, dude, can you stop trying to break our million dollar piece of equipment? Like, yeah, I'll stop.

Mary Moore-Simmons (she/her) (03:50)
Thank

Ha!

⁓ Yeah, I went to a math and science school and I did a lot of work in the chem lab at my college and I did some research there and I have done, I think worse, so I think you're fine.

Ben (04:13)
They're so fun though. Like if you're,

if you're like a physics nerd or a chemistry nerd, like being able to like play around with, with those or like the PL like wavelength measurement thing for material science to be like, how does this crystal lattice actually like form in the substrate? And like, what is the molecular arrangement? Being able to just play with that stuff. You're like, taking everyday thing like, oh, I brought this from home. I wonder if anybody's going to notice I'm going to mess around with this. It's just super cool. Yeah.

Mary Moore-Simmons (she/her) (04:38)
The answer is they totally noticed.

and physicists get the coolest toys.

Ben (04:46)
correct.

Mary Moore-Simmons (she/her) (04:46)
Yeah. yeah, sorry, sorry. Sorry. So we were making spectrometers ⁓ and I was doing some like, it was a small company. So I was doing R &D work for them, researching like new things that they could use their spectrometers for. I was doing like sales engineering for them, like helping them like do technical sales. ⁓ And when I was doing the sales engineering stuff, I noticed that our customers were mad because we kept delivering stuff late. And so I just like talked to her.

Michael Berk (04:48)
So project management.

Mary Moore-Simmons (she/her) (05:15)
to our manufacturing department of like five people. And I asked them what was going on and there's, and there's just like little things like, we forgot to order the screws on time or, ⁓ like ⁓ there is these specific blast, these specific EU approved blast proof cases that we put on the spectrometers because some of our customers were oil and gas. ⁓ And they were like the only, there's like one company that made these and they were in Italy and they were always three months late.

And so we were always three months late for our customers. so they're like, well, we're three months late because these Italians won't ship things on time. Like, why don't you just tell the customers that it's going to be three more months? Like, why don't you just tell them at the beginning, it's going to be a six month leave time. So I just little things like that. I ended up like project managing, essentially our manufacturing department to in addition to the other things. And then I wanted to move out of California because I'd lived there my whole life.

and I didn't want to be like a boring person. Sorry to anyone who's lived in the same place their whole life. I was worried I'd be boring if I lived in the same place my whole life. And so I was also living in, again, I'm probably going to insult more people, Sacramento, which is like not the funnest town. I'm from there and I feel like I'm allowed to say it's not the most fun town. And I wanted to like get out. So I just took a job somewhere else. And the easiest job to find was a project management job.

Michael Berk (06:18)
valid concern.

OK. Heard. So you basically were very type A and then just started managing stuff. Is that what?

Mary Moore-Simmons (she/her) (06:45)
I dislike inefficiency. And I think that that is still true today. I dislike inefficiency.

Michael Berk (06:48)
Okay.

What is out of

curiosity, I also dislike inefficiency, but what's the emotion for you? Is it like anger? Is it like, like for me, it's anger. That's why I said that.

Mary Moore-Simmons (she/her) (07:02)
That's a good question. ⁓ The thing that I just keep thinking is like, why? Why are you doing this to yourself? I don't understand. And so think maybe it's like confusion mixed with a little bit of frustration. Like, what are you doing? Why are you flogging yourself?

Michael Berk (07:04)
Like, why does it piss you off?

Got it. Confusion, yeah.

Okay.

Ben (07:21)
Do you think that was ⁓ something that you gained from early childhood or is that something that was from your studies as a chemical engineer? Because I used to work with a lot of chemical engineers and almost all of them had that personality trait. There's a process that we should follow that optimizes the amount of human effort and maximizes the quality coming out of this. We should not deviate from that and continuously improve it. And it is like, that was their mantra.

And I'm just wondering, I came from a nuclear engineering background where we didn't do that type of stuff. It was more meticulous attention to detail, but chemies were always like, we need to improve this. So did that come from your school or is that like just who you are?

Mary Moore-Simmons (she/her) (08:02)
I think it's who I am. ⁓ I have a lot of cool stuff I want to do and I don't have time to waste. I'm only looking for parking. Whenever I'm looking for parking, I get very upset and then I think that's 90 seconds of my life I'm never going to get back. ⁓ I think it's just who I am. I don't have time for bullshit. I just want to get stuff done and I don't understand why I'm doing annoying things that aren't fun things.

Ben (08:31)
Mm-hmm. Attracts. So I guess that core personality type just attracts people to the chem education.

Michael Berk (08:31)
Whoa, okay.

Mary Moore-Simmons (she/her) (08:32)
Hahaha

Yeah. Yeah, I actually,

I recently, this is interesting because I recently, my, was, went to physical therapy recently for an injury I had from running and my, I don't consider myself a runner because I swam my entire like childhood and through college and played water polo. So I don't consider myself a runner, but I run every day. And ⁓ I've, enough physical therapists have been like, you runners are ridiculous. You just constantly just like run on injuries. You refuse to rest.

And was like, I guess I am a runner because apparently my personality trait is masochist. So...

Michael Berk (09:10)
Yeah, interesting. so project management. And then you pivoted a little bit once again to be more engineering lead. How did that happen?

Mary Moore-Simmons (she/her) (09:14)
Mm-hmm.

Yeah, so I had done software engineering in college. ⁓ like, shout out to Harvey Mudd. They forced me to learn a lot of things and I'm pretty happy about it. ⁓ And so you had to take computer science classes and I did enjoy them, although coding does give me rage, ⁓ but I did enjoy it even though it gave me rage. ⁓ And so I was working in project management at a software company.

⁓ And that was like how I moved into software. And so I knew how to code. So there were places in which I could help out with like, you know, more coding type things. That company did marketing for hospitals. And so a lot of what they did is take like gross data and put it into like databases so that they could market to people. And so I could help with it was like fairly simple stuff that I could help with. And so that's how I started actually like coding professionally, even though it wasn't really my job.

⁓ And then that's when I sort of like went into software more ⁓ intentionally.

Michael Berk (10:18)
Got it. Did you enjoy it?

Mary Moore-Simmons (she/her) (10:20)
Yeah, I did enjoy it and I was able to code both there and then also at SendGrid a little bit. But then again, every time I go into something technical, I end up getting still frustrated about inefficiency and then trying to solve it.

Michael Berk (10:36)
Yeah, so it seems like a theme throughout your career has been you want to, like you see problems and you go and actually just start solving them and that becomes your job. That's something that I know Ben, you preach. I'm curious, is this like a foolproof strategy where you can just like transition within an org or like, what are your thoughts around that?

Mary Moore-Simmons (she/her) (10:44)
Mm-hmm. Yeah.

Ben (10:54)
thoughts? I've for my entire career, I've been an inmate runs into the asylum sort of person. you always, if you want to go and do something, you can ask permission to do it. Well, it's like to learn a new major skill, just like Mary, you were talking about like, their like code needed to be written. I'm going to go just do that. If you want to make a career transition, the easiest and most expeditious way to do that, just do it.

And then beg for forgiveness if somebody gets pissed off, but do it in a humble way that you're like, Hey, I'm just trying to help. I've never had somebody be like, stop helping. If it's something that is like, Hey, it needs to get done and we don't have time to do it. And you're willing to learn it. I've every single time I've done that in my career for like even, in entire profession shifts that I've done to different industries. People are always like.

Thanks for the help. Do you want to do this full time? Like, yeah. And they're like, okay, we'll transition you into this. Sweet.

Michael Berk (11:51)
curious, I feel like there's the two main fears that people would have is one, getting punished for doing stuff that's outside their job description. And then two, they're now on the hook to deliver something that's important. If they're working on important things, it has to be done. So how do you handle both of those?

Merry as well.

Ben (12:05)
I think both of those

are, are, are ego based fears, right? Like the only time that those actually matter, that's only within your own head of like, I'm to get in trouble. Like, no, you're not, you're helping out. People are not going to get mad at that unless you, unless you help out in a way that's not helping and you just break stuff. Then yeah, don't do that or learn from that and do it better next time. But, and that fear of like, ⁓ no, like

now people are going to expect things of me. Like you should go for that. Like that should be the motivating factor of like if you want to go and do something, put that stress on yourself. It'll push you to get better at it. That's my take.

Michael Berk (12:41)
it's here.

Mary Moore-Simmons (she/her) (12:42)
Yeah, I think people are only going to tell you to stay in your lane if you're annoying them. It's like and and I will say that as a person who's been told to stay in my lane several times and I know it's because I was being annoying while I was trying to do something. So if you're if you if you're helping and you're doing it well and you're like being kind and not like pointing out problems that other people are causing, then ⁓

then people are gonna be more likely to accept your help. I say this as a person who does not do this well sometimes. ⁓ And yeah, I think the other fear is that if you are helping, then you have too much to do and then you're overloaded. I think that's a fear. so that's, I know, just something to like make a plan around. ⁓ sure that you're still, make sure that the thing that you're supposed to be doing is easy enough that you can get it done in less time.

Ideally, you're doing the next thing because the thing you're doing now is boring because you've already mastered it.

Ben (13:39)
Yeah, exactly. Or you've worked on automation as part of that process. Or as you said before, and we were talking about, figure out the most efficient process so that you're not doing the bullshit that you don't want to be doing.

Mary Moore-Simmons (she/her) (13:41)
Yeah.

Michael Berk (13:50)
Alright, okay. So you keep shifting your role a bit, you try different areas. How did you get into engineering management specifically? You said you were a team lead, does that qualify?

Mary Moore-Simmons (she/her) (14:01)
Yeah, I think that's what happened is that I got into engineering management because like I was doing coding things, but then I was also ⁓ helping again with project management. so as it turns out, in my opinion, the best engineering leaders are good at people stuff, technical stuff, and process project management stuff. ⁓ And so that's sort of how I got into management is like I was doing the technical stuff, I was doing the

I was being good with people and I was doing the project management stuff. And so they're like, hey, do you want to like manage people then as a real job? And that's how it happened. Yeah.

Michael Berk (14:39)
curious, what were the skills from project management that made you a good manager for engineering?

Mary Moore-Simmons (she/her) (14:45)
⁓ the, the two, like one of them was just like project management fundamentals of just like everyone in engineering is doing agile and scrum. And some of the projects are longer and might need more waterfall type planning. There's a lot of planning around engineering that needs to happen. People are always, engineers are very expensive. And so people want to know what they're doing and how efficient they're being and when they're going to get stuff done. And also they're the core of delivery to customers.

⁓ at a software company. like, they're the most important thing that has to be efficient and works well or else the business gets very grumpy and probably won't do well. ⁓ But also, ⁓ one thing that I like to do that I think a good project manager does is just, like, grease the wheels for everybody. And I think that that is something that managers should be doing, is they should be just,

clearing roadblocks for everybody and like greasing the wheels so that everything is just easier to get done. And I think that was the skill that I think is the most important skill. Like, yes, there's like project management fundamentals and blah, blah, but you can read that in a book. I think the important thing is just a sense of how do I grease the wheels so that everything just works better. And I think that that's something that a project manager, a good project manager does, although I think that this is another hot take. think 95 % of project managers are trash.

that are mostly bad, but maybe that's actually true.

Michael Berk (16:04)
You were worried about offending people

for saying Sacramento is not that fun? You say that.

Mary Moore-Simmons (she/her) (16:09)
So I remember someone said

trash. 95 % of project managers are not useful to me. How about that? But maybe 95 % of most people are bad at their jobs. So maybe that's not actually anything different. So yeah, so a good project manager should be greasing the wheels and greasing the gears and everything's just moving smoother. in a lot of ways, people are just like, I don't even know what they did, but everything's just better now.

Michael Berk (16:20)
status

Mary Moore-Simmons (she/her) (16:33)
And that's what a manager should be like too. They should just be like, they should just show up and everything should just like be better because they're around.

Michael Berk (16:39)
Can you give a tangible example?

Mary Moore-Simmons (she/her) (16:41)
Yeah, so a good example, let me think of like a small thing that came up recently. ⁓ Our escalation process from ⁓ our support team to engineering is like a little rocky at Kivo. It was because it's like a new thing. Our customer set is growing. ⁓ And so I just went in and said like, okay, cool. Well,

why don't you just like, here's a form that you fill out. It'll automatically open a JIRA ticket. And then that'll automatically go to the on-call engineer, dear on-call engineer, just like look at this board when you get up in the morning and work on the things. And it was just so much better than, my gosh, there's all these Slack threads everywhere. And I don't really know. And like the CEO's like, why haven't you responded to this? The customer's mad because we haven't talked to them in two days and they reported it. It's like.

That was it. was just like, just a little thing of like, fill out this form. It opens a JIRA ticket. I tell the oncology to look at the JIRA board and none of that like problem happened anymore.

Michael Berk (17:40)
Clear. Well said, alright.

Ben (17:42)
Yeah, it's efficiency. Like I remember before we had that system and what the chaos was. And then it was, think it was like an, an EM1, a, like a first line leader manager who did the same thing at Databricks was like, why does this exist? Like, let's just automate this. And now it's like fully automated. There's no form. It's like customer files, a ticket gets like

Mary Moore-Simmons (she/her) (17:44)
Yeah

Ben (18:05)
triaged and then there's like automation to just send it to the right team.

Mary Moore-Simmons (she/her) (18:09)
Yeah, I really like, I think that process creation should also be agile. Like you should just like do the smallest thing that makes it better and then like figure it out later. And yeah, and then I know that eventually as the company grows, like that'll become like a totally automated system for now. It's just like fill out a form and there's a ticket and it's so much better than it was before.

Ben (18:15)
Yes.

Yeah, I think you bring up a fantastic statement about a related topic to what makes an engineer manager awesome is like focusing on that, that agile methodology, not as a box to tick of like, yeah, we're agile. do, we do scrum. Like everybody does that because it's just the standard, but not, not a lot of engineering organizations actually live that life.

with respect to making sure that product managers and project managers, and if you have a project manager or you have like a TL that's doing that, like having everybody aligned on, no, we're actually doing incremental releases. We don't, we're not signing up for Scopecreate ever. Like we release minimum products and then respond to feedback and improve them as we need to. What, like, what's your take on that? It's almost a...

like a pattern of default human behavior to want to release the most excellent thing. And how do you rein people in from preventing them from doing that? So like, no, we need to stick to just the minimum thing.

Mary Moore-Simmons (she/her) (19:31)
Yeah, I think there's the way that it's hard. It is really hard. And I will say that like none of I've never felt like I was doing this well. I don't I've never like been in a company where I was like, yeah, we're crushing it at doing like minimum MVPs and iterating. And you're right, it is usually that people want to over scope things and like over engineer things. For engineers, the like the way that I get them to do it is there's like two things that you have to do. One of them is say like,

Customers might hate this. So like if customers hate it, then what is the point of like engineering it to be beautiful? Like just make it, just like put it in front of them. And then if they like it, then great, we'll go make it not terrible ⁓ on the backend. ⁓ But if they do, then if they don't like it, then awesome, you didn't waste a ton of time. So like don't waste your time on something that we might throw away. That really helps with engineers. But the other piece of it is you actually have to like follow through on letting them fix it.

Ben (20:26)
Yeah.

Mary Moore-Simmons (she/her) (20:26)
when the

customers like it. Otherwise they stop trusting you. ⁓ So like that's the important thing. And I think maybe that's also, I think why a lot of engineers like to over engineer things is because they've had a horror stories. Well, there's, mean, the one of them is like, they want to make a beautiful thing. But ⁓ the other reason is like, they've had things that they have poorly engineered to hit a date and then it just like pages them all the time at 3 a.m. and then they don't have time to fix it.

And then they're like awake at three in the morning, pissed off trying to like fix the tech that they created a year ago because their manager won't let them have time to do it. Not at three in the morning. So like you got to do that. You got to like on the back end actually like fulfill your promises. ⁓ that helps with engineers. ⁓ it's harder with product people because they're held accountable for selling, ⁓ really like they're held accountable for whether or not their product sells. And so it.

is it's actually not in their best interest. Like if we would talk about politics wise, it's actually not in their best interest to scope it down to the smallest thing possible. It's in their best interest, and I know this is gonna sound rude, but like it's in their best interest to scope it large and then blame engineering for being slow. ⁓ That's actually like what, if they wanted to do the thing that would be best for them, that's what they should do. ⁓

So that's even harder because they're held accountable for building a product that customers want and because you don't know what it is that customers want until you try it, you kind of just want to throw everything at the customer and hope they buy it. ⁓ Yeah, so that's harder. Honestly, the best way I figured it out is just building good relationships with my product folks and building trusting relationships where... ⁓

Michael Berk (22:01)
How do you manage that?

Mary Moore-Simmons (she/her) (22:13)
I'll basically say, cool, my engineers are going to iterate quickly on stuff. They're going to build small things and they're going to iterate quickly. And whenever you feel comfy with it going to a customer, that's on you. And maybe once you see the first thing we do, maybe you'll feel better about it. Maybe you'll feel better about putting it in front of a customer and least getting feedback. But we're going to go fast and we're going to iterate quickly. And it's going to sit there behind a feature flag ready for you.

and I'm gonna talk you through it and hopefully you'll put it in front of a customer. I don't know, that's the best thing I've come up with, I don't know. It's not, again, not perfect. This is why I'm like, I've never done this well, I don't think.

Michael Berk (22:49)
Well, no, that makes perfect sense. Basically, if you have engineers be the creators and then product is sort of the gatekeeper for what is good enough. And they also go gather feedback and help engineers iterate. It's now not a big sell initiative. It's more of like, is this good enough? All right, sweet. On to the next one.

Mary Moore-Simmons (she/her) (23:05)
Mm-hmm. And then selfishly, I just like to have engineers regularly deploying to prod because ⁓ it's like the mental overhead of having to keep something big in your head that you're working on is like, it's mental overhead. takes up a lot of space in your brain. And when you deploy something to prod, like it helps you not think about it as much anymore. And so I kind of like that iterative, like, okay, I can flush the cache and like move on to the next thing.

Ben (23:30)
Yeah, I could not agree more. particularly the thing that terrifies me when working on projects is when I have to cut a feature branch. Not, just like, I'm cutting a branch. It's more like, I can't merge this to main branch because we need to do pseudo waterfall even for the first like agile deployment, because this thing has, you know, 37,000 lines of code in order to implement just the MVP.

Mary Moore-Simmons (she/her) (23:38)
Mm-hmm. Mm-hmm. ⁓

Ben (23:57)
And when I start working on that, like, I got to have all of this in my head in that feature branch because we're going to do a bug bash six weeks from now. And I had better remember what the heck I did on day one and like why I made that decision. then, but once you merge it, you're like, Hey, all my tests are passing. Bug bash look good. We're I can, yeah. Do the, the brain flush and be like,

Well, it's now a maintenance problem. Like when I'm on rotation again, I'll go and look at my code and fix it if I have to. But yeah, it's a huge burden. It's like you can't multitask very well when you have that in your head.

Mary Moore-Simmons (she/her) (24:29)
Mm-hmm.

No. I've had like, I feel very fortunate that my partner is also an engineer because he's tried to talk to me after hours when I've been like coding something and I've been like, no, you're not going to talk to me right now. You, you talk to me. I have five matrices in my head right now. This is not, this is not going to go well. Go away.

Ben (24:47)
I'm in the zone.

Michael Berk (24:53)
You

And he gets it because he knows he's been. Cool. So going back to sort of your career, you worked at GitHub sort of in between Kibo and all the other project management stuff we were talking about. ⁓ What did you do there?

Mary Moore-Simmons (she/her) (24:58)
Yeah, he's like, got it. Yeah, you know.

⁓ Yeah, so I did two different things. I was ⁓ over their communities group, which is I know a very broad word. ⁓ GitHub reorged a lot, so I was the director of basically two totally different departments while I was there. ⁓ One of them was focused on, there was a community and safety team. There was a team called GitHub Education, which gave away GitHub for free to colleges and built a

tools that help professors use GitHub at colleges as sort of like an early customer acquisition program. It's actually incredibly successful. And ⁓ GitHub sponsors, which allows you to sponsor open source developers. And then halfway through GitHub, I shifted to own their billing team. So then I was just in charge of their whole billing org for a while.

Ben (26:00)
Yeah, I kind of heard that that company took off a little bit. Like just a little.

Mary Moore-Simmons (she/her) (26:06)
Yeah, just a little.

They got bought by Microsoft, ⁓ so that happened. ⁓

Ben (26:11)
so you're in there like pre that acquisition. ⁓

Mary Moore-Simmons (she/her) (26:14)
I was there during the acquisition or sort of

like the acquisition had just happened or something when I started. It was like right around and after I started, so the engineering team at GitHub was 800 people-ish and then Microsoft added 800 Microsoft engineers to the engineering team. And so then the team was like half GitHub, half Microsoft people. So that was a very interesting experience. Those two cultures don't mix super well.

Ben (26:31)
Mm-hmm.

Yeah. Microsoft, every interaction I've had with their engineering team, it's like, I'm talking to somebody who's like genius level intellect, but they have this mental model of how things work that a startup just like does not grok.

Mary Moore-Simmons (she/her) (26:54)
Yeah, because I was on the billing team, worked, there was a lot of like, we were doing integrations with Azure billing so that people could buy GitHub through Azure. And so I had to end up interacting with a lot of like people at Microsoft to try to get like things set up and things approved. And have either of you ever gone through like a permitting process for something like with a city? Okay, it's like the same thing. It's like,

Ben (27:17)
Yep.

Mary Moore-Simmons (she/her) (27:21)
You go, and I didn't realize it was like that until I actually just recently did a project on my house that needed permits and I had to interact with the city of Denver and I was like, my God, this is exactly like Microsoft. You would just show up and you'll be like, hey, I need to do this thing. And they're like, I don't really know how you get that done. And I'll be like, okay, well, I found this form in this like thing on this website and I filled it out. They're like, that's the wrong form. ⁓ You got, and then I'll be like, okay. And then I would fill out another form and then I would,

Ben (27:46)
Yup.

Mary Moore-Simmons (she/her) (27:51)
I would like send a notification to some team. They'd be like, I don't know why you're contacting us. This isn't the right thing. And you need to fill out this other form. And then I would fill out the other form and they're like, ⁓ OK, yeah, we're definitely not the right team. It's this other team now that you filled out this form. And then eventually you would find a project manager and they'd be like, actually, you just need to talk to Sue. She'll get you fixed up. And I'm just like, this is the worst.

Michael Berk (28:11)
You

Ben (28:12)
Yep.

Yeah. Every interaction I've had with them, and there's a couple other companies that are partners of ours that are, they're very similar. It's like this horror show flashback for me to the last job that I had in the Navy, which was, ⁓ procurement and design of tugboats. The Navy has eight of them left back in the pre-World War II. They had like a thousand and the ones that are still left are from that era. So we had to like,

Michael Berk (28:17)
Yeah.

Ben (28:42)
refurbish and design new ones to replace the ones that were falling apart. figuring out like, who do I even talk to in the DoD to get funding for this? And the phone tag that happened lasted like a full five weeks of me on the phone, eight hours a day, calling around to all these different numbers and people like, ⁓ yeah, you need to fill out this set of forms. You go and download it from like the...

the central repository. like, this is 1200 pages long. I'm not filling this out. Call the next number. they're like, oh, wait, no, you don't need those forms. Like, just give us a design doc. Like, okay. And then you can talk to the next person. You didn't use the proper design doc form. Like it needs to be converted. And like, okay. And then you talk to the next person. like, oh, this needs to be wet signed, like wet stamped. And you need to like courier this to us.

Okay, I'm just going to get on a plane and I'm going to fly down to DC and deal with this in a week. Yeah, that was the only way to get it done. But Microsoft definitely for our interactions, it's like, this is like the federal government. This is ridiculous.

Mary Moore-Simmons (she/her) (29:47)
Yeah, the vibes are similar. It makes me wonder. I think I might be an optimist, but I believe that it is possible to not be so bad at stuff. Well, can be, again, back to efficiency. I believe it's possible to not be so inefficient, even when you get larger, you just have to care. But it just feels like, I don't know, it kind of reminds me of like, this is a hot take. Sorry, I'm full of hot takes. But as a leader, you are not,

Michael Berk (30:09)
please.

Mary Moore-Simmons (she/her) (30:14)
⁓ incentivized to care if your people are happy. You're only incentivized to like get results. ⁓ And as long as your people are just happy enough that you're still getting results, like nobody cares if you have like good culture on your team. That's my hot take, which is I'll have a whole thing about that. But I feel like that it must mean that like maybe big organizations are just not incentivized to be efficient, like or something. Like there must be, it must maybe it doesn't matter. I don't know.

Or maybe when you get big enough you're too big to fail and it doesn't matter anymore.

Ben (30:44)
I think a lot of it, at least what I saw while working in the US government, in the military was the reactionary culture. So everything is a knee-jerk reaction if the problem is big enough. And what is the reaction to a problem? More bureaucracy. Like, ⁓ we screwed this up and this was really bad. Instead of them saying like, what in our culture allowed this to happen? Let's fix that. They're like,

No, we're going to just make this so painful for somebody to even go through this process that they need 37 signatures on this form. And most of those are pencil whipped anyway, because the person signing it has no context or, or even competency in that, that layer. It's like, if you slow things down, I guess the thought is there's less of a chance of something going wrong again.

It infuriated me. That's one of the prime reasons why I was like, never again am I like, I'm not staying in and I'm not like taking any of these contracts with the US government ever again.

Michael Berk (31:45)
And how does your team do it though? Because I know with postmortems, it's a big write up and then you add CI checks, is pretty minimal overhead typically. But are there other instances where there's actually a lot of bureaucracy involved when something goes wrong?

Ben (31:59)
We avoid bureaucracy, like we avoid contracting the bubonic plague. ⁓ Databricks is so against adding layers of red tape because it stifles innovation and it pisses engineers off. Like we're all professionals and we all understand it's a no blame culture. So you do something stupid, like you're human, right? Unless it's something that was intentional, then it's like, all right, you're fucked.

Like you intentionally did something wrong and you knew better. ⁓ but if it's an honest mistake, nobody cares. The only thing we care about is blaming our, our processes in our culture of saying like, like this was inevitable. This was going to happen. So it's not this person's fault. How do we build a system better and more efficiently in order to make sure this doesn't happen again? And sometimes that is we need integration tests.

or we need to make sure that like how this was built needs to be refactored in such a way that this can't happen again. That's how we do it.

Michael Berk (33:00)
Okay.

Mary Moore-Simmons (she/her) (33:00)
Yeah,

that's amazing. have also, because I came, so when I was at Sangrid, was mostly working in DevOps. And so I have developed a lot of like strong opinions about post mortems and how to, after outages and how to do it right. And I cannot agree more. It's really easy to just like add a checkbox to a checklist that somebody has to follow. like, or instead of doing that, you could just, yeah, write an automated test ⁓ and then.

You don't have to remember to like check the box on the checkbox list, which is annoying and nobody likes it anyway. And yeah, and like not exactly like the whole, the blameless post-mortem culture. The reason why blameless post-mortems are important is because you need to get rid of ego so that you can get into what are the systems that caused this failure and how do we fix the systems? So I actually, every company I go to, do a training on how to do post-mortems because

⁓ There's always something where like, I'm always at startups where we're like scaling and so there's always going to be outages if you're scaling. And so it's always something that I need to train people on because it's like, look, it's fine. We need to get better. We just need to get better. And we can't get better if we're not reflecting well.

Ben (34:14)
Mm-hmm.

Michael Berk (34:14)
What are the root causes that you typically see of issues like that? Is it culture? it like, what is it?

Mary Moore-Simmons (she/her) (34:21)
There's a lot. The most common problems in a scaling organization for why outages are happening are we didn't have enough visibility and or like we didn't have enough observability. That's like the most common problem. We don't have enough insight into how our systems work. Only like Bob understands this system. And so yeah, like actually, so yeah, that's the other thing. It's like knowledge sharing. So observability and then like lack of knowledge of our systems.

Because when you're scaling fast, you're going to be, to the agile point before, we are intentionally just building just enough to get it done for now so that we can put it in front of customers, get feedback, and move on to the next thing. ⁓ And so that is going to create scaling problems. It's going to create problems with code being brittle. ⁓ And so it's usually like, how do you get better observability? But that includes signal to noise ratio. ⁓

Like how do you share knowledge better? Those are usually the big problems. Everything else is just like technical problems that are totally solvable. But you just need to like see the, you just need to have enough information to solve the problem.

Ben (35:24)
Yeah, one of the things that burns us, I mean, I think it's something that even if your organization gets big enough, your sub teams in engineering are going to operate like a startup sort of, unless you're working at a company that believes in lots of bureaucracy. But if you are a true agile shop, you know, at first your engineering org of 20 people is going to be like, just like you said, like, yeah, Bob knows this system because Bob built this and nobody else, like people reviewed his code, but

don't understand like why he made these decisions. And then Susan built this other system and she really knows that. But as you, as you grow and these become production systems, you're going to still be innovating. even within that sub team, you're like, well Ben built this and Ben knows this. It's not helpful if every time that system has an issue, you just contact Ben and like, go fix your stuff. It's more like you need to

Like the way that we approach it is kind of cross training by pairing people up. Like, hey, you're going to respond to like the easy tickets at first that come up about this service that this other person built and there your backup so that you can like cross pollinate knowledge and people understand the code base.

Mary Moore-Simmons (she/her) (36:32)
Yeah, because Bob needs to go on vacation.

Ben (36:34)
Yes.

Michael Berk (36:35)
Powerpuff.

Ben (36:37)
And Bob shouldn't be ⁓

on pager duty while on vacation just in case.

Mary Moore-Simmons (she/her) (36:41)
Yeah, exactly.

Michael Berk (36:42)
Yeah. So one more topic that I'm interested in. ⁓ Kibo has a lot of potential to optimize some inefficient processes, both at Databricks and Snowflake. There's a lot of incentive. I'm not saying we do this, but there's a lot of incentive in theory to not optimize. And it's been really interesting to see our culture is very focused on doing what's best for the customer. So often that means cost savings. But theoretically, a job that is oversized, I mean,

If no one's complaining, we're making more money. Like there's not a lot of capitalist incentives and the rationale for Databricks at least is that at least a churn and less happy customers. So it actually does make money in the end. But I think there's a nice place for external processes to optimize these large systems, like whether it be cloud, Databricks, Snowflake. So how are you guys tackling this at a high level?

Mary Moore-Simmons (she/her) (37:31)
Yeah, so one thing I would like to mention is that you know that you have a good business if you have other businesses that are just built around your business. So that's like a pretty nice thing for the Snowflakes and the Databricks. And we're going to move into BigQuery and Redshift as well in the future. So it's it's good news for these people. It's like your product is good enough that there's entire products about your product.

Michael Berk (37:48)
Nice.

Mary Moore-Simmons (she/her) (37:54)
⁓ But yeah, I think that you are correct. And I think this is true. We are just getting into Databricks in the last month or so. So I have more experience with Snowflake, but ⁓ on the Snowflake side, you're right. Like they are not incentivized to reduce their own revenue. ⁓ They will put out new products that are more performant, ⁓ perform better, but they cost more.

⁓ So they're like incentivized to improve performance, but they're not really incentivized to reduce their own revenue. ⁓ So yeah, in terms of how we're doing this, you mean technically or just, is that what you're asking about? Yeah. Yeah. mean, the way that we do this is ⁓ it's less about what we focused on so far has been historically less about changing the actual workloads that customers are creating.

Michael Berk (38:32)
Yeah, probably.

Mary Moore-Simmons (she/her) (38:46)
although we are working on a product to automatically rewrite queries, but that's in like super alpha. ⁓ Most of what we've been focused on is given your workload, assuming it doesn't, not assuming it doesn't change, it changes all the time, but like given your workload, we're not gonna try to change your workload. We're just going to try to optimize around it. ⁓ So we train machine learning models on a per warehouse basis because we found that

⁓ warehouses have their own unique signature of usage. ⁓ And it automatically optimizes the size of first snowflake, it's the size of the warehouse, it's the auto-suspend value for the warehouse. We also suspend warehouses directly, which is slightly different than auto-suspend. ⁓ I'm happy to go into it, but we just train machine learning models that look at the workloads that are happening on the warehouse and say, okay, this can be downsized at this time.

⁓ When we see this load pattern happening, we know that the workload is going to go down after that, and we can downsize the warehouse. ⁓ There's also situations where ⁓ customers don't really care if their queries take two minutes longer, and they'd rather save the money. So that's the other thing is what we're taking input from customers through our tool to say, I don't really care as much if this query takes longer to run, just save me money on it.

Whereas other warehouses or other workloads, they care a lot more about performance and so we can't optimize this aggressively.

Michael Berk (40:16)
That makes sense. Yeah, a big portion of the field engineering job that I do, or at least used to, and now it's more GEN.AI, but ⁓ you basically are given an SLA for a pipeline and then you minimize the costs and it's that simple. And so if customers do provide that Pareto frontier of SLA of latency, then you can do, you have a lot of freedom to basically minimize costs and even that sometimes that involves re-architecting. Why are you guys not modifying the actual code?

Mary Moore-Simmons (she/her) (40:42)
The, it is.

Michael Berk (40:45)
because it's hard, potentially.

Mary Moore-Simmons (she/her) (40:46)
Yeah,

it's easier to do what we're doing. in the methodology of like agile-ness, ⁓ you want to do the easiest thing first that provides the biggest value to customers with the least amount of effort from your part. So it's definitely more work. It's also, ⁓ it's a harder problem to solve, like rewriting people's code for them. And customers are less likely to want you in their code like that.

⁓ So it's an easier approach to a customer to say, we'll just downsize your warehouse sometimes. ⁓ And we don't have to look in your code. We don't have to see any of your data inside your warehouses. We're just going to downsize it sometimes, and you're going to save money. ⁓ That's a much easier sell to customers. Then we're going to rewrite your code for you, and then some sad engineer later is going to have to figure out how it works.

That's ⁓ like, I'm ⁓ over dramatize that, but that's what the difference is. It's just a lot easier to sell for customers for how much we can muck about in their systems.

Ben (41:47)
This actually reminds me of the like paid engagement I did in the field at Databricks. It was working with an extremely large company that I'm not going to name their name. ⁓ And one of their sub teams, wasn't an engineering team. The engineering team actually hated the fact that the analytics team did this. They hired a contractor, like a contracting company that offered a service. And what they proposed or what they promised was

We'll give you UI based ETL that you can like drag lines to boxes. We'll analyze your data in Databricks and then we'll, we'll write the most efficient code. And they brought me in because it A wasn't working and they wanted it to work. And then B they're like, well, we need help with some of the implementation stuff. So you're a Databricks person. You should know this. I still remember opening up.

this, like they sent me a link to the GitHub repo and I opened it up and I was like, this, isn't Scala or Python or even SQL. Why are you writing AQE queries at the, like the lower level spark level? And like, do you, and I actually sat on a call with them and was like, do you actually think that you're better at this than our entire like core spark team at Databricks who invented this technology?

And has written, they've spent 11 years working on AQE. This is all they do. And they're like, we think we're better. I'm like, can I see a benchmark? Because what I just ran on your test dataset, if I just enable AQE where you have disabled it, it runs like 15,000 % faster than what you have, the abomination that you've created. They're like, well, we're still optimizing. Like, good luck.

⁓ Why would you go to this path first? Why would you promise this if you've never even done it? This is very challenging to get right. And then of course we release a new runtime patch release midway through the contract that I'm working on where all of their, like we changed things in AQE on the data work side. So all of their code just wouldn't run. It was an exception factory. And they're like, you need to help us make this pass. like, no, I don't.

Michael Berk (44:00)
you

Ben (44:01)
I

need to leave. Good luck.

Mary Moore-Simmons (she/her) (44:03)
This is exactly what people are talking about when they say you should be building in your core competency ⁓ or your differentiator. You should not be building in things that aren't your differentiator. This is an extreme example of why are you doing this? Shouldn't you be building your product or whatever?

Ben (44:19)
Exactly.

Yeah, just build your UI, like cool interface that allows for this to work. Like there's a product there, but they left that half baked and we're just going into the weeds of like, we need to make this performant. Don't.

Michael Berk (44:34)
you

Mary Moore-Simmons (she/her) (44:35)
I had a CEO once that was trying to cut costs and he was like, and we were using Okta for, ⁓ for SSO and off. And he was like, well, can you just build your own off and SSO? Well, was like, technically I totally could. And like, honestly, I would have fun doing that cause I love security, but that's a waste of your money, sir. Like I would need X number of people like,

Ben (44:46)
Technically, yes. ⁓

Yeah.

yeah.

Mary Moore-Simmons (she/her) (45:02)
And then my back of the envelope calculation is fully loaded. And this is probably on the low side. An engineer costs $200,000 a year if you include, it's probably more than that actually, if you include benefits and things. But it's an easy back of the envelope calculation. That means five engineers is a million dollars a year. And so I'm like, cool, let me tell you how much Octa is gonna cost. And let me tell you how much the teams of engineers I'm gonna need are gonna cost. And you tell me if you want me to build it myself.

Ben (45:28)
Yeah, exactly. I could, that basically sums up a lot of what the, like the field that Databricks was. Like you go in and talk to a customer. They're like, can you look at our code and see how, like how we can make it better? And sometimes you would see stuff that was very clean, very straightforward. And it's like, this is a pleasure to work with these people because they just want to make what they like their core business better. And they just need an expert to come in and help them.

And I would love those engagements. But for every one of those, have three that are like, you do know that DataFrame APIs exist, right? They've been around for like six years. Like, why are you writing Scala RDD code, like just MapReduce code in Databricks in 2019? Like, just why? Do you think that you can do this better than we can with all the work that we've done?

They're like, well, we get some good optimizations from this. I'm like, sorry, no you don't. Like there's no possible way. And plus you have no unit tests for any of this code. There's a hundred thousand lines of code in here. How do you even know that this is correct? And what are you going to do when we deprecate this? well, ⁓ that's what you're here for. Okay.

Michael Berk (46:46)
This is where I leave part two.

Ben (46:48)
Yeah.

Mary Moore-Simmons (she/her) (46:49)
When you said, ⁓ my gosh, when you said they thought they could do it better, I immediately wanted to like create a competition. Like it was like, let's do a head to head. Like we're gonna have your engineers and my engineers running and get in a room and they're gonna fight, well not fight, fight, but like fight with code and see what happens. I'd watch that.

Michael Berk (47:06)
Maybe.

Ben (47:08)
Yeah. And a lot of times I

would, I would explain to people cause they'd be like, Oh, Databricks is so smart with what they do. And like, we stay in our lane about what we're working on. Could we go and build a data center and write our own version of object store and like host your data on our like physical hardware? Of course we could. We would probably need to hire about 50 people to do it on the software side and probably 200 people on the hardware side.

Are we going to do that? No, like that's not our wheelhouse. We don't want to be in that business. And even if we think erroneously that we can do it better than AWS or Azure, we're certainly not going to spend time doing that. And a lot of times that resonated with those engineering leadership people that like, you got a point here. Let's simplify. Like, yes, let's, go the simplest route.

Mary Moore-Simmons (she/her) (47:59)
Also, ⁓ people who use Databricks, they get charged for the AWS usage underneath, right? Or if they're running Databricks. Yeah. So it's like, it's not even like a big financial problem for Databricks. It's not like there's a financial problem they need to solve. Yeah. Yeah. Yeah. I had a company at Sendgrid when I, when I worked at Sendgrid, we, actually, and they still do run their own hardware for some of their stuff. And it's because it's email infrastructure. So it's basically like infrastructure as a service.

Ben (48:13)
pass through.

Mary Moore-Simmons (she/her) (48:27)
And so like for them, it also helped that they were founded in 2009 when like those, these clouds weren't things. And so they built that competency and they run their own hardware for their mail pipelines still, because it's just so much cheaper than doing it in the cloud. But that's because they're literally providing infrastructure and they're not passing on the cost. For other companies, it's just like totally not necessary. And I would never now today, I would never start a startup on on-prem. So yeah.

Ben (48:54)
No,

it's so astronomically expensive to maintain hardware. It's like, just why? Just pay a cloud provider. They're super secure. They're super performant. They're easy. Everybody knows it. And the other aspect is like, you can get people in your roles. Like you can staff your engine organization because everybody knows cloud. You're not going to get a new recent college grad or somebody coming out of a PhD program who's like an expert on

like VMware configuration running on on-prem hardware, people are be like, do people still do that? Where's my S3 pocket?

Mary Moore-Simmons (she/her) (49:32)
amazing.

Michael Berk (49:33)
So Mary, I have one final question for you. As an engineering leader, I'm sure you know a lot about the optimization space. I'm curious, what's sort of on the forefront both for Kibo and this industry?

Mary Moore-Simmons (she/her) (49:45)
When you say optimization, that's a pretty broad term.

Michael Berk (49:47)
Good point. I

mean, like cost and performance optimization, like specifically in the niche that Kibo has of sort of attaching to larger, potentially slower and bigger organizations that aren't as efficient and then optimizing around that infrastructure. Like what are the cool things that are happening?

Mary Moore-Simmons (she/her) (50:04)
Yeah, think ⁓ cool things that are happening are, yeah, I think, I forgot who asked this before, which one of you asked, but you asked like, do you optimize their actual code? And the answer was like, it's a harder thing to do. But I do think that that is actually where like the next logical step, which is why what we're working on now is automated optimization for your warehouses, because that's the easiest, fastest thing with the most benefit.

But then you start to get into, how do we go even further? And it does. The next logical step, like I mentioned, we have this alpha product we're working on that rewrites queries for you. And so the next logical step is we actually optimize your code. the problem with that is the reason why it's such a hard problem to solve is that our AI models for writing code are not

great yet. Like they're definitely getting there, but like, you know, the cursors of the world and things like that, like generating code. ⁓ It's like, you know, it works and it's like as good as the engineer who's using it, but it could be a lot better. The way I see AI today, I am like reminded of when I ⁓ see movies about like IBM computers that took up entire rooms and had like hundred page manuals. Like

That is what AI is today. ⁓ That's the version. It's such a little baby. ⁓ And so it's going to get better, but that's the hard problem, is getting into actually rewriting actual code to make it more efficient, I think is the forefront of ⁓ the next cool thing that's going to happen. But we have to get AI models. They just have to continue to improve to make that not as much work ⁓ as it would be today.

So I think that's an exciting thing. I think yeah, I think AI is anything that like an engineer gets annoyed doing probably can be done by AI. ⁓ Or a good engineer. Some engineers don't like the things, the parts of their job that I would consider to be like, they're like, you're doing, you're holding five matrices in your head seems like a thing that an engineer should be doing. but ⁓

But anything that's annoying, like writing tests or automated tests or things like that, anything that's annoying and feels repetitive, should be able to, AI should make that go away. And so I think code optimization seems like something that actually is kind of fun for some people, but could be something that goes away or is less arduous with AI.

Ben (52:40)
Yeah, I 100 % agree. Particularly if you're talking about like analytics queries, ⁓ we use like, we just did an episode, I think last week on cloud code usage, like the best best practices for that. And it's something that across the board, all of the engineers at Databricks are now using every day. ⁓ Some of the things it's like, yeah, I need to create like ⁓ another SDK that's based on this language that I've already written it in.

I don't really, I'm not an expert in that language, but Cloud Code is good enough and it can run its own tests and write its own tests and like iterate. So it's kind of cool. But yeah, like we've, I've done some playing around with stuff like I need to pull this data and write this like super ad hoc, obscure query against our logs that we have for like usage logs. And like,

I don't even know what table this is. I know it's in Unity catalog and I can just write basically an MCP function that allows a rest interface to the catalog and then tell it like, where's this data? It finds it in 30 seconds. I'm like, all right, can you write like an optimized query? Like here's my first pass attempt at this with my four terrible CTEs that I wrote. Can you like clean this up? And then it just...

spits out perfectly formatted, beautiful SQL code. I'm like, all right, now go run it. Use the tool that actually interfaces and runs it. And it finds out, I have an error here. I assumed that this column was labeled properly, and it's not. And it diagnoses it, rewrites the query. And within 15 minutes, I had something that solved my problem. It's not my core job to like,

Like this isn't something that's going to production. This is something for analytics purposes to answer a question that I have. And it saved me probably eight hours of work. So I'm like, thank you. I think stuff like that is definitely the perfect use case for these things, as well as everything that you said as well. I hate writing unit tests. Unless it's something that is super important for validating the functionality, or it's like,

I had this idea and I want to make sure that it really works and this is probably confusing to test so I'll write the test. But other stuff like make sure that this property is attached to this object. Like do I really want to write all those validators? Like no. AI can do that.

Michael Berk (54:58)
Yeah, well said. All right, so we're about at time. I will quickly summarize. ⁓ Lots of really cool topics today. A few things that stood out were if you want to transition into a new role, just do the thing. Ask for forgiveness, not permission. And as long as you come in with a humble and kind and self-awareness of being an annoying attitude, you should be OK, because that'll help you course correct. ⁓

When things go wrong within the organization, try to find the root cause and don't introduce red tape. That's not a solution. Often the issue is the core culture or the processes. And observability is key into this. ⁓ For project management tips, planning is super important. And especially for engineering, it's really important to know what is happening and what will happen. ⁓ And also just try to make tasks more efficient. Block the busy work that prevents engineers from doing what they do.

Some miscellaneous tips. Process creation in itself should be agile. When you are creating a MVP, customers might hate it. So just try to ship it and see what happens. And also understand base motivations of these customers. That's really important. And then finally, when choosing what to build, stay in your lane and don't try to make object store. So Mary, if people want to learn more about you, your work, where should they go?

Mary Moore-Simmons (she/her) (56:18)
Yes, if you want to learn more about Kibo specifically, can go to our website at kibo.ai. If you want to find me, I'm on LinkedIn, ⁓ Mary Moore Simmons. think I'm the only one. don't think there's, I don't know, there might be other ones. I haven't found any. ⁓ And then my GitHub handle is MMSthepizatheif if you want to find me on GitHub.

Michael Berk (56:30)
Congrats. ⁓

Ben (56:38)
That's a good one.

Excellent.

Mary Moore-Simmons (she/her) (56:40)
I am a pizza thief, so it's fair.

Michael Berk (56:41)
Well, until next time it's been Michael Burke and my co-host and have a good day everyone.

Ben (56:45)
Ben Wilson.

We'll catch you next time.