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.

1. 1/11
October 22, 2021
Masters of Process Episode 1: On Deck with Michael Gill
and Curtis Cummings
process.st/masters-of-process-episode-1
Jane Courtnell
October 22, 2021
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

2. 2/11
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.

3. 3/11
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

4. 4/11
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.

5. 5/11
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.

6. 6/11
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

7. 7/11
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,

8. 8/11
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.

9. 9/11
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?

10. 10/11
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:
1. Sidekick natively blocks adds meaning everything moves a lot faster.
2. 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.

11. 11/11
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!