From Scrapy to Scaled: You Finally Landed Resources to Grow Your No-Code Operations. Now What?

Hi, my name is Phil Blayken. I am the head of Enterprise Innovation at Zapier, and I'm super excited today to talk to you about going from scrappy to scaled in no-code operations here at ProductivityConf.

Let's dive right in. So before we go into this whole story, I just want to give you a little bit about my story. So like many no-coders, I didn't come from the world of all things technical and IT and computer science. I was actually an actor before I was in tech, doing everything from Law and Order and Gossip Girl to films and cans and Tribeca Film Festival. And then I eventually started my own business because I was a super mediocre waiter when I was living in New York City. And I fell in love with the girl marketing and promotions, which is what you're seeing here at your NYC concierge. And that business was acquired by Get, which is an Israeli-based uber competitor, where they wanted me to go from street team management into building out an operation that could onboard drivers in the field using street team and field marketing tactics. And they wanted me to build out an entire way to onboard drivers in the field with an app. And we had no developer support on my team, so I was the developer and built that. And that's what got me recruited at Compass to do a lot of no-code work there, where I built out the no-code onboarding workflow for thousands of real estate agents all over the US, all the way through Compass going public. And then eventually I started No-Code Ops, which was the first community for operations professionals in no-code. We built an observability product called Operator, and we were eventually acquired by Zapier, where I am today as the head of Enterprise Innovation. So it's been a really rag journey. I've learned a ton about scaling no-code. I've made almost every mistake. I think you can make in the book. So I'd love to tell you about everything I've learned on my journey. So let's start talking about you, less about me.

The rise of the ops hero. This is the story that I heard over and over and over again when talking with members of the No-Code Ops community. Typically it starts with you're asked to automate something like lead routing. You've never done this before, so you start reading in how to do it, what systems you can use to do it. You've got no dev support from your dev team because when does ops ever get support from developers?

And so what do you do? You find a tool like Zapier or Airtable or Typeform to help you in that process. We've seen lots of folks use Zapier for things like lead routing when it comes to, hey, if it's this type of lead they say in the form, route them to this person. If it's this type of lead, route them to this person. And super complex workflows as well with like territory management and stuff. So you don't have to be technical to know how to set that stuff up in Zapier and that's typically how a lot of folks get into No-Code. They just had to solve something and they didn't have dev support.

But here's the problem. You as the person on your team, maybe you're not in sales ops or rev ops yet. You're on the sales team, you're on the CX team, you're maybe chief of staff. You haven't done something like this before, but word spreads. And now everybody wants in on not having to wait on developers to develop something to move super fast. So the marketing team might want in and they've got their own ideas. And then your sales leadership team goes, well, maybe we have some of these quick requests, but now you have to start training others and building more things, noting your own roadmap. And it gets out of hand very fast when people find out there's a quicker way to do things than going to devs. And so what does that turn into? Chaos.

So it's the paradox of success. You've got to balance building things and also at the same time maintaining them. And if you're not doing this full time yet, because you're not full time sales ops, rev ops, you also have your day job to consider and take care of. So this is what I like to tell folks who are at this point in their career where they're starting to get all these inbound requests, starting to become the popular person in the company for these types of systems. I like to say what got you here won't get you there. And so let's dive into that idea. So what got you here? You had this build first, ask later mentality. You just figured it out. The documentation, it was mostly in your head. It probably doesn't exist. You were the one person doing the stuff.

So you didn't really have to document much. You ignored errors until they really impacted others or massively critical systems. And there was no need to prove ROI because there was probably little to no investment in this stuff. But once you start on this journey, you realize that, well, some stuff has to change now that you're getting more recognition and more critical jobs within the company.

So changing to ask first, build later. So a lot of the times us folks in Nocode, we get really excited about the solutions. In fact, sometimes to this day when people talk to me about their problems, they're having it work or their manual things they're doing, I'm literally building the zap in my head and thinking about the solution or I'm thinking about that software I saw in Product Hunt that I know would solve for this thing. So I love solutions. I love Nocoders love solutions. But when we start getting bigger and bigger tasks that involve multiple departments or more critical areas, we've got to start with the problems.

Diving in and learning the problems before you recommend any solutions. Like I always say to folks, you would never trust a doctor that if you went to the doctor and you started talking and 30 seconds into you talking, the doctor's like, I got the prescription for you. You probably wouldn't trust that doctor. But if the doctor sat down and asked you a bunch of questions and listened to you and really understood what was going on, and then had a recommendation, probably trust that doctor more. And when it comes to other people's areas of the business that they care a lot about, they feel the same way. So it's really good to listen to really get to intimately know problems.

The end product that you end up creating across multiple departments, it shouldn't be a surprise. You should have involved people early and often, so that by the end of four or five weeks they build Journey, you're not delivering something where people are totally shocked. They should feel like, oh yeah, I was involved in this. I gave input on this. I knew exactly what was coming. So you don't want anyone being surprised at the end. And then, ideally, there's also something called the automation development lifecycle, which is something we care about deeply here at Zapier.

We thought a lot about it at NoCodeOps as well. But when software developers build things, they have the software development lifecycle. And the more automations that you're creating, or the more NoCode systems you're creating, it's good to think about them in different stages, right? Is this in the idea stage of the build? Is this in the deployment stage of the build? Is this in the testing stage? Are we in the maintenance stage? Are we in the observing and maintenance stage? Is this in the deprecation stage? There's a full lifecycle. And being able to clearly identify what lifecycle different automations and different builds that you have are, are really, just a really good way to communicate to others what your capacity is for what you can handle at any given time. So really great way to manage the resource that is your time when you're working with tons of other people.

Fostering a culture of documentation. So the number one thing with documentation is to start documenting what you wish you had.

So I don't know about you, but I've built some pretty complex NoCode systems in Zaps where I come back a year later and I'm just like, what was I thinking when I created this thing? And then I'm spending hours trying to trace down dependencies or seeing, you know, impact analysis. If I change this, what else would happen? And so I like to say if there was something you wish you had when you were fixing your debugging or changing something, just start with that. Just start with something super simple that you can write about every automation or NoCode system that you start to develop. I always like to focus on consistency over extensiveness. And one of the ways that I like to do that is I like to agree with other people on, hey, what is the quick format and place that we're going to document things? So let's say it's Notion. Every time I create an automation, I'm just going to create a quick why, what systems are involved, what team owns this, what systems is it related to? The more template types you can make documentation, the more secondhand nature it will be to fill it out. And pro tip, if you record yourself talking out loud about the documentation and then feed your template into ChakGPT, you can also have ChakGPT templatize your builds in written documentation for you based on how you talk about them. Fun, fun little trick there.

So there are a few types of documentation. There's architecture, user journey, and how to use this. They're all important. Architecture is really good for if you have multiple builders. So think of like, how was this done? Why was this done? What decisions were made behind this? What systems were involved? What SaaS apps were involved? What trade-offs were made? The user journey is more so, hey, as a user goes through this process or this automation, this is what their journey looks like. It starts with this form, and then the data flows through here and lands in this Slack message, and also lands in this part of the CRM with images. So that's like the user journey. Sometimes also people do that as the data journey. What is the trail of data through this automation or no-code system? And then there's the how to use this. This is typically when people hear documentation, they think about this one. Fun fact, if you've never used how to use this documentation tool, I highly recommend tango.us, my favorite tool on that front. But that's when you're teaching people how to use the system that you've built. And then when it comes to architecture documentation, really important to cover the how and the why. Why you built something and why you made certain trade-offs, really good for other people coming into your shoes down the road as you grow and progress your career. Oh, and sorry, last part. Almost missed this one, which is funny. But if people can't find it, it's not real. So if documentation is created and no one reads it or can't find it, the documentation doesn't exist. So put your documentation in places where people will easily find it. My wife is really incredible at this and it's funny because she used to work for a documentation company called Guru. But whenever I want to know where something is in the house that she put away, she always says to me, Phil, where would you want it to be? That's where it is. And so think like that, right? Where would your users want your documentation if they were in the middle of going through something that they were building? So I often like to see sticky notes living right on diagrams or notes right in the zaps or if there's different fields, can you put little icons in those fields that mean something to people? So put documentation where people are easily going to find it.

Brace for error impact. So the more systems you create with no code, the bigger they are, the more errors you're going to have. I'm sorry to say, but it will happen. So implementing monitoring tools and workflows. You know, there's some really great tools out there for monitoring. One of them is called Log Snag. You can also build your own monitoring workflows when you could say, if certain fields or things change in this, send webhooks into Zapier or Log Snag so I can get an alert anytime something changes. So you can get alerted upon a critical system changes that might affect your workflows.

If role-based access control isn't really cutting it, I kind of mentioned this a little bit earlier when it comes to documentation, but like put little emojis that means something to your team. Like train your team on what different emojis mean in different fields. And you know, that lock emoji can be don't edit this field, right? Without talking to me. So really easy way, you know, to let others know what is touchable, not touchable, breakable, changeable, etc.

Every automation should have a SPOA, a single point of accountability. The more people in a company, the more automations happen, right? You can have one form on your website that has 10 different automations running after somebody submits it over three different apartments that care about those. And so when no one owns an automation, when there's not one name saying, I own this automation, then it's easy for like someone to go in and change something and not know who it's going to impact or who they need to talk to. So every automation having a single point of accountability is really important. And when those single point of accountabilities leave the company, really important to have the conversations about who should take those over and what needs to be learned. And then linking error resolutions to relevant documentation. So look, if you've got a big problem that you just debugged, one of the best things you can do is do a quick write up on it and attach it to the documentation on that automation. So that way if someone faces that problem again, they can see what was done with that problem and who resolved it and what was done to resolve it.

So A, B, C, D, I liked always be communicating and I would have liked something about like results or something but it didn't flow as good as A, B, C, D. So always be communicating dividends. Us ops folks who automate things and who are growing our careers doing these automations and building complex operations across multiple teams, it's really easy to just think, you know, if I do the work and it's good enough, people will notice and that'll be good enough to talk for itself. The work is good enough. But that's just not true because when automations work, they're pretty invisible. And so it's really good to showcase your work to folks and the results of it and bring up the work that you're doing and the roadmaps that you're building. If you're starting to collect work from a lot of other folks, show a roadmap in different meetings saying here's the requests I'm getting in. And if people give you requests, follow back up with them if you complete them saying, hey, I really loved your idea about adding a new field in the form that would, you know, give more information to this part of our CRM. Here I implemented that. Thanks for the feedback.

Let's celebrate that person that gave me that feedback and close that loop. Getting specific success stories. Man, if you're doing really cool work, no one's going to highlight that stuff for you. One of the things we did at Compass, one of the companies I worked at, was we did a time trial of someone doing things the old way and someone doing things with the automation. We ended up saving on average, you know, four hours a week per person in that department, which ended up being a huge cost savings. But no one was going to go and do that study for us. We had to build that out and conduct that study. That was really helpful. But sometimes people also like qualitative examples of this stuff too. So, you know, getting some quotes from internal users about what a process used to look like before you got involved and what it looks like after or, you know, showing like a story of a customer that got better service because of something you implemented in terms that, you know, gained speed efficiencies on the back end, right? So, like specific stories could talk to people too, not just numbers.

And then here's some really great ways to showcase ROI. I'm not going to take credit for this. This came from Mike Cardona, who's one of my favorite thinkers in like the operations and AI space. I posted it on this URL, tinyurl.com slash hidden levers AI, which is his newsletter, which I also highly recommend. But you know, sometimes you can't always show money or cost savings when it comes to automations. You're great when you can do them. But when you can't, there's other ways to show ROI. There's time savings, error reduction, increased output, improved data quality, and higher customer satisfaction like measuring, you know, CSAT service before and after a process that you implemented.

Now, when you have your ROI story, different teams at your company are going to care about different things. IT is going to care about one thing, devs are going to care about something else, business leadership is going to be totally different, and end users are going to care about something totally different as well. And when I say end users, I mean the internal people at your company that are using these no-code systems and automations.

And on the right-hand side, you see some of the KPIs. So benchmark, you know, you have some benchmarks around how is the process currently working, what is it currently performing, and then what are some of our metrics that we want to hit and targets and how are we currently doing against them and how long was that being tracked against. Showing these updates to folks, like I said, no one's going to do this work for you. So it's really important to do it and talk about your work. And that's not only for, you know, getting bigger and better opportunities within the company, but it's also, you know, if you ever want to go into no-code consulting, which plenty of no-code and automation folks do either part-time in a moonlight capacity, or they end up doing it full-time, this is the kind of work you have to do for clients anyway. So really good to get used to this.

Now, when you have your ROI story, different teams at your company are going to care about different things. IT is going to care about one thing, devs are going to care about something else, business leadership is going to be totally different, and end users are going to care about something totally different as well. And when I say end users, I mean the internal people at your company that are using these no-code systems and automations. And so here's a great example of this. This is a zap that we had at no-code ops, that was our user, our intake form, and router. So an IT person might go, hey, whose auth is sending emails via Gmail? Because you can see the Gmail's being used here, and by the way, pro tip, make sure to use service accounts when you can like automations at or hello at your company.com, as opposed to your email, because if you ever transition jobs, all those auths will not work anymore in automation systems like Zapier. Devs might go, hey, which version of our web flow form was connected here? The business leadership might say, huh, I wonder how many leads are qualified versus unqualified, I'd love to see those numbers. And an end user might look at this who's like one of your ops team and go, hold on, paths? Are the people who are qualified leads here not ending up on our newsletter list? And fun fact, when you look at paths in Zapier, it doesn't just choose a path, the data can just go down one, it checks the conditions of every path. So actually, if they were qualified, they would also get the newsletter if they signed up for it, fun fact.

Quick bonus wins, so some super actionable things you can do right away. So the first one I already gave you a sneak preview of, which was service auths versus personal auths. The next one is regular show and tells. So if other people are building these automations at your company, get together and talk about what you're doing with each other. Some of the best ideas I had in my job as an ops professional came from other departments and collaborating and being like, wow, I didn't even know that we could use the tools in that way. So getting folks together to do show and tells with the cool stuff they're doing, super inspirational, really validating. Internal certification programs, if you want more people to use tools like Zapier and Airtable and Formstack and Fillout, these complex or powerful no-code tools, sometimes it's good to just have an internal certification program like, hey, this is how we use this tool here, this is generally how to use this tool, but this is how we use this tool here and these are what these things mean. And just having some kind of internal certification can get you really comfortable with allowing more people to use the tool, not centralizing everything to falling on your plate. Making maintenance work visible to stakeholders. Look, when you're building a lot of no-code automations, it's easy to eventually have, I don't know, 30, 40% of your work not be building new things, but maintaining things that already exist or fixing things. If you're doing that work, make that visible to your managers and your stakeholders in weekly or monthly updates. Because if you don't show that you're doing that work, they're just going to want you to do more of the new stuff all of the time, thinking that, well, what's that other 30, 40% of the time doing? It's like, well, software doesn't maintain itself, right? So you're going to be the one maintaining it. So make sure that you're advocating for yourself and voicing that. And lastly, if you need more resources, sell pain, not benefits. A lot of the times people will see a new system out there or a new tool and they'll go, oh my gosh.

The benefits that we're going to get from this are going to be incredible. And they try to sell benefits and they get shot down pretty easily by executive leadership or management on their team, departmental management. I like to say to folks, sell pain in those. Try to say if we don't do this, here's what could happen. And when you sell pain, when you work in operations, it's usually more tangible than selling the benefits.

So that is it for me. I hope that you take away from this talk how to grow beyond what you've found yourself in, which is you're the ops person who started doing all this stuff with no code and automations and now you're getting bigger and bigger and bigger things to do. And now you have some clear, concrete strategies on how to take this kind of place that you've maybe stumbled into and turn it into a whole purposeful career. This has turned into an entire career for me. I know hundreds of others who it's turned into full careers for them. And those careers, the more purposeful you are with them, the more this can turn into going from a salesperson that does a little bit of systems work to a full-time sales ops person or moonlighting and getting some freelance gigs on this stuff or eventually even starting your own agency and doing this stuff full-time. So all of these skills are helpful to get you further along on your path.

If you have any questions at all, feel free to reach out to me on LinkedIn or X or TikTok. You'll find me under Philip Lakin. Can't wait to talk to you and hear about your journey. Thanks so much and have an awesome rest of your time at ProductivityConf.