Today's podcast episode is a special one! (I know, I know, I say that a lot. But I really mean it this time!!)
Today, we're diving into my favorite area of ops: no-code operations.
No-code is one of my specialties so I've been putting off this episode for a while because I wanted to make it a really good one.
Luckily, the best no-coder I know finally agreed to come on the show after much cajoling. And, since he lives right here in Mexico City, we recorded this episode live and in person... sitting on the floor of my closet, talking into the same mic. 😆
I'm super enthusiastic about no-code and the possibilities it opens up for operations teams of all sizes so I was pumped to nerd out with another expert in the space.
If you've been thinking about how to do more with less, how to get around a lack of engineering bandwidth, or just better manage the no-code processes you've already built, then this is the episode for you!
About Our Guest
Luis has spent his career scaling early-stage startups so he's used to being an early employee, or the first hire in a new market.
This has made him an expert at using no-code tools to not only help the company grow faster, but to create a better experience for customers and team members alike.
About this Episode
In this episode, we chat about:
- What no-code operations even is!
- How to get started with some of our favorite no-code tools 🛠️
- Why Luis prefers the term "platform operations" for his own role
- How ops pros can use no-code tools to accelerate growth and validate products without an engineering team
- Luis' strategy for documenting all the no-code processes that he uses at BACH
- Why I was "just a number" when we first met in Chile—and just how uncomfortable my closet floor is 🙃
You can listen to Opsy on your favorite podcast platform, including:
Stay in Touch
- Tools mentioned in this episode: Airtable, MiniExtensions, Softr, Stackr, Webflow, and Zapier
- The History of Knolling
Welcome to Opsy, a podcast for people doing opsy work in tech. I'm your host, Caro Griffin. Every month I dig into what Opsy work really is by talking to an operations pro who has something really cool to teach us—in a traditional part of ops like HR or finance, or a newer specialty like no-code ops or marketing ops. Thanks for listening!
Welcome to a special episode of the Opsy podcast! Today, we're diving into my favorite area of operations, which is obviously saying a lot, and that's no-code ops.
No-code is one of my specialties so I've been putting off this episode for a while because the bar is kinda high. I wanted to do it justice, you know?
Luckily, the best no coder I know finally agreed to come on the show after much cajoling and harassment on my part. [Laughs]
His name is Luis Vera and he's spent his whole career in operations. Currently, he leads Platform Ops—and we'll talk about what exactly that is—at a startup called Bach. Bach is in the event and travel tech space and they help users plan awesome bachelorette parties. Talk about an interesting niche!
And another special thing about this episode is that Luis is actually a close friend who lives right here in Mexico City so we're going to record this episode in real life. Like while sitting next to each other on the floor of my closet, sharing a microphone, instead of chatting via Zoom halfway around the world from each other, which I think is pretty cool. So I know we're going to have a great chat!
And if you've been thinking about how to do more with less at work, how to get around a lack of engineering bandwidth for your team’s projects, or just want to get better at the no-code tools you’re already using, then this is the episode for you.
Welcome! Thanks for coming on and spending your Saturday morning with me.
Thank you for having me. It's good to be here.
So do you wanna tell folks how we met or do you want me to?
What if you tell them how we met and I'll tell them what we've done together since?
[Laughs] I don't know how that's gonna end well for me, but okay.
Everyone listening, Luis is actually a close friend of mine here in Mexico City, but we initially met in his home country of Chile. I did a work and travel program that took me to Santiago for a month and he worked for that company, Remote Year, as an Ops Manager.
You were kind of the guy that got our apartments and co-working and made sure we had functioning internet for all of our Zoom calls and stuff, but we weren't actually really friends then... In fact, I was just telling you the other day that I think I only remember having like two conversations with you that whole month.
Back then, you were basically a number, a customer. [Caro laughs] One of thousands.
Well, okay, just for that, I'm gonna tell everyone my main memory of our month together in Santiago was at like our goodbye party, where Luis was doing some kind of fasting but was like also drinking like two Old Fashioneds and was like, “I can't have this conversation. I haven't eaten today. This is my second Old Fashioned.” And that's like my main memory of you until like Covid hit two years later. Fast forward, I think we were Instagram friends and you were like, “I'm in Mexico City, let's hang out.” … And then I never got rid of you.
And since then we both moved to Mexico City. We've broken the law and bribed the cops together.
Well, Okay. That was like… I mean, yes. Okay. That's technically accurate. No other details will be provided. [Both laugh]
… and got matching shoes together.
This is really taking a turn. Maybe we should keep it moving guys.
I feel like our relationship is a lot more wholesome than you're making it out to be with these highlights… Our matching shoes are very cool though. We have some really cool Nikes, although we have different feelings about how to maintain those Nikes…
And that's the one successful thing out of our project list that we have together.
Yeah. Luis is one of those guys. I feel like everyone has one of those friends in their lives who's like a “we” guy. Like, “We should buy a car. We should open a coworking space. We should go to Japan…”
What's the latest one in that list?
There was something last night that you were saying that we should… Oh, we should open a restaurant.
It's a club. Don't tell them [the details]. I don't want anyone stealing the idea.
I think that was the whole idea. I don't think you provided me with any other details about this project that we're embarking on together.
Details are in this spreadsheet.
Okay, well, um, moving along since, you know, we're here to talk about operations.
Despite the fact that, uh, you know, I give you a hard time and our whole friendship is based on us giving each other a hard time… You are probably the best no-coder I know. So I'm excited to have you on the podcast to talk more about this because this is an area of ops that as soon as I started the podcast, I knew I'd wanna do an episode on this. But also… I love no code, right? And so, if I was gonna have another guest to talk about no-code, the bar was high... And yet, here you are, sitting on the floor of my closet with me recording this episode.
Thank you. I know how hard it is for you to give compliments so that means a lot.
Only to you.
Okay, let's get to why we're really here. Let's talk about ops. So why don't we start at the beginning. How would you define or explain no-code to someone?
Good question. To keep it simple, I say no-code tools are a part of your systems and processes that you can build without the need of a software developer. And most likely these days, we’ll start with tools that allow you to connect other tools and systems… or to control access to parts of your system to certain, like, end users or colleagues, et cetera, et cetera.
Yeah, I mean that makes sense. I feel like that was my definite introduction to no code was like using Zapier for something very simple, like if this, then that, right? Like if someone buys here, send me an email there or take this other action there. But it's gotten super complicated since then. And I know you were kind of the king of the most complicated no-code processes that even I can't follow sometimes, but you're so excited about them. [Laughs]
I wouldn't say they're necessarily more complicated, but, yeah, if you take the time you can get really elaborate with what you can do.
Yeah. So your role is pretty focused on no-code operations in a way that like a lot of us other ops people are just kind of dabbling in it, it's like kind of a… “means to an end” sounds kind of negative, like we don't enjoy it. Because I think, in theory, a lot of us do enjoy it, but it's the way that we get something done that's like a bigger part of our role. But you're pretty focused on no-code operations.
So, what is your role? What is the role of someone like you at a startup? What does your day-to-day look like?
As far as the role, I'd say it depends on the size of your company and the stage of the company you're in. In my case, I joined like a seed stage company of about 10, 12 people. We were at the stage where you're like figuring out you're moving pieces and the processes and systems to connect them within the company. So, basically, my role involves building that, iterating, maintaining those, and actually figuring them out as we go and, and as we grow. Especially… like, I guess most of us are in startups where things change quickly. So, you need to be iterating and adapting whatever you're building pretty much day to day.
I think something I struggle with a lot, especially as I've gotten into like more general… like, now I'm like a General Manager, I have a bunch of different responsibilities and so it's hard for me to keep an eye on things where, team members are doing something super manually or like not in an efficient way. I know I can automate it or I know I can turn it into a no-code process, but I'm not as involved, right? Like I used to work closer to them or I could be like, “Oh wait, how are you doing that? Let me help you fix that.”
How do you decide what you tackle? Like do people say, “Hey, Luis should help with that,” or do you kind of discover problems and say, “Hey, I can help with that.”? Or is that like a little bit of both?
I'd say it's a mix of both. One part of it is just having a good communications channel with your team where they can just like Slack you and say, “Hey, I need help doing this.” And usually they're asking for help on how to do it manually. And that's what sparks the idea of like, “Hey, we shouldn't be doing this manually in the first place.” And kind of like, okay. That's how a little project starts [and] actually ends up becoming something bigger.
And the other part is just like your own initiative, your understanding of how your processes work within the company and what you know is gonna happen. Especially at this stage of, like, where you're growing and you have an idea of like, [which] of your systems are gonna stay working when you have like five times, 10 times the users, right?
That's always something that's in your mind like, “Okay, we have a system that puts things in a spreadsheet because we have like a thousand things here. When we have like a hundred thousand of them, this is gonna break.” You're kind of always preparing for that and seeing [how] you can optimize and prepare systems for the next stage of your growth.
So I'd say it's a mix of both—being able to understand well what your colleagues are doing… Sometimes I join [team] meetings for the last 15, 20 minutes to see like, “Hey, how is everything working? Like, what do you guys need?” Or, “How [could] this system be better?” Because sometimes people wouldn't ask unless there's something like a major issue. But they're not realizing what they're missing or what we could be doing better if you just put some time on it.
Yeah. I think that's like the biggest thing I struggle with is trying to get my team members to have a basic understanding of how some no-code tools work. Especially the ones that we're already using and that I'm really familiar and efficient with… so that they have just like even a spark of, “Oh, I should ask Caro about this because there's probably a better way to do this.” Right?
So, obviously you're getting all these Slack messages and, you know, popping into team meetings and basically giving yourself more to-dos that way, and then trying to stay a step ahead by being like, “Yeah, this process is painful now. It's gonna be even more painful six months from now when we have three times as many users or whatever.”
What does that do for your day-to-day? Like what does your day-today look like?
I say at this stage, um, and, for context, I work at a company that's in it series A and we've had like maybe a year and a half of track record of sales and users. So, we started a lot of our processes… like a lot of things are in the “v1” of what we needed at the moment.
We have a good [bit of] seasonality in our business, so we're kind of now in the winter, maybe like a little bit slower time. We're preparing for what next year slash next summer is gonna be—maybe that involves five times, 10 times our users.
So, particularly these days, I'm working on improving, rebuilding and iterating on systems to make sure that these processes and tools scale with our volume and they don't break basically when you have a higher load.
Yeah, that makes sense. Your title is Platform Operations, but I know there are a lot of different titles kind of floating around for no-code roles. It feels like, as an industry, we haven't quite figured out naming conventions yet. So, would you say that it's almost exclusively a no-code operations role or do you have other things in your job description? I actually don’t know.
[Laughs] It's definitely not just no-code. I think like most of us operations folk work with all the teams in the company and do a little bit of everything. And particularly, [with] my background, it's always been in operations. Maybe before it was more like in real life and more involved with logistics and, particularly in the industries of what my company works in, related to travel and activities and experience and hospitality and things like that. So, because I was on those sides of the table before and, and in those roles and seats, I have a good understanding of how things work for our vendors, our users, our partners and I can also be helpful there. And, personally, I'd say I’m a guy that gets bored more quickly, like doing the same thing. So—
[Laughs] Understatement of the year, folks.
[Laughs] I'd say I find myself in like a new project or, like, volunteering to organize a company retreat because, honestly, like figuring out those is something I enjoy.
I love that too. I just got approval to have a team retreat for Tech Ladies here in Mexico City and I'm like, it's definitely not anywhere in the top 10 priority list, but it's like the project that I turn to when I, like, want something fun to work on for an hour. Like, are we gonna go to Lucha Libre? Are we gonna go on a taco food tour?
I'm telling you, I could put together a kick-ass tour for those ladies.
If you think that you could do a better taco tour than me, we're gonna have to talk about this later because…
You know I’d do a better job…
Absolutely not. Back to the topic on the table here. [It’s interesting to hear you] talking about this because I feel like you're really drawing the line between the role I knew you you had at Remote Year in your current role, which I realize we haven't defined at all or like talked about, you talked around it. So why don't you tell us about your company and, and kind of what it does?
Cool. So I work at a company called Bach. We are, uh, group travel planning app dedicated to the niche market of bachelorette parties and the app itself has like the standard travel planning features, like a schedule, expenses and things like that. And we also have a marketplace—so picture something like Airbnb experiences, but [right now] in a handful of US cities with activities and experience for that group of users.
Yeah. And I feel like we have to give a little more color here because it's some fun color we're talking about. Like you can order like dick cookies and…
You can also have like yoga classes and candle making things… Yeah, there's some like dick-shaped cakes in there, but that's like….
That's my favorite though—like working at a cafe [with you] and, especially when you were helping with some customer support more in the early stages. You would have just like the most random things on your computer screen. [Laughs] Like, I’d get up to go to the bathroom and be like, “What are you doing?” But yes, it is a small percentage of the users. I get it. I hear you.
And going back to the titles… I agree. There's no clear definitions of these titles in the no-code space or like this part of the operations [space]. And, actually, we went for platform operations… And you mentioned that we met during my Remote Year days. Back then, we had an understanding of what a platform is.
For example, our platform in Chile was like… Let's say we had an office and housing and activities and different things like that. We referred to the platform about how all of those will interact with each other. So, yeah, maybe in one city you had like great apartments or like a great coworking space in Spain, but they were in the wrong neighborhood or between them you had to like climb a hill to get to the office.
Maybe those parts together, like by themselves, they were great. They [had] like a great office and a great apartment, but between them they didn't talk to each other so well. That concept of a platform is kind of what stayed with me.
At Bach, we don't refer just to ‘platform’ as [just] our app for example or like, or the backend for our partners or vendors, but how all of those interact with each other. And that's kind of like what, at this stage, or in previous stages, we were doing and slash are doing with no-code. [We] have that more holistic view of what a platform is.
That’s really interesting and that makes a lot of sense. I just remember being like… What was it you called me? A number on a spreadsheet? [Laughs]
Yeah but, when I was in, for example, Japan… like we had this really awesome like traditional Japanese house, but it was a 35 minute walk from the coworking space and we all finished work at like 3 or 4:00 AM. That was not a good platform.
Exactly. It’s exactly that.
Yeah, you know, like me riding a bike when I'm not comfortable on a bike… like down a highway.
I can ride a bike. I just said I'm not comfortable on a bike. And I definitely wasn't then—I hadn't ridden a bike in like a decade and I suddenly was like thrust into a city without Uber, a city where like I didn't wanna take a 35 minute walk at 4:00 AM but I also didn't wanna like ride a bike down like an interstate. [Laughs] And that was the platform, you know.
I just, I like am picturing that while I think about the experience that you—or the “platform” that you set up for us in Chile, which…
That was a good one.
It was pretty good. It was pretty good. I'll give you that.
I mean yeah, you were in a mansion.
Yes, we did call it the mansion. [Laughs]
Um, so, okay, well that's super interesting and I think also just like, to take it back to kind of the title platform operations, I guess, I'll just like say that… this has also made me think differently about having the title like “no-code operations manager” or something.
I'm usually the person that's like, “Let's just say it what it is, right?” Like, let's use plain language. If you're doing no-code, let's call it no-code, but I think what you're talking about is so important that you can't just build no-code processes in a silo. They have to work together. You have to think about the whole experience. And so I think you've turned my mind around where I'm like… Yeah, no, it really should be platform operations when you're approaching it kind of this holistic [way]...
Especially in an early stage startup where sometimes no-code is gonna be the answer, but sometimes the SaaS tool is gonna be the answer. And so I guess my takeaway here is that really the only people who should be called no code operations managers or whatever, are probably at like bigger companies where they really, solely, are only doing no-code.
That's what I'm thinking. At this stage, like, in our case, I'm pretty much a one-man band. And it makes sense that yeah, I'm the one that is kind of thinking of these systems and prototyping them and actually building them and testing them and then really talking with the users—meaning our colleagues—and, basically, building on top of them.
Maybe as we grow, once we are like a team of three doing this, you're just gonna have someone that is like, yeah, no-code operations manager or something like that. And [then] you have maybe a guy figuring it out slightly higher and someone that maybe makes a connection with our dev team. It's maybe a thing of the scale of the organization.
Yeah. I mean I'm glad we had this conversation. I feel like we've just like figured it out for the whole industry. Like… done, guys! You don't have to do it. We’re here to tell you it should be platform ops early in the game and no-code ops later in the game. Done. Like brush our hands off, move on. [Both laugh]
So, next topic, I'd love to talk a little bit more about no-code tools, specifically. I think a lot of people think about no-code as just automating things with Zapier, but you've built entire processes and products with some of these tools, as well as I have. So what are some of your favorite ways to use no code tools and like how do you use them at Bach?
I say, on a day-to-day… we use tools to connect different moving pieces we have in our business. Like, maybe the support call to action buttons in our app to our support app, or our bookings database to a dashboard that allows us to see what's happening on a given day. Things like your usual suspects, [the things] you'll expect.
On the bigger picture, I'd say our main use of no-code is to somehow show us the path of what we eventually need to build in house. I mean, in our case, we're a proper tech company. We have software developers but, of course, resources are limited. Building software takes time. It's slow. Especially at this stage—maybe I'm abusing this phrase a little bit lately—but you don’t know what you don’t know.
When we say we need an interface or a dashboard to show us a certain thing, we don't really know yet what that thing looks like. We probably have an idea that allowed us to build like a prototype slash [version one] and, later, we're gonna iterate and build on top of that [version one]. Once we have like our colleagues or users using it for a few months, we're gonna be making changes but, at the end of that process, we're gonna end up with something that will be really close to the final version of how that thing looks like.
And then you can involve your dev team and say, “Hey, this thing that we have here in Airtable or whatever it is, we need you to build this in house.” So, there's no guessing of them saying, “Okay, so what features do you need or how do you wanna store this?”
Because we already went through all those iterations with no-code and it was fast and cheap to do it in that space versus figuring out all of those in our engineering space and having them like to create a ticket and groom that code and then like release it in dev… and then like it's so much faster to test that and build and prototype in no code. At the end of the day, it shows you the picture of what you end up building in house.
Yeah, I mean that's my favorite way to use no-code tools. And you know, recently I won a Zapier no-code contest for work on a project that really was built for the reasons you're talking about. Like, we had no full-time engineering talent at the time at Tech Ladies. We were two or three people, most of us not full-time. And it was building this candidate database that like our partners had been asking for something, but like… you know how it is, users are rarely the best person to ask like, what you should build, right? Like, sometimes people say they want something and it's like, that's not actually what you want. You want to solve this other problem. And so, you know, it would've cost us tens of thousands of dollars to have engineers build that. But I was able to build something that was like, frankly, really shitty. [Laughs]
[At first] it was an Airtable embedded in a Webflow page, but we were able to become a seven-figure business with that. And now we've, you know, built a way more complex application with Softr and stuff. But ,like, you know, this week I was able to like really quickly make some tweaks… because the direction of what our partners wanted… like I could just go into Softr and Airtable and just like change some columns around and it took me, you know, half an hour versus like… If I had to submit a ticket to an engineer? I don't know if it would ever get done.
It's too slow. I love you guys, but the process there, it's too slow.
Yeah. And it's just like, they got a lot of stuff going on and you gotta prioritize accordingly and, like, honestly, it's like the little fixes that I made this week… they never would've been high enough priority to pay an engineer to do it.
So, we talked a lot about the benefits of using no-code tools. Obviously, we're both big fans and you know, do it a lot. But like, there's some real cons that I think we should talk about too.
What are the downsides of you being this one-man band who's like building out these processes for your team?
I'd say that maybe the fact that it's so fast and easy to build and make changes here…. I mean, you're like the product manager, you are the developer, you are the QA. It might put a lot of power in you or, like, autonomy, just because you think something is a good idea. You can just be like, “Oh yeah, I can knock this out in like 10 minutes and just do it.” And maybe [you don’t] put the necessary thought in like, “Okay, what's the motivation again?” [Laughs]
Yeah. It's like, is what I'm building really tying into business priorities? Is this the highest priority thing that I could build? And, also, I think you're really speaking to like a lot of technical debt, right? Like engineers have all this tech debt when they build features that no one uses and like that's a very real thing for no-code stuff too, right? Like you build things because it's quick to build and then you're like, “Oh crap, I gotta maintain that.” Or like it's falling apart.
I'd say just because something seems like it's easy to do and it's fast… It doesn't mean you should do it right away. It’s something where we're doing now. It's having these weekly reviews of what our no-code slash my priorities are and what I'm working on. And how does that relate to the work that the engineers have coming in the next month?
And sometimes it’s the other way around. It's like your dev team [wanting] to switch one of your tools or systems to the in-house, the real backend of your app. And sometimes, because you work by yourself, they are not as familiar of how that piece interacts with everything. So it might be the case that, if they move something to to the back end—and I mean the back end by what runs in our codebase. Maybe they don't know that if they move [something] that you lose a piece, or a trigger or something that you need [from a no-code tool] because another dozen things happen from that. Having those checks, those reviews, like constantly with your team, especially as you're growing or you're just entering that stage of growth, it's critical.
This brings up a really good point and a follow-up question I have around this. How do you document this? Especially as a one-man team. How do you document all the zaps and triggers and tools and maintain them?
I feel like I'm constantly—because I'm the one that set them up—I'm the person that people ping and they're like, “This Zap is broken!” And I'm like, “No, it's not. That's just not how it was intended to be used. This is an edge case. It's triggering to me when you say it's broken because it's not broken.” [Laughs]
But then it's like, that becomes a big part of my day, right? And, I know to some degree, that is your day. That's your job. But, like, how do you maintain all of that? Not that I expect you to have this perfect solution! But like what's your work in progress?
Not well enough, but it's definitely something I’m literally improving at this moment. It’s documenting at least some of your critical processes that run on no-code. Especially as your team grows, the rest of the people are not as involved as they used to be on some of this stuff.
For example, we have a mobile app, right? Sometimes actions that happen in the app, like we get a new booking or someone did this or that or like, a partner created a new experience that’s listed in the app… something happens and we have a trigger from that to the no-code side of our systems. Just having a quick table of saying like, “From this trigger, all of these things happen.” From this other trigger, all of these things happen and, and it's connected to these other 3, 4, 5 tools.
It's like a quick reference thing to the engineering team to say, “Okay, actually, if we move this or, if we do like another change and it has some repercussions and it changes this trigger in some fashion, that could affect all these other processes that sometimes are critical for day-to-day use. So you can start from something really basic, like a table and a list of the triggers you use, and what happens with each of them. Make it something that is really easy for everyone to read, especially if they're not on the technical side. Go from there and maybe you'll get more elaborate later, but just start from the basics.
Yeah, because I think, you know, you're building really critical business processes in these tools and these things live in your head, right? So, if you were to, I don't know, get hit by a bus tomorrow, what happens to Bach, right?
That happens to every team. I mean, when I joined the company, a lot of the information that needed to be documented in a database was only in the head of a few of my colleagues and it took us a long time. We're a business that deals with hundreds of different partners that list in the app. Some of their information—like who's the guy in charge, what's their email? Like, how do they operate?—If that was only in the heads of, let's say our sales or our business development people. No-code was a really good solution to store all of that.
We started with everything in an Airtable database and built from there. And, because we had all of that information there, it made it like a no-brainer to be like, “Okay, if we already have all of this stuff here, if we need to [create] like a quick portal for our users, then it makes sense that it feeds directly from here. Instead of trying to figure out a new way, or a different way to do it…
Yeah. I can't believe we're this far into this conversation without having like… I think we haven't even really named any no-code tools we like. What are your favorite no-code tools or the ones you use most often?
If you don’t say MiniExtensions, you’re lying.
[Laughs] I told you about that one.
I know you did and now I use it all the time. But sorry, go ahead and answer the question.
No, like my core tools… I would say Airtable. It’s really our main thing where we store our data actually. I think that's like the standard for most folks these days.
Yeah. That's what we use at Tech Ladies to power so many things.
And from there is like maybe like a couple tools that interact with Airtable—like something to build, a customer portal like Stackr, or, maybe something like MiniExtensions because you want better functionality when building like a form or like a public URL for some of your records and things like that.
I think the critical step is to pick the base of what you're using, something that makes sense for your business, for your stage. Maybe you can get by with like a spreadsheet, you know, if you're like a bootstrapped business or like a side project with just a few hundred thousand users—or records, however you wanna call them. And then maybe use something like Airtable at a later stage… because it’s also maybe an issue when you're starting...
But I'd say the main thing is to pick up the right main tool where you store your stuff and then you can build with add-ons and extensions from there.
Yeah. I mean, I think both of us have picked Airtable in a lot of ways for that reason, right? It's a great base for our use cases because you can extend it with Zapier and MiniExtensions… I’ll link to all of these in the show notes… and you can build that front end with Softr, Stacker. Like it's very… expandable, I guess, with other tools, like it communicates well with other stuff even though it has its flaws, for sure.
And I'd say another component there is thinking about your user. For example, in my case, the users for the stuff I build are my colleagues. A lot of them don't have, like… let's say they're in sales or account management or customer support. They don't necessarily need to have a [technical] background. They don't need to be tech-savvy, necessarily. And that's an important factor of [how and whether] people are gonna adopt these tools. Like, you cannot assume that everybody will know the basics of how “if this, then that” works. Or how filtering a view works. Sometimes you will make something that, under your eyes, is great and it works well and you release it to your people and they're not gonna find the value that you see because they don't know the basics of how the tool works. And so, just putting yourself out there and making yourself available for like, “Hey, let's do a session where I show you how all of these like buttons in their table works,” or even like a spreadsheet, like basic functions. You can’t assume that everybody knows how to use the basics of a spreadsheet or a web browser or whatever the tool is that you're using.
Yeah, that's a really good point. And something I think that gets overlooked with no-code in a team context where, like you said, it's important to remember that your end user might be your colleagues. And how do you train them on it, right? Like you have to onboard them to it, you have to make sure it works for their [level of] tech-savviness and all of that. And so you have to be a good communicator and a good onboarder… You can't just build the thing and hope that they will come and use it in the way that you want them to.
So, we've talked for a while and I feel like I could go on forever about no-code. Like, we might have to do like a whole spinoff show just for me and you to talk about no code stuff. But I wanna talk a little bit more about your ops career in general. Tell us about your career path and how you got into operations.
I'd say I've always been the guy that likes logistics, how things work, and how to make them better. I was a kid that would tear apart the toys to see what's inside, right?
And I feel like it's important context for everyone to know that, currently, in your spare bedroom, is like a bike that you're like taking apart and putting back together. [Both laugh] So, like, not a lot has changed since that little boy in Santiago was taking apart radios or whatever..
[Laughs] Not a lot has changed. The only thing that changed is the price of the toys. So, you might see in my apartment that I'm rebuilding an engine one day or whatever… I don't know.
I always joke that my dream is to like have a Tony Stark workshop. Like that's my, if I had like real fuck you money, like that's what I would have. And I feel like you've got the very approachable, realistic version of that, like with your work tables in your spare bedroom and your like constant projects.
I love my tools. It’s funny, in Bach,, like people say I'm the tools guy.
You are the tools guy.
They have no idea how many like actual tools I actually have…
Yeah. You installed the doorknob in my bathroom. When I like kept getting locked in a bathroom and Luis was like, “This is ridiculous.” And he bought a doorknob and was like, “I'm on my way to your apartment. We're fixing this.”
I took an executive decision on that one.
Yeah, and I appreciated that. I need someone to take some executive decisions sometimes…
But like, going back to… I'd say I've always been in operations, more like a real-life approach. Things like running travel logistics. All my roles have always been very early stage so I've been like employee number one or two at a couple of previous businesses or, in the case of Remote Year, that maybe was like a bigger organization with a hundred employees, but I was like the one guy they hired to like open the city in Santiago and basically figure things out. And that's that I like to do.
Sometimes, getting back to the, “I get bored easily,”... It’s because I like a lot the ‘figuring out’ stage of whatever it is we're doing. Maybe later, when it's just like down a hill and it's just coasting, I'm ready to let it go and move to the next thing. Which, at this stage, is basically what I’m able to do. I build something, I put it out there, and then move to the next project and that's what I love.
Yeah, Molly Graham has this great article, and I'll link to it in the show notes. It's about how, at early stage startups in particular, it's about building Lego towers and then giving them away. And, like, part of your role as a manager at an early stage startup is to like… people who have attachment to those Lego towers, [you have to] show them that like, “Oh, you can go build this other awesome Lego tower.” I feel like you and I have very much learned that and are like, “Please someone take this tower away from me. I'm done with it. I've already started three other towers around the corner that need my attention.”
Even when I say like… If you put it like down to Lego levels, I don't know, like…
Which you also love and we've done together
Yeah, we've done together. But remember, like, when we were doing Legos, my favorite step is literally knolling the pieces and actually like putting it together. It's like
I didn't even know what knolling was. He had to explain it to me. So maybe you should explain it for other Caros on the podcast of what knolling is.
I only say like, you guys do yourselves a favor and look for knolling on Google images..
[Laughs] Okay, we'll link to that in the show notes too. The show notes are getting pretty long on this episode. Not that I'm—
Knolling is the process or maybe the art of like—
It's definitely an art.
Yeah. Like, let's say you're going on a camping trip and you have your backpack full of gear to go on that camping trip, or hiking, or whatever it is. If you take all of your pieces out and neatly organize them on the floor or on a table to visualize everything you're bringing, that's knolling.
And, of course, with Lego pieces, you can like organize them by size and color, or whatever the criteria for what you're doing. But, the process of doing it, at least for me, is like really relaxing. And it's kind of…, for example, I also love to cook and like, in cooking, there's this whole missing class of like, before you start cooking, making sure all your ingredients are in place and ready to go. That your knife is sharpened…
This is where our paths diverge because that's the only part of cooking I like. Like, you're a really good cook and I can cook like three things. But I do like the knolling of cooking. I never thought about that as knolling.
It is knolling, yeah.
Okay. I took you down another tangent. My apologies. So, you've always been in early-stage startups. We were talking about kind of how you got into ops and why you like it.
How did you kind of switch from a role like the one you had in Santiago for Remote Year, which was so… in person? It was so, like, logistics of apartments and co-working and offices and internet and like to go to something that's so no-code heavy.
I'd say I've always had a big detail component to it. I worked in a hotel and, yeah, I was on the ground, but I was also doing like some of the stuff in the detail space and, in my previous roles where I was a very early employee,, I was also doing that. And I'd say, like, technology has always played a big part in my interests and skills. So it happened just naturally. I would say maybe it was always kind of like half and half, and now this is like my first properly fully remote role. So, now it's like a hundred percent detail [work].
So, were you using no-code tools at Remote Year or your previous roles?
Oh yeah, for sure. Yeah. They were definitely more basic… Well, that was like years and years ago, so yeah. Some of the stuff that we were using didn't exist.
Oh my god. It's like a whole new universe than it was even two years ago.
Yeah, which is exciting. Only in the last couple of years have all these tools [been] showing up and existing now. What's about to come? It's so very early stages of what we have access to, of what we're able to use.
Absolutely. And that's part of what is so exciting for people like us, who like building the Lego towers, right? Or the bicycles, or the Lego things, or I don't know, whatever the thing is.
How do you learn new tools? How do you recommend that people learn more about no-code tools? I think sometimes it's like an intimidating place to start.
I'd say in my case, [it was] by necessity. I'm not the one that is, like trying to actively check out what's out there. Because it's easy to get a bit busy, or feel like… because something new came up, and people are using it and talking about it on Twitter, you feel like, “Oh, I also need to start using this tool.”, I try not to fall into that and so it's usually that [Bach has a] problem that we're trying to solve, that I identify… Only then do I do some research even. It's just like looking for it on the internet or asking colleagues or asking friends. Sometimes it’s your colleagues that find something that are like, “Oh, maybe we could use this one in the future.” So [I have] multiple sources to learn what's out there and what's coming up. There are so many new [tools out there] that I'm cautious on not just [starting to] try things out for the sake of like trying things
Yeah, no, I love hearing about the new tools and then kind of like, poking around on the website for a minute and then I'll be like, “Okay, mentally bookmarked, or literally bookmarked, and like it's helpful to know that it exists for the times when I might actually need it later. But, I think, same here, I think the best way to learn a tool is often to try to build something with it. And like to solve a real problem, right? Like to build something that's solving something for you or your team.
Because, oftentimes, like that's how you're gonna find the limitations of a tool and whether it is good for this scenario, or that scenario, or whatever. You're not gonna run into those like same kind of limitations until you have like a real problem that you're trying to solve.
Yeah. It's those mental bookmarks, I agree with that. For example, one of our main projects I had last year was our first version of our customer portal. We did it with this tool called Stacker. It was something that a colleague find at some point. She just mentioned it and I look at it for about two minutes and I'm like, okay, this looks like too complicated for me to dig into now and I don't have the time. Something we do at Batch that I really enjoys, like every few months or so, we have these innovation days. It’s two days in like a certain week for you to work on any project that's not the stuff you normally work on.
It doesn't have to be like a business priority?
It doesn't have to be a business priority, it doesn't have to be in your area. So, if you work, uh, let's say you're an engineer, you can try something for marketing or whatever you think is a good idea. Or you can partner with a colleague to work on something together and do like a little collab on one of those. I think it was last year, I said, like, “Okay, I'm gonna use this two days to take a shot at this tool that I saw months ago and dedicate those two days to it.” And it ended up being like one of our main tools at some point.
That's like literally how I built the Candidate Database [at Tech Ladies]. But you have a way better name for it. I love that it's Innovation Day and that it's like a regular thing. I might steal that. At an old company we had what we called Field Day. It was kind of like the same concept but innovation day sounds way more inspiring.
To kinda wrap us up here, because, you know, we've been talking for a while. People might have lives that need to get back to, Luis. We can't jabber in their ear all day.
I cannot wait to get up from this floor.
You have six pillows, sir!
Okay, moving on. What advice would you give to someone who wants to do the kind of work that you would do?
That's a good question.
I mean, in some ways, I think this whole episode has been like the advice that we would give people who want this…
Oh, this is not advice, people. Please, don't hold me up for that.
I mean, just disclaimer that your mileage may vary, but I think like, again, I'm gonna say something really nice to you, which is not our dynamic, but like, you have an inspiring story in that…. You just broke in, you just taught yourself. You figured it out, you know?
I’d say, first try whatever you are trying to learn on like a real world scenario helps a lot.
It's similar to the advice that I give people learning Spanish or a second language, like [forget] the material that your teacher gave you and study with materials that are interesting to you. If you like sports, then read in Spanish about those sports. You're gonna have a better time and you're gonna make more progress if you're doing that than if you are reading whatever they just assigned to you.So, like, getting into those tools with a real project, something that might be useful for you or [for] the current company where you're working at, even if you're doing something different.
Also, part of the advice I give people, like in language learning, is to lose the fear of like fucking up.
Despite the fact that every time I speak Spanish in front of you, you laugh at me?
I might laugh at you, but that’s like I'm telling you like, “Oh, like you're Spanish now makes me proud. You've come a long way. “ [Caro laughs] Like the people that—
Considering that I spoke zero Spanish when we met? Yeah.
The people that makes the most progress are the ones that don't fear to sound stupid. It's okay to not know everything at the beginning, or ever actually. It's okay to like screw things up and just like, start again. For example, one of our main tools that we used to keep track of our bookings… We had one that we started in Google Sheets back in the day, like almost a year and a half, two years ago. We iterate on another one and [now] we're like version three of it because we've learned a lot [along] the way. We know what works, what doesn't, when it breaks, and now it's on a level that it's pretty much ready to be switched to an engineer in-house. Like, something we code.
So, know that whatever you do, it doesn't have to be permanent and you can just test the water and explore and experiment with stuff. And it's just like building with Lego. You can always like scratch it, scrap it, and—
And re-knoll all your pieces?
… And re-knoll all your pieces. And start again.
Wow. If that's not an analogy for life.
Okay, final question.What are you trying to learn this year? Like what are you trying to get better at? What should people reach out to you with If they can help?
[Laughs] Okay. Not an answer we've gotten on the Opsy podcast before, but, you know, very real.
We spend a lot of time every day in front of our computer so, lately, I've been paying more focus on things like goodness and wellbeing and training several times a week…
And then complaining to me about how you're sore for several days after? And then, as soon as you're not sore, going back and doing it all over again?
That's the beauty of it. But, yeah, if you have your tips on how to improve your posture, deadlifts, and all that, hit me up. I'd like to hear about this.
Great. Well on that, uh, very ops-related note, why don’t we won't wrap things up?
Thank you, Luis, for coming and chatting with us and sitting on my very uncomfortable closet floor with your six pillows and coffee cup. And—
Don't thank me. I'm only doing this because you're buying lunch.
Thanks for listening to Opsy. You can find resources and links from this episode in the show notes at opsy.work. While you're there, I hope you'll take a second to join our free community where we share resources and opportunities that help us all level up in our ops careers. Again, that link is opsy.work. Until next time, stay Opsy, friends!
We send out content like this every other week. Sign up here to stay in the loop!