In our first episode, we join with two of the team from On Deck, Michael Gill and Curtis Cummings. They join our hosts Philip Lakin and Blake Bailey to give us their insight into where no-code can take new startups and how you can use it to iterate at lightning-fast speeds internally.
Masters of Process brings you the no-code revolution in full. Join us as we meet with top innovators in the space and explore how they are reinventing the way a modern business operates. Brought to you by industry insiders from No Code Ops and Process Street, each half hour episode is a goldmine of productivity, products, and scaling.
Listen now on your favorite podcast platform. Subscribe now so you don’t miss out on the most in-depth no-code insights!
Masters of Process: On Deck with Michael Gill and Curtis Cummings
Philip Lakin: Hey, everybody. Welcome to the first episode of Masters of Process. My name is Philip Lakin and I’m the co-founder and CEO of No Code Ops. I’m joined by my co-host Blake Bailey. Blake, do you want to introduce yourself?
Blake Bailey: Yeah, I do rev-ops and no-code for Process Street.
Philip Lakin: And today we are joined by two of my darling and great friends in the no-code space, Curtis Cummings and Michael Gill, who both work on no-code infrastructure at On Deck. Curtis and Michael, welcome to the show.
Today we’re going to be talking about how to build a no-code operational culture from day one, which we’re super jazzed about. Curtis and Gill, y’all wanna tell us a little bit about On Deck and your roles there?
Curtis Cummings: I can start with that. I’ve been at On Deck for about 10 months, which is an eternity in start-up timelines. I’m leading the no-code infrastructure team that helps create the building blocks used by the rest of the ops org and the team at On Deck to build their no-code MVPs and products. Previously, I worked as a software engineer which gives me unique insight into no-code. I kinda found no-code about two and a half years ago. I’ve loved it ever since.
Philip Lakin: Amazing. And Gill, you wanna tell us more about your role, and then about the mission at On Deck?
Michael Gill: Sure. I also work with no-code infrastructure. Curtis brought me into On Deck about four months ago back in May. I’m working with him on that. Before On Deck, I was a CTO and a developer, running my agency and all that jazz. At On Deck, no-code is definitely in the DNA. Our whole goal is to continue to harden and scale no-code; meaning we can continue to use it as we grow at a rapid pace.
Philip Lakin: Yeah. I keep reading more and more about different cohorts y’all are launching. For those who are not familiar, On Deck is virtual learning in the cloud with peers on different topics. Would you guys say that’s a fair picture of On Deck?
Curtis Cummings: Yeah. On Deck is constantly evolving. On Deck is a modern education institution built for the internet. It provides different cohort-based courses. Some of these courses are annual, meaning if you’re like chief of staff or you’re a designer or something, you can opt into these communities and have a lifelong membership where there are constant talks, masterminds, and all sorts of programming. And the exciting stuff that we’ve been able to put on is when these fellowships kind of meet and cross the boundaries of other fellowships. This means you can have no-coders to help people try to found companies who are getting funded by the angels who are there, who are getting resources from designers, PMs, and customer success. These are, what we like to call internally, flywheels. One fellowship usually is the source of another fellowship. We have these flywheels spinning, and it’s a market-driven network – is what the fancy term for that is.
Philip Lakin: I love it. Blake, have you, or do you know anyone, who has gone through the On Deck review?
Blake Bailey: No. But there are many different programs like On Deck. Of course, On Deck is one of the best ones. I’ve had a lot of friends who have gone through apps similar to On Deck. I’ve gone through a couple of ones similar to On Deck as well, although I do wish I went through On Deck.
Philip Lakin: You missed out, man. I was at the On Deck no-code fellowship one and it was unreal. Unbelievable. Helped me go from zero to one. And by the end of it, I was doing my side hustle full-time as a start-up in the no-code space. I can’t complain. I’m a big fan.
Sweet. Building a no-code culture from day one. The thing that I was most excited about talking to you both, is that On Deck is one of these companies I’ve seen use no-code from the beginning, and then scale with it through a $20,000,000 round. Like all the infrastructure seems to still be built on no-code, but it seems that you also empower your employees to experiment and use no-code. I’d love to learn a little bit more about how that works. Like how are people internally empowered to use no-code in new ways?
Curtis Cummings: I can start with that because I was there earlier when we were much, much smaller. Gill mentioned that no-code is in the DNA of On Deck and that’s because it started as a very scrappy start-up of three people, and none of them were engineers. This meant they had to use no-code tools. And as we started to scale operations, we rolled out more programs and continued to use that no-code. And then once we started growing a little bit more, we really got executive buy-in to continue using no-code.
It’s unique what we’re doing. We have a full product engineering team, there’s a lot of our product that is in code, like a traditional start-up running product organization. But we’re also enabling everyone at the company to build products using no-code tools. And once they hit something we’ve coined an internal product-market fit, this is when we go in and harden it and add it to the code-stack.
Philip Lakin: I love that term! I had to call that one out. That’s beautiful from an operator’s perspective, internal product-market fit. What does it look like when someone hits that internally, with like a no-code MVP they’ve built for an internal process?
Curtis Cummings: One unique thing at On Deck is almost nothing gets coded until it’s had an MVP done in no-code. It might be version 0 and version 1 are both in no-code tools. Internal product-market fit means it’s hit a critical mass for number of programs using it internally. That means thinking about how much exposure it has to fellows, or it might be that we’ve developed something very strategic and we want to bring it to the next level – whether that’s hardening it or making sure it’s part of our directory product or some of the other code products we have. It’s the same thing as a product-market fit for a start-up. We’re viewing it as these different products, that their customers are the fellowships, and maybe if it’s an internal tool, it’s the internal team. And once they hit critical mass and it’s doing what we needed it to do, that’s when we go about hardening it or coding it.
Blake Bailey: What are some of those tools that you guys are using on a typical basis to build those version 0 and version 1 MVPs?
Michael Gill: It depends, as it’s sort of the wild west in that sense because we’ve optimized it for the user experience and customer experience. This means, those that are closest to the customer can use whatever tools they want. I mean the main ones are apps like Airtable and Zapier. But in reality, there’s a whole bunch of tools where you can kinda grab one off the shelf and make it work. And I think that’s the special thing about On Deck, and what stood out to me when I first came in.
It does depend on what you optimized for. If you optimize for customer experience, the first concern is not what tools you are using or whether engineering has approved that. You don’t have to go through engineering to get your product launch. You need to get it launched, get it working, do what you need to do, and then have an engineer later to help take you from version 0 or version 1 to something more sustainable for the future.
Philip Lakin: Awesome.
I hear folks listening saying, “Well, you know, this is all well and good that nontechnical people can use whatever tools they want to serve the customer. But what happens when stuff breaks or someone goes off process or someone who started an interesting process leaves the company, you know, where is the safety security structure of something like an engineering culture that is coded?”
And so I’d love to hear from you all. What do you do to allow the wild west? Allow folks to build and serve the customer without the constraint of waiting for developer resources, but do it in a way that is scalable, safe, secure, and repeatable. I’d love to learn more about that.
Curtis Cummings: No-code infrastructure is the way we do that.
This team didn’t exist three months ago and it spun up because we wanted to solve this problem. It was wild west like six months ago; people using personal Slack connections to wire up Zapier flows. So if someone left that Zapier flow, it broke. We’re getting a lot better with that, and that’s why we’ve appointed head of IT to properly set up accounts, meaning we can work through Slack apps and bots since that’s scaled to all the different tools. This means if one person leaves, everything doesn’t tumble. But then also there’s an amazing ops internal training document that’s spun up, which isn’t our team, it’s the ops team, but they codify all the learnings from what they’re building.
These learnings are incorporated into our onboarding processes. This means you can take two to three weeks to train up on no-code tools. Then when you do hit problems, that’s when the no-code infrastructure team steps in and can help you in engineering because everyone on the no-code infrastructure team is an engineer. We’re also no-coders. We do day-to-day support and we do like bigger building blocks. If I can’t find a tool that does this one particular thing, we’ll work with IT to figure out if we have something already that someone used, or we’ll spin up something, or will code something to help block them.
Philip Lakin: Amazing. And if people listening take one thing away from this podcast, please, if you work at a company and you’re using Zapier, don’t use your personal Gmail or Slack connections, because when you go, those go.
Michael Gill: Yeah, one of the other elements that stood out to me when I first joined On Deck is to help with what you described: Documentation.
On Deck has some of the craziest documentation I’ve seen; our Notion is almost bursting at the seams. Everything is heavily documented. I feel like all the processes are open in the company; there’s no pride of ownership or walls where you have to get access to find out what other teams are doing. It’s all readily available to everybody. And so if somebody leaves, or a process changes, then we have documentation that covers that.
For early start-ups – especially ones who are growing fast – documentation is usually the first thing to suffer. So, we make sure we have an underlying stable layer. We still have a traditional relational database, we have automation processes that copy data from one place to the other, and make sure that we have redundancy and stability built-in. This means if something breaks or a third-party tool decides to shut down or go a different direction, it’s not a big blow to our system.
Blake Bailey: You mentioned Notion and some of the documentation levels that you guys have. I’m interested because this is a problem that I face, and an issue that a lot of people in this space generally are facing. At what level do people document a new creation? Or when they are editing something that already exists, at what point are you making sure that people are documenting that? And do you have automated ways to do that, or is that purely a cultural thing? Or is it both?
Curtis Cummings: That’s a culture thing.
We work as a globally distributed remote-first company. This means we have very few meetings. And if you do have a meeting, you better have a Notion doc that has the full agenda laid out with all the call-outs and stuff. It’s expected that before you go into the meeting, you’ve read the agenda and you’re up to speed on any background that’s been linked to other Notion docs.
It’s mostly culture and it’s beaten into everyone that when you change a process, or when you finally figured out a process and how it’s working when you’re rolling it out, you need to make sure you have that procedure in the right spot in Notion.
Michael Gill: Everyone is busy, so there’s a natural incentive to not have to explain something multiple times. And by the time you’ve answered the same question twice, guaranteed you’ve already recorded a Loom and thrown it into a Notion doc. You can use that document as a reference and send it to somebody; that way you don’t have to explain work multiple times. That’s part of that culture of wanting to streamline the sharing process.
Blake Bailey: Truly no-code is made up of productive lazy people. I think it’s all founded in the sense of “I don’t want to deal with this.”
Philip Lakin: Yeah, it is the externalization of structured procrastination.
For everyone listening, this is the Masters of Process podcast. This is episode 1 with Curtis Cummings and Michael Gill from On Deck. My name is Philip Lakin. I’m the CEO and co-founder of No Code Opps. We are a community and newsletter for no-code operational professionals. Blake, do you wanna talk about Process Street?
Blake Bailey: Sure, yeah. My name is Blake Bailey. I do rev ops, customer success, and special projects at Process Street. Process Street is a process management tool that allows you to document your processes but also to hook them up to other services through automation, and to be able to actively track what’s happening at each moment across all your processes, and then also report on them by being able to export that information wherever you need.
Philip Lakin: Amazing, very on topic, right? Process documentation.
Blake Bailey: Yeah, that’s why I have questions on it, because it’s kind of my thing.
Philip Lakin: Fun question. Tell me, or tell us about a time that something went awry with no-code. I think in the community, we talk a lot about how awesome it is and how fast it is, and how quickly people can pick it up. But we don’t always talk about the blunders. I know I’ve had a few. I’d love to hear from you all like what was the blunder? How did it get remedied?
Curtis Cummings: It’s sort of related to what you were getting at with people leaving the company.
We had one particular person who had their Slack connection all up and down Zapier. This is well before the infrastructure existed. I was a senior engineer at that time working on code. Yeah, that person left and we deactivated their Slack account, and we lost everything. Any notifications or any automation we had set up in Slack broke. And it took us a week to figure out all the places and reconnect everything. And yeah, it was a huge mess because some of the Slack channels were private channels. And because the person was no longer there, there’s no good way to invite another user into that private channel.
Another one that kind of impacted us recently is – which is not unique to no-code, but has impacted us a lot at scale – is when Airtable, or Amazon AWS had some downtime a day or two ago. That impacts us. We had a couple of hours of Zaps firing that were pulling no data because of what was changed in the Airtable automation. And then later that day, AWS west went down. We lost a lot of other connectivity tools. This is the reality of using the cloud. No-code is based in the cloud. We don’t self-host a whole lot.
Yeah, those are the things that continue to go down for us. We’ve kind of fixed the service account problems because everything is done through apps or service accounts. The downtime thing, well it’s hard to have a fully redundant system, but we at least have the steps in place to recover from stuff like that.
Michael Gill: In my first month, I saw someone become excited about Integromat, and went ahead to build their first scenario. And let’s just say it wasn’t the best scenario. When we were maybe halfway through the month, we went through all of our billing credits to find we had gone over our normal limit.
Philip Lakin: All names have been changed to protect the innocent on that one.
Michael Gill: Exactly, yeah. Also during the hiring process, I heard stories of someone accidentally deleting a whole Airtable…which can happen when there’s full access.
Philip Lakin: Oh the joys of access rights, right Blake?
Blake Bailey: Yeah, that’s something I deal with too. It’s not fun.
It’s painful to even talk about, but I have one of these stories as well. I went on paternity leave. I mean, I came back from paternity leave about two weeks ago. Before I went on paternity leave, I spent a good month or two prepping and training everyone to make sure everything ran smoothly. In one of the last jobs I did, I set up an automation meaning when I went on leave it would block off my calendar and message my main contacts and internal team. Everything was set up to make sure I was good while away for six weeks. In my head, I was thinking, ‘Man, I’m gonna have to drop everything and go to the hospital. I’m not gonna have time to do everything. I gotta make it easy.’ Well, I set it all up. It’s all good to go.
I wake up the next morning and the automation had fired by itself. Calendars are blocked, the entire team and company think that I’m out on paternity leave. It messaged like 80 people, like 80 customers, stating “hey, I’m on paternity leave”. I wake up and I have like 100 emails of people congratulating me, and like 50 different Slack messages. People are all excited. And then I had to tell them. I had to spend an entire day undoing the automation. This is the worst feeling in the world when you spend time building an automation to make work easier, and then you have to undo it. And I hope I never have to repeat that. I then rebuilt the automation. I rebuilt it with a specific code word that I had to send to somebody else, and then they had to do something to trigger the automation.
Philip Lakin: Curtis and Gill, blunders and fun stuff aside, I have the utmost respect for On Deck, for pushing the envelope on this front. I think as more companies are forming and growing super fast, and the need for technical talent is high and the demand remains fairly low, we’re going to see more and more start-ups using no-code; not only for their external products that their customers are using, but also for a lot of their internal processes, from day one.
What would be your recommendations for operational folks internally, who are maybe like the first one or two operational folks at a start-up starting to experiment with, and using these systems before all the scale happens – like from day one, what would you recommend?
Michael Gill: Yeah, definitely join the On Deck No Code (ODNC). Shameless plug, but I would say build your side project and use it yourself. When you’re the one building and using it, that’s the best way to learn. That’s probably the best advice I can give. You building for somebody else doesn’t have the same learning opportunity.
Philip Lakin: Awesome. Curtis, any thoughts?
Curtis Cummings: I’ll echo on a personal level what Gill said.
At On Deck, no-code was a necessity because they had to build a product with no-code. But even once they had coders come on, the product engineering team still leads the product, but they set the constraints that other people can then play in. Have good conversations early with product developers, stating that no-code will make their lives easier, i.e., it’s easier to iterate and code something that’s already been validated by a bunch of users, like actual user metrics versus a spec that’s in Notion. Yeah, getting early buy-in from your engineers can support that process, getting executive buy-in is also huge. If you’re super early, getting someone in that knows how powerful no-code can be, is good. This means you won’t have to do grassroots advocacy. You can get support for your no-coding from the top-down.
Philip Lakin: I think one of the best ways to sell no-code to engineering teams is to say, “I’m creating a living battle-tested spec“. By the time you get your hands on it, we know what worked and what didn’t work – it’s not just a theory. It’s something that people have used, that’s been iterated on. I think that is an incredible way to put it.
Sweet, to wrap up, we’re going to talk about something Gill and I are used to from the Zero-to-One Makers Club in Atlanta. We will talk about our recent favorite product. Before we do that, I’ll give everyone a moment to think about it and I’ll talk about how I was introduced to the Zero-to-One Makers Club.
I saw No Code Coffee, Gill’s newsletter on Product Hunt, and was like, this is cool. I found that he lived in Atlanta and I found his CTO website. I scheduled some Calendly time to hit with him because I was like, “I’m new to Atlanta and I wanna make friends.” And Gill responds by asking what this meeting was about. And I’m like, “I just want to make no-code friends because I’m new to Atlanta.”
Gill replies saying, “Well, I’m going to this meet-up at Switchyards for the first time.” This is a co-working space in Atlanta. And it ended up being Zero-to-One, and it’s an epic group that includes the likes of KP and Dru Riley from trends.vc, and Ash and Whit from Bad Unicorn. These are legends in this space. And I was introduced to that whole group because I randomly reached out to a dude that had a cool thing on Product Hunt. Thanks, Gill.
Michael Gill: I have to tell you, Phil, I had anxiety about that because you’re reaching out to me to say, like, “How do I get started?” And I was like “Oh, come to this meet-up with me”. And literally, as I’m on my way – because I’ve never been before – I’m like, “What if this thing is a bust?” Like, I have no idea who these people are, how this could be, and it turned out to be the most amazing group of no-code makers. It’s legendary. I had no clue. I was like, “Come with me. I’ll tell you the way.” And it worked out.
Philip Lakin: It all worked out. Cool, Blake do you want to kick it off? Your favorite product?
Blake Bailey: Sure, I think my favorite recent product is one that filled a big hole I had from another product that was bought.
For years, I’ve been a heavy user of Woven, which is a calendar tool. Their calendar was wonderful. For years, it was free. I was using it when it was in beta. I’m using it for years, but I should stop because they were bought by Slack and shut down. The aim was to integrate it into Slack. I hope, as a Slack user, that happens. But for a while, I had this pain, this gap that I had to try to fill with something new.
And so somewhat recently, I found out about Vimcal. Yeah, and I like it. It does some tasks better than Woven, although there are other tasks that it doesn’t do that Woven did. Vimcal uses quick keys, and you can create automated stuff within the tool itself, such as sharing your available time.
Philip Lakin: When you send me your available times, like in text format in Slack, is that from Vimcal?
Blake Bailey: That’s from Vimcal. I could send it to you in text, or I can send it to you with links to book time. I could send it to you in all sorts of ways. I could pull up anything within about two quick keystrokes. It’s useful for super-users like that.
Philip Lakin: Sweet. I love it! Curtis, what you got?
Curtis Cummings: I discovered Path Fix. Pathfix.com is a serverless API that does authentication to other SaaS services. It’s the same sort of thing you could hook up with Integromat, but this would be good for cases where you need to like hit one URL, and you want that data back. I’m gonna try and incorporate this into what I’m working on this week.
Philip Lakin: Shout out to Path Fix. Gill, what you got?
Michael Gill: Something that I think has been a big kind of gap in the no-code space for a while, is an easy way to create Chrome extensions. An emphasis on easy because there have been a couple of ways to do it, but if you go down those paths, it’s complex.
I’m working with Builder to kinda help with some of their content generations, like educational content. Builder is a no-code tool, if you haven’t used it before, allowing you to build chrome extensions and more. I built my first Chrome extension with Builder and it was super easy.
Philip Lakin: What does the Chrome extension that you built do?
Michael Gill: It allows you to go to any web page in your browser, hit a button to click the web page, and this pulls the details from the webpage, i.e., the title, the description, the URL, a lot of the metadata, and then the social share image. You can add notes and you could save these notes anywhere; You could save it to Airtable, you could save it to a Zap in Zapier, or you can even generate a banner image and post that somewhere.
Philip Lakin: Sweet. And for the last one, for mine, I’m gonna say, not because I’m trying to get more free credits on them for a free forever plan, but I’m going to say Sidekick as a browser – meetsidekick.com. It is incredible. It’s built on Chromium. For those familiar with Chrome, there are two differences between Sidekick and Chrome:
- Sidekick natively blocks adds meaning everything moves a lot faster.
- Sidekick has this amazing sidebar for all of the apps that I use regularly, right in the browser.
Expanding on this second point, a lot of companies try to attempt this – like Shift, Station, and I think Wave Box. The problem with all those is they access all your web apps through one single desktop app. This means you can only access the apps and you can’t create new browser tabs. And I want the power of both in one place; meaning every time I open the app, it’s not creating a new tab, but I can also create new tabs for random jobs alongside, should I want to.
And I get to do both with SideKick. Every time I hop in Gmail and if I have two different Gmail accounts, I can have two different apps for those and I can seamlessly switch between them without opening a new tab. It has helped me somewhat curb my overload on tabs. I can’t say completely because I love me some tabs, but yeah, I’m a big fan of Sidekick.
Cool, well Curtis and Gill thanks for joining us on our first episode. Blake, it’s always a pleasure to hang out with you, man. Talk to everyone soon.
Thanks, everybody. You can learn more about On Deck at beondeck.com. They have some incredible fellowships coming up that y’all should be looking at. I don’t know when the next no-code one is, but when it comes up, you should do it. Also, checkout Process Street for all of your process and documentation needs.
And if you are loving this conversation and want to have conversations like this regularly with other no-code operation professionals, you can sign up for the newsletter at No Code Ops. Also, apply to join our community.
Thanks again everyone and see you next time!
Are you a no-coder? If so what no-code tools, apps, and software do you use to make your work-life easier? We’d love to hear from you, who knows you may even get featured in an upcoming episode! Subscribe to the podcast on your favorite podcast platform!
The post Masters of Process Episode 1: On Deck with Michael Gill and Curtis Cummings first appeared on Process Street | Checklist, Workflow and SOP Software.
0 Commentaires