Hey everyone, Michael here with the ArchSmarter podcast. Today's episode is "Working Lazy by Design: A Framework for Smart Automation." And yes, you heard that right - we're talking about being lazy. But not just any kind of lazy - we're talking about strategic, intentional, designed laziness that's going to transform how you work.
You know the saying - "If you want something done, ask a busy person." But I've learned that's wrong. The real saying should be "If you want something done, ask a lazy person." But not just any lazy person." You want a certain kind of lazy person. You know the type - that person in your office who seems to get twice as much done as everyone else? The one who always leaves on time while everyone else is staying late? Well, I used to think they were just faster workers. Turns out, they're likely working lazy by design - and today, I'm going to show you exactly how they do it.
Let me share a story from my architect days. Back in 2006, I was working at Gehry Partners in Los Angeles. We were working on a big mixed use project in Brooklyn. We just finished a deadline, I think it was our 50% DD submissions. One of my jobs on the project was to package up the drawings, specs, and 3d models for each submission. This involved a lot of cleaning up CAD drawings, organizing files, and uploading PDFs. It wasn't hard work but it was very tedious. So while everyone else had gone out to celebrate, I was stuck in the office going through file after file after file. After pulling multiple 70-hour weeks to meet the deadline, I was running on fumes. The coffee had stopped working hours ago. The only thing keeping me awake was a steady stream of vending machine snacks.
I finally got home around 2 AM, my head is pounding, my eyes burning from staring at screens all night. It was at this low point that I thought, there has to be a better way. This can't be how we're meant to work. There was another deadline coming up and I needed to change how I did things. I had a young son at the time and I'd much rather be at home with my family than crunching files all night at the office.
So that Monday, still recovering from my previous all-nighter, I made a decision. I was going to work lazy by design. I bought a programming book, I did a lot of googling, and I started writing some awful scripts. But here's the thing - those awful scripts worked. They weren't elegant, but they got the job done.
I had tried to learn how to program before but it never stuck. I took an intro programming class in grad school. After spending hours and hours studying for the midterm, I got a 50 on the exam. Not good. I quickly dropped the class and figured I was just incapable of learning how to code. I told myself that my brain just didn't work that way. So What motivated me this time? Simple - I was the one who was going to benefit. I had real skin in the game and I was super motivated, so much so that I forced myself over the learning curve. Because when I did, it meant no more late nights at deadlines. After weeks of work on my scripts, making lots of mistakes but slow and steady progress, when the next project deadline came around, I had reduced that 8-hour drawing cleanup and packaging ordeal down to just one hour, all through automation. I had turned that manual checklist into a series of scripts that could handle the cleanup, the exports, the file organization, everything. I could even hand it off to others to run.
That was my first real lesson in working lazy by design - sometimes you have to work harder up front to be lazier later. And let me tell you, every hour I spent learning to automate has paid itself back many times over. I've seen a huge return on investment.
Now, when I tell people about working lazy by design, I usually hear the same objection: "Hey, I'm too busy to learn how to program, to learn about automation." I get it. I really do. When I was pulling those 70-hour weeks, the last thing I wanted to do was spend my precious free time learning to code. But here's what I've figured out - being "too busy" is exactly why you need to work lazy by design.
After leaving Gehry Partners in 2012, I started ArchSmarter to help other AEC professionals work smarter through automation. Over the next decade, I consulted with firms of all sizes on their automation strategies, teaching them how to work more efficiently, and building custom tools. During this time I also created the Revit Add-in Academy, where I teach architects, engineers, virtual designers how to code their own Revit add-ins. Then in 2021, I joined IMEG, one of my former consulting clients, as a full-time automation specialist.
Through all of these experiences, I've developed what I call the CLIMB framework. It's a systematic approach to automation that I've seen work time and time again, whether you're just starting out or you're looking to take your automation to the next level.
CLIMB is an acronym that represents the five stages of automation maturity. Let me walk you through each stage using a task we all know too well - setting up a new project in Revit.
First of all, the C in CLIMB stands for "Capture Processes". This is the first step and it's crucial. We need to document how things actually get done. For project setup, What phases do you need in the project? Which views go on which sheets? What families need to be loaded? If you ask five people in your office how to properly set up a project, you'll probably get five different answers. So you want to start by documenting the right way - step by step. At the end of this stage, you'll have a clear standard operating procedure (SOP) document, which is a detailed checklist that anyone can follow to manually set up a project correctly.
Next, the L is where we "Leverage Templates". At this stage, we develop standardized starting points that users can build off of. For our project setup example, a good Revit template is a start, but we also need clear standards for view templates, sheet organization, what families to load based on the project type. Having these standards clearly documented or better yet, embedded in a template file, immediately saves hours on every new project. A while back, I wrote about a method I use to develop templates, called the CBT method. I'll include a link to this article in the show notes. By the end of this stage, you should have robust standards and templates that are specific to the project type and include all the building blocks you need for consistent project setup.
The third step in the CLIMB framework is "Implement Automation". Now that we have our workflow documented and good standards and templates in place, we can leverage the power of automation. This is where basic scripts come into play. We're not talking about fully fleshed out applications that take a team of developers months to produce. Instead, maybe you write a Dynamo script to create views listed in an Excel file. Or you create a small add-in to automatically load and place common families. These small, focused tools can start cutting down that project setup time from hours to minutes. The end goal of this stage is a set of automation tools, a toolbox, if you will, that accomplished some or most of the tasks in your SOP. And again, these can be Dynamo scripts, macros, or simple add-ins that each handle a specific part of the setup process you outlined in the first stage.
Alright, our fourth stage, the "M" in climb, is "Monitor Results". Because automation without quality control means you might just be making mistakes a whole lot faster. Are all the views named correctly? Did all the families load properly? Are the sheets numbered according to office standards? Here we want to build in checks to catch issues before they become problems. We also want to capture metrics on how many times the tools are being used and how much time is being saved overall.
Our end products at this stage are checklists and validation scripts that ensure that automation is working correctly as well as a dashboard so we can see the ROI, the return on investment for of our efforts. Is this effort working. Is it working as well as it should. If not, what can we do to fine-tune it.
Finally, we reach the top of the CLIMB framework and we start to "Bridge Systems". This is where everything comes together into a seamless workflow. Your project setup tool now pulls data directly from your project management software. It creates views based on the project type, sets up sheets according to client requirements, and even starts populating titleblock information - all automatically. The end result is a comprehensive automation system - a tool or suite of tools that handles the entire project setup process from start to finish, connecting with other office systems and requiring minimal user input.
Now, here's something I see from time to time - people want to jump straight to that end-to-end system. They want to click a button and everything maigcally gets created. They want to start at the top of the mountain without actually doing the climbing. But imagine trying to climb a mountain without first mapping the route, getting the right gear, learning basic climbing techniques, and testing your equipment. You'd never do that, right? It would be dangerous, and you'd likely fail.
The same is true with automation. You can't bridge systems if you haven't captured your processes, created good templates, implemented basic automation, and monitored the results. Each step of the CLIMB framework builds on the previous one. Skip steps, and you're setting yourself up for failure.
I've seen companies spend a lot of time and money on comprehensive automation systems that ended up sitting unused. Why? Because they didn't do the groundwork. They didn't understand their own processes well enough to automate them. They didn't have standardized templates to build from. They didn't start small and test their approach. They tried to launch themselves up the mountain without building their climbing skills first.
So where should you start? Begin with your own manual task nightmares. I had my drawing cleanup process as a motivator. What are tasks keeping you at the office late? Maybe it's sheet setup in Revit, maybe it's marking up shop drawings, maybe it's coordinating consultant files.
Write these tasks down. Be specific. Capture all the sub-tasks that going into completing the task. Next, time how long it takes. Then start small - don't try to automate everything at once. Remember, I started with some really basic scripts that just renamed files and cleaned DWG files . But those basic scripts gave me back hours of my life.
Here's a simple way to think about what to automate first. Look at your tasks through two lenses: how often you do them and how much impact they have. Tasks you do frequently that have a big impact - like sheet setup or view creation - these are your prime candidates for automation. Start with these.
For tasks you do often but have less impact - like file naming - you might only need good templates and standards. Don't over-engineer the solution.
Tasks that you don't do often but have high impact need good documentation and templates, but might not justify full automation.
And for tasks you rarely do that have low impact? Simply documenting the workflow is usually enough.
Here's your challenge for this week:
Pick one task that's keeping you at the office late.
Spend 15 minutes documenting exactly how you do it now.
Don't try to improve it yet - just capture it.
This is your first step toward working lazy by design.
Remember, working lazy isn't about cutting corners. It's about being intentional with your time and energy. It's about making sure you can make it home for dinner with your family instead of staring at a screen in the office at 2 AM.
If you found this approach to smart automation helpful, hit that subscribe button and leave a review. And if you want to learn more about working lazy by design, check out our show notes for links to resources and examples.
This is Michael Kilkelly with ArchSmarter, reminding you that sometimes the smartest way to work is to work lazy - by design. Thanks for listening.
