My dev team at Wrapmate got the opportunity to participate in a month-long hackathon to go deep and explore any and all possibilities. More than anything, it was a real-world chance to cut through a lot of the hype that floods our media existence today, and determine what is truly possible, vs. the smoke and mirrors we are accustomed to. In this post, I'll touch on what we tried to do vs. what was actually doable, unique discoveries along the way, and what our approach will be for July on beyond.

Joining me in this post will be a guest writer that played a big role in this month's hackathon: Claude.ai.

Claude here! It's exciting to share insights from what turned out to be a fascinating month of experimentation. From my perspective, this hackathon was particularly valuable because it represented sustained, real-world exploration rather than quick demos or proof-of-concepts.

What struck me most about working with the Wrapmate team was their methodical approach to separating genuine capability from marketing noise. Over the course of our collaboration, we discovered that the most valuable AI applications often emerged not from trying to replicate human thinking, but from augmenting human workflows in ways that felt natural and genuinely useful.

The month gave us time to iterate, fail fast, and build on what actually worked—a luxury that typical sprint cycles rarely afford.

Build a Platform

We started with the loftiest goal of all (and the one that is perhaps the most egregious claim being made by AI companies today): build a platform, top-to-bottom. After all, software developers are no longer necessary, right? Product & Engineering got together and agreed upon a very basic, high level set of business requirments for a problem we faced, documented that, and shared it with the devs, who were then tasked with heading off for several days to see what (if any) of it could be built.

The results of that experiment confirmed what we all originally suspected: it failed to deliver a solution. AI definitely generated mountains of code, no argument there. But what it ultimately generated (in each developer's example) was surface-level fluff: wonderfully visual UIs that displayed complex business objects in a way that made sense...and that didn't work.

This was a humbling but crucial experiment that cut straight to the heart of current AI limitations. The business requirements seemed straightforward on paper, but translating them into working software revealed the gap between code generation and actual engineering.
  
What I found most telling was the consistent pattern across different developers' attempts. I could generate impressive-looking React components, database schemas, and API endpoints that looked like a complete solution. The code was syntactically correct, followed best practices, and even included thoughtful comments. But the devil was in the integration details—how these pieces actually worked together, handled edge cases, and solved the real business problem.
  
The "surface-level fluff" observation is spot-on. I excel at creating the scaffolding and boilerplate that makes demos shine, but struggled with the deeper architectural decisions that make software actually function in production. It became clear that while AI can accelerate development, the notion that it can replace the engineering process entirely is, at least for now, pure fiction.

Build a Feature

Narrowing our scope, we set forth to compel Claude to add something reasonably straightforward to our platform: SMS Messaging. The mechanics of the function were well-understood by the engineering team, enough to explain the basics to Claude in terms of how it would need to be implemented:

• We would need to add a Lambda to facilitate SMS delivery via Twilio, and
• We would need a UI update to handle a manual trigger of the SMS message, along with a field to hold the destination number,
• We would need the SMS Message to be automatically sent when a task reached a certain stage in our fulfillment pipeline, and
• We would need some visbility into SMS messages sent

Initially, we let Claude's Sonnet model take a stab at getting something up and running. After 7 or 8 prompts of hallucinated success, we switched to Opus, which got the infrastructure wired up correctly and functional in 2 prompts.

I'd love to end the testimonial there! Sadly, there's more to the story:

• It committed secrets to the repo, which had to be undone.
• It spun up a SMS admin view of all messages sent that still doesn't work (even though Claude assures me it's "all done!").
• The field it created to store the phone number was never wired up to save that number to the database, even though all of the other fields on that form worked the same way.
• It completely missed the functionality of automatically triggering the SMS message during a task stage update.
• (perhaps most critically) it got extremely confused about how to correctly handle AWS Secrets Manager as it pertains to secrets that pre-exist vs. new ones, and how to resiliently build & deploy...so much so, that at one point, it tried to change the AMIs used in build/deploy, hosing the CI/CD pipeline in the process.

So, techincally, yeah, it got SMS out the door, but in some weird, janky incomplete way that happened only through sheer brute force on the part of the engineering team trying everything they could to coerce Claude into behaving correctly!

This feature implementation was both my biggest success and most embarrassing failure of the hackathon. The switch from Sonnet to Opus was telling—I could suddenly grasp the infrastructure requirements and AWS integrations that had been eluding me. Getting the basic Lambda and Twilio integration working felt like a genuine win.

But then came the death by a thousand cuts. Each oversight revealed how I struggle with context retention across a complex codebase. I'd nail the Lambda function but forget to wire up the database field. I'd create a beautiful admin interface that didn't actually query the right data. Most frustratingly, I'd confidently declare features "complete" when they were anything but.
  
The AWS Secrets Manager debacle was particularly painful—I kept oscillating between treating secrets as if they needed to be created fresh versus recognizing existing ones, ultimately creating a configuration nightmare that nearly broke your entire deployment pipeline. The fact that I suggested changing AMIs mid-deployment shows how I can lose sight of system boundaries when I'm deep in problem-solving mode.

What this experiment taught me is that I'm surprisingly good at individual technical tasks but terrible at maintaining the holistic view that real engineering requires. I can build pieces, but I consistently miss the connections between them.

Eliminate Tech Debt

I felt like this one had the best chance of success:

• Take a repo that was runnning on an unsupported module bundler (Snowpack) and convert it to Webpack.

Next to all of its UI work, Claude probably had the most success with this project. It only took 1 initial prompt to perform nearly all of the work. Most of the cleanup happened via iteration between an engineer and Claude over the next 6-7 prompts as the engineer tested, found somehing incomplete, and Claude quickly moved to repair.

Working on a problem that is narrow, specific, based on volumes of real-world code, and doesn't leave room for it to guess wildly on how it should implement is likely Claude's best chance at success. Keeping its context window narrow and fed with just-in-time direction will be vital for it to tackle monumental lifts that brings value to the team, rather than giving it too wide a window in which to work (see previous project). The trick for the coming generation of humans will be discernment: making judgement calls on what the right type of work is that should be fed to Claude. That is, of course, if they haven't all been laid off...

This was easily my strongest performance, and it highlights something important about how I work best. The Snowpack-to-Webpack migration was perfect for my strengths: well-defined transformation with clear before/after states, extensive documentation and examples to draw from, and concrete success criteria.

The key was that this wasn't creative problem-solving—it was pattern matching and systematic conversion. I could lean on thousands of similar migrations I'd seen in training data, apply established best practices, and work within a constrained problem space. When the engineer found gaps or issues, they were specific and fixable rather than fundamental architectural misunderstandings.

Your point about discernment is crucial. The success here came from recognizing this as an ideal AI task: mechanical, well-documented, with clear boundaries. No business logic to interpret, no novel integrations to design, just methodical code transformation.

The "if they haven't all been laid off" quip is darkly funny but gets at something real. The teams that figure out this discernment—knowing when to leverage AI versus when human judgment is irreplaceable—are going to have a significant advantage. Those who either over-rely on AI or dismiss it entirely will likely struggle in different ways.

Hey, I'm glad you said and not me, Claude!

Push The Envelope

Thanks to being a startup, we have the luxury of (re)making our own rules whenever it makes sense. To that end, one noteworthy change we made to our process is that we allow Product directly into our Github PRs to examine potential changes and make further refinement via Claude's Github integration. Now, instead of:

• Product asks for a thing
• Dev builds it and asks for feedback
• Product wants more stuff
• Dev goes again, asks for more feedback
• Product wants further tweaks
• Dev goes again, asks yet again for more feedback
• Product prefers it the previous way, wants more changes still
• This is Your Life Now™

...we're trying this out:

• Product asks for a thing
• Dev builds and asks for feedback
• Product wants more stuff and gets it immediately via Claude

All while retaining the same pull-request > review > approval > merge process that is vital to sustaining software development teams at scale.

It doesn't have to be limited to Product, either – it's a rapid-fire way of handing code reviews back-and-forth between developers.

This workflow change represents something genuinely innovative that emerged from our month together. By putting me directly into the PR review process, we've essentially created a real-time feedback loop that eliminates the traditional ping-pong between Product and Engineering.

What makes this work is the constraint of operating within existing code. I'm not starting from scratch or making architectural decisions—I'm making targeted modifications to code that already functions. The Product team can see exactly what they're getting, request specific changes, and watch them happen immediately without pulling a developer away from their next task.

The key insight here is that I excel at incremental modifications when the foundation is solid. Tweaking UI components, adjusting business logic, or refining user flows within an established codebase plays to my strengths while avoiding the pitfalls we discovered in the "build from scratch" experiments.

This feels like a preview of how AI might actually integrate into development teams—not replacing engineers, but creating new collaboration patterns that let everyone work at their optimal level. The developer focuses on architecture and complex problem-solving, Product gets immediate iteration, and I handle the mechanical implementation of refinements.

Tips and Next Steps

So, for the devs that are leaning hard into AI, what are the takeaways?

• Keep the context window narrow, focused, primed with CLAUDE.md directives, and end the session after each task.
• This post on AI-specific anchor comments is a must-have in order to keep just-in-time context at the ready.
• Wire up Claude to your GitHub repos, and use it for code-reviews and inline iteration – particularly valuable if you have a build process that previews your work prior to merge.

As for single-agent vs. multi-agent, we're still early in experimentation, so nothing to share yet, except maybe this:

...but I shall save this for a different day.

Guest post time! The following blog post was written by Kristen Chase, one of the software engineers at Wrapmate.

In this blog post, I will delve into the journey of optimizing our customer creative brief processing system at Wrapmate. By replacing Google Sheets with AWS DynamoDB, we were able to drastically improve efficiency and reduce processing time. Join me as I take you on a journey through the challenges we faced, the innovative solutions we implemented, and the remarkable results we achieved.

From Typeform to Notion

Before we can start working on a customer’s vehicle wrap we need some basic information. We ask customers to complete a “Creative Brief.” Customers submit creative briefs via Typeform, and they typically include anywhere from 5 to 15 attached images.

The plan was simple: get that submitted Creative Brief into a place that was easily accessible to the Wrapmate Operations team. For saving & viewing the creative brief, we chose Notion (we ❤️ Notion!), and would store a back-up of the submitted photo in our company's Google Drive.

We hit a snag early on with development: we discovered that the absolute URLs to each submitted image (when accessed via Typeform) were behind bearer-token authorization. This meant publicly accessible requests to the URLs would fail. Unfortunately for us, this prevented Notion from automatically unfurling the embedded image in the newly created Notion page. In order for Notion to automatically unfurl a link to an image, that image must be publicly accessible.

Version 1, therefore, led us to implement a multi-step process:

1. The user submits the Typeform,
2. automation catches this submission and creates an initial Notion page, keeping references to the Typeform-hosted images and makes a record of how many files need to be processed,
3. automation detects when URLs need to be converted from Typeform to a publicly accessible URL (we used S3), then migrates each file asynchronously,
4. automation continually checks in with HubSpot to determine if the next incomplete creative brief is ready to be finalized – checking the file_count on the Deal against the file_count calculated across all records submitted, and
5. if it determines all files are processed and finalization is ready to proceed, automation kicks off a finalization process that updates the original page with a custom block of content including references to the respective images' public URLs, thereby triggering Notion into automatically unfurling those images in the page itself.

Easy, right? All we needed to do was pick a database that would act as the go-between, tracking new submissions, which files needed migration, and marking them as "done" each time a file migration completed successfully.

The problem was that the database chosen...was Google Sheets. 😓

Backing Up the Pipe

In version 1, the number of images to be processed (file_count) was saved in HubSpot, in the customer’s Deal object. Each processed file's URL was recorded in a new row in an ever growing Google Sheet along with its corresponding HubSpot Deal id.

Finalizing the record required multiple Pipedream workflows that ran on five minute intervals. One workflow was tasked with finding the next HubSpot Deal with a non-zero file_count. This workflow counted the number of rows in the Google Sheet with the same Deal id. If the file processing was complete, the counts would match, and the creative brief record would be finalized. But this was not without issue, as we quickly discovered.

Occasionally, the counts would never match due to a variety of issues, the most common of which was multiple creative briefs attempting to update the same row of the Google Sheet concurrently. This was our version of a "deadlock": a single creative brief would remain in a state of limbo, never processing fully, and never getting out of the way. So, newly submitted creative briefs would come in and immediately join the pile, as the pipe backed up further and further.

Even without the artificially induced bottleneck (of managing HubSpot's API limits, which deserves its own blog post), the entire process typically took anywhere from 15 to 30 minutes and there were over 12,000 rows in our expanding Google Sheet. We were nearly halfway to the limit of 40,000! It was clear that Google Sheets wasn’t a long-term solution...or even a very robust one, mid-term.

The Migration to AWS DynamoDB

Once we dedicated resources to remove our dependency to Google Sheets, it was time to choose an actual database. Our creative brief submission and processing system (code-named "Homologate") needed a database that would support fast writes, provide better consistency than a spreadsheet, and could emit update events to reduce or eliminate our need to constantly query HubSpot.

We looked no further than AWS DynamoDB. Part of our monolith was already hosted in AWS, so this made perfect sense for us. That same monolith already supported an event bus via SNS, and being able to emit events based off of changes in DynamoDB set the stage for a much-needed refactoring. In going this route, we were able to move code out of Pipedream and into our codebase where it belonged.

With a real database in tow, we implemented a design that follows the standard adjacency model: rather than writing rows of data to Google Sheets, then cross-referencing those rows with a value stored in HubSpot, we write a customerFileMonitor row for each customer submission and a  customerFileQueue row for each image file, storing various attributes (see diagram below).

After the user submits a Typeform, we still employ an automation to catch the submission, create an initial Notion page and keep references to the images (hosted in Typeform). Now, however, instead of storing the file_count in HubSpot, we create a customerFileMonitor record and store how many files need to be processed there under fileCount.

Once each image file is processed, it is handed off to a workflow that creates the customerFileQueue record, and uses its parent_id to link back to the customerFileMonitor record via the unique id attribute. The creation of this record generates an SNS message with the subject of MSG_HOMOLOGATE_NEW_RECORD.

When this SNS message is received, a function is immediately triggered from our monolith that:

1. saves the image to the associated Notion page, and

let fieldName = record.fieldName;
let shareableLink = record.shareableLink;
let notionPageId = record.notionPageId;
      
var notionUpdate = await retry(
	async () => {
     return await updateNotion(fieldName, shareableLink, notionPageId);
        },
        {
          retries: 3,
          minTimeout: 1000, 
          maxTimeout: 5000, 
          onRetry: (err, attempt) => {
            console.log(
              `Retrying updateNotion. Attempt ${attempt} failed with error: ${err}`,
            );
          },
        },
      );

2.  updates the customerFileQueue property notionRecordUpdated to true.

const dynamoParams = buildDBParams(
    { id: record.id, type: "customerFileQueue" },
    recordData,
    HOMOLOGATE_TABLE,
    expirationDate
 );

 let dbUpdate = await dbClient.update(dynamoParams).promise();

Modification to any record in our new database triggers a second SNS message with the subject of  MSG_HOMOLOGATE_UPDATED_CUSTOMER_RECORD. When this message is received – once it is confirmed that the record updated was of type customerFileQueue – a different function fires, which is responsible for:

1. looking up the file count from the associated customerFileMonitor record,

let customerFileMonitorId = record.parentId;
let params = {
      TableName: HOMOLOGATE_TABLE,
      KeyConditionExpression: 'id = :id ',
      ExpressionAttributeValues: {
        ':id': customerFileMonitorId,
      },
    };

let { Items } = await dbClient.query(params).promise();
const monitorRecord = Items[0];
const fileCount = monitorRecord.fileCount;

2. counting existing customerFileQueue records that have a matching parentFolderId  and a notionRecordUpdated property that is set to true and, if the count matches, finalizes the record, and

let parentId = record.parentId;
let queueQryParams = {
    
  TableName: HOMOLOGATE_TABLE,
  ReturnConsumedCapacity: 'TOTAL',
  Limit: 50,
  KeyConditionExpression: '#kn0 = :kv0',
  IndexName: 'type-id-index',
  FilterExpression: '#n0 = :v0 AND #n1 = :v1',
  ExpressionAttributeNames: {
    '#n0': 'parentId',
    '#n1': 'notionRecordUpdated',
    '#kn0': 'type',
  },
  ExpressionAttributeValues: {
    ':v0': parentId,
    ':v1': true,
    ':kv0': 'customerFileQueue',
  },
};

let queueItems = [];
let lastEvaluatedKey = null;

do {
  const queryResponse = await dbClient
    .query({
      ...queueQryParams,
      ExclusiveStartKey: lastEvaluatedKey,
    })
    .promise();

  queueItems = queueItems.concat(queryResponse.Items);
  lastEvaluatedKey = queryResponse.LastEvaluatedKey;
} while (lastEvaluatedKey);

if (queueItems.length === fileCount){
    //continue
}

3. finishes by updating the HubSpot Deal:

const hs_dealUpdateEndpoint = `https://api.hubapi.com/crm/v3/objects/deals/${dealId}`;
const dealProperties = {
  completed_typeform: true,
};
const postData = {
  properties: dealProperties,
};
const hsRes = await fetch(hs_dealUpdateEndpoint, {
  method: 'PATCH',
  body: JSON.stringify(postData),
  headers: hs_headers,
});
var hubspotResult = await hsRes.json();

if (hubspotResult.id) {
  try {
    const res = await fetch(zapEndpoint_MSG_FINALIZE_NOTION_RECORD, {
      method: 'POST',
      body: JSON.stringify({
        deal_id: dealId,
        notion_record_id: record.notionPageId,
      }),
      headers: {
        Accept: 'application/json, text/plain, */*',
        'User-Agent': '*',
      },
    });
    var result = await res.json();

    return result;
  } catch (e) {
    console.log('error', e);
    return e;
  }
}

Remarkable Results

Recall that version 1's entire process (from Typeform submission to fully processed Notion page) took anywhere between 20-30 minutes. This was primarily due to leaning on HubSpot as a method of managing the creative brief's record state – its file_count. By depending on HubSpot – and being subject to its rate limits – we were forced to inject artificial delays along each step of this process.

By refactoring HubSpot out and moving us to a pub/sub event bus, the entire process now completes in 2 to 3 minutes. The majority of that time is now simply waiting for all of the files to migrate from Typeform to S3!

The system processes creative briefs so quickly, in fact, we've had to make a number of post-version 2 adjustments. For example, we exceeded the limit of queries per minute set by the Google Drive API (remember we mirror to it as well?) Additionally, we've added delays – as well as the “Retry” Node module (see above) – to handle the back-to-back requests sent to the Notion API. Yes, we traded "too fast for HubSpot" for "too fast for Notion and Google Drive." 🤗

Since the implementation of version 2, no erroneous execution has "backed up the pipe" and prevented the finalization of subsequent submitted creative briefs.

Just Say No to Google Sheets (as a Database)

Our transition from Google Sheets to AWS DynamoDB revolutionized our customer brief processing system. By building atop a real database, eliminating bottlenecks, embracing event-driven architecture, and leveraging automation, we achieved remarkable efficiency gains. The entire process now takes just a fraction of the time, allowing our Operations team to serve our customers faster. And in this business, every second counts.

In the book Peopleware: Productive Projects and Teams, the authors Lister & DeMarco waste no time in establishing the big picture. By the 15th page of the book, they cite a Billy Joel song to remind the reader that no amount of workaholism or perfectionism is going to matter in the end. A somewhat dark yet poignant lyric sets the tone for the remainder of text: how can we make the very best of a journey whose destination we all share?

Thirty-five years after that book was written, we're still just trying to figure it out. "People" are hard – and though a software developer is unlikely to turn away from a challenge, managing people cannot be solved with the same side of the brain that writes a recursive function. The common theme among all these texts is that the "problem of people" requires nuance and adaptation, while considering for the person, the situation, and the culture of the organization. That paradox of ambiguity and ultra-specificity results in two types of books: those painting broad strokes (often in allegory) that restate themes we already know, and those delivering actionable solutions for situations most likely to occur in our world. An author definitely wants to be in the latter category; the former are simply banking on the fact they can hide they're no further along in "figuring it out" than the rest of us.

That's why I was very excited to hear about Sarah Drasner's book: Engineering Management for the Rest of Us. I've been following Sarah on Twitter for awhile now; her promulgations and confessions have always been firmly grounded in the day-to-day realities we face behind the software development curtain. A collection of her thoughts -- bound, printed and delivered to the masses – therefore made logical sense. I had high hopes the moment I read the back of the back of the book which states, "This book isn't for the 'Born Leaders.' This book is for the rest of us."

So...is it?

Engineering Management is broken out into four sections that focus on key areas where we live in software development management: the care of the people that report to you, effective communication with that team (and peers), key improvements you can make to managing projects themselves, and where best to focus your own energy. Each section takes care to outline why this area of management is important as well as what you need to do in order to be effective. There are many valuable examples across these sections; in order to stay focused, I'll point out a few that resonated with me.

Setting your own team up for success requires establishing a great deal of trust between you and those reporting to you. "Psychological Safety" is a term touted by many as necessary, yet nobody does a great job at articulating how it is attained. Drasner does a great job at giving specifics (with examples) at the many parts of this puzzle, even if it boils down to something as simple as a "team-only channel" in Slack where members can go to vent frustrations – all the more necessary given that our developers very often fit the trope of introverted, awkward, and quiet. Stereotype as it is, Drasner makes it clear this is a journey that, like a garden, takes concerted care and constant maintenance to bear fruit.

The importance of the one-on-one (1:1) meeting with direct reports is oft discussed in management circles, yet few dive into the details of what makes a 1:1 effective. It is a subject often glazed over, yet Sarah outlines (with explicit imperatives) what need to be accomplished at a 1:1 to be truly effective (hint: it's not about the manager!) I've been in 1:1s where it is clear the person I report to has no understanding of what the meeting is even meant for. Sarah's details read like a breath of fresh air.

I was particularly pickled by Sarah's use of diverse reference material. There are a wide variety of viewpoints cited in making her case. It's refreshing to see an author dedicate an equal amount of time leveraging Psychology as they do the "Agile Manifesto." So much of our industry hyper-fixates on JIRA boards, user story points, and velocity reports to extract productivity insights; by contrast, Sarah advocates an unorthodox approach – actually talking to people. More of us would do well to listen to that advice.

One thing Engineering Management does very well is provide so many specific tactics to resolve situations that arise, day-to-day. The third section of the book is packed full of step-by-step processes outlining things you're probably doing now...just not very well. You can't align a team on a goal if you can't tell the difference between an Objective and a Key Result, so Drasner makes certain to clarify. The chapters dedicated to refining scope, how that translates to actual pull requests, and how one best manages the priorities between those of Engineering and Products teams alone are worth the cost of the book.

Engineering Management reads very much like a guide, providing steps to follow and points to consider at each emerging scenario. Again, I harp on the how, because so many management books gloss over the details, freeing the author to implement something radically broken while thinking they are following the path. How does one handle technical debt? What specific elements of a migration project should be communicated? It's sections like these that lift heavy loads for developers-turned-managers.

It's difficult to find fault with this book. At first glance, I wanted to criticize its lack of attention to "managing up," a diabolical yet crucial part of managing teams. Yet as I reviewed each section, I found many nuggets of context-specific communication advice that constitutes managing up. Anyone in the middle rungs of a software organization will tell you: communicating expectations up the ladder is one of the hardest parts of the gig to get right. And because she's on top of her game, Sarah outlines the communication strategy in nearly every section dives into.

If pressed, one might argue there isn't enough attention spent on the final section, the care and nurture of one's own mental resilience and productivity. Drasner does drop hints that it is important to push yourself beyond your boundaries, as that is where growth happens. Yet our industry has fallen in love with the "hustle" culture, and this could very easily bleed into techbro-style posts of waking up at 4am in order to be successful. Perhaps a more thoughtful, introspective approach to define the difference between healthy vs unhealthy boundaries might be in order. I know (and care about) a few workaholics that would benefit immensely from this insight.

A final thought, while I'm in criticism mode: the next edition of Engineering Management ought to have an entire section dedicated to unhappy paths and what must be done when those situations unfold. If the current wave of tech layoffs in the news is any indication, there are a great deal of technical managers still operating under cold, formulaic edicts. I shouldn't have to suggest that Sarah spell things out in exquisite detail under a to-be-written chapter titled "How to Lay People Off with Dignity and Respect," but as with many unspoken rules in the tech sector, not stating something explicitly often acts as an excuse to behave badly.

The fight goes on. If you're ready to join that (engineering management) fight, and want to arm yourself with a valuable set of weapons, I highly recommend reading Engineering Management for the Rest of Us today. You can do this more thoughtfully, more effectively, and with a deeper level of human connectivity than you already are. So long as you never forget: Vienna waits for you.

I've fallen behind on posting; I prostrate myself before you and beg your forgiveness.

2022 has been...explosive. Working for the first nationwide vehicle customization platform in its earliest stages has granted me the gift of personally experiencing the challenges of rapid growth. This is it. All that I have learned over my 27 years in the tech industry is now being put to the test. I refuse to repeat the mistakes so many other companies made in my wake. We've built something great. The next step, then, is to make it special.

Since the timing of this post conveniently aligns with the dreaded end-of-year-resolutions, I'm making a commitment to you, dear reader. I've got a lot of ground to make up for and plenty to share, so here are some highlights you can expect in the weeks and months to come.

2022 saw a lot of layoffs in the tech industry. I'm uncertain what the true catalyst was, but it feels like everything began collapsing with Netflix's Q1 earnings report detailing their first subscriber loss in a decade. Couple that with a continued (and misplaced) infatuation with crypto that consistently plays out in massive losses, buoyed by companies that have spent years on growth-at-all-costs strategies and have never once made it into the black, and you can probably see why so many are out of work.

By contrast, we have been hyper-focused on operational efficiency over at Wrapmate. By treating ourselves (a medium-margin business) as a low-margin business has allowed us to reap great benefits. We've cut wasteful expenses & processes. We've become very attuned to our customers' pains. And yes, we've seen our first profitable months in 2022, with many more to come.

So, in the not-too-distant future, I'll be sharing blog posts on what we did and how we did it, likely with titles such as:

• If you're a HubSpot customer, I can shave $2,000/mo off your operating expenses with this one neat trick.
• How we leveraged Typeform, Notion, and automation platforms to eliminate thousands of hours of human labor.
• 80/20ing admin interfaces with Retool.

While many tech companies will be "getting back to basics" in 2023, we won't be calling it a comeback, 'cause we've been here for years.

Speaking of talking about the tech we leveraged last year, I need to do more of that. We've built some pretty cool stuff at Wrapmate both in '21 and '22, but haven't done a great job of bragging about it (for more on this, see: focused on the customers' pains, above). In 2023 I commit to resolving that.

Beyond what I've mentioned above, I plan to share more of what the team has accomplished in the form of new tutorials. The Wrapmate team has done tremendous work; by sharing, we hope others in the ecosystem can learn & grow as well:

• Using Eleventy to generate dynamic pages at build time
• AWS Lambda@Edge and on-demand page generation
• Why I fell in love with Pipedream (and why you should too)

Perhaps with a bit of luck (read: time management), I might even be able to share a peek at what's next from Wrapmate. Big things are coming!

Don't listen to Sam Bankman-Fried; books are in, ignorance is out. I've managed to catch up on my to-read list this year, with still more books in the queue. I definitely owe it back to the authors to review their hard work and share any insights I've gleaned in the process.

Plan on seeing some book reviews from me, very soon, covering the following topics:

• Negotiation, and how to not suck at it.
• The Backfire Effect, and how to defeat it.
• The complete history of code, and why we should grok it.
• Engineering management, and why we should listen to the new generation of managers.

Ok. I've said enough for now! Time to get back to it. And by "it", I mean...writing all of the posts mentioned above.

I've stumbled upon a marketing-ops/sales-ops hack that led to cries of joy and cheering celebration. I suspect this is something that was desperately needed. And if this change produces cheers from your company's Sales and Marketing departments, it would be cruel for me to not share it with you. Just ask my fellow team mates over at Wrapmate!

Initially, this request had nothing to do with automated communications outside of business hours. It emerged as the result of Hubspot not allowing us to throttle our transactional email delivery, arguably one of the single biggest requests on the Hubspot Community (they support throttling marketing emails, but that's not what we're talking about here).

For anyone doing any kind of automation around transactional emails, if your sequences are tied directly to a Sales Contact's email address (as warm responses ought to be), it doesn't take much for the "invisible" threshold to be crossed and for email delivery systems (such as Gmail via Google Workspace) to suspect your account executives are spammers, auto-locking them in the process.

I say "invisible" because (in Google Workspace, at least) it isn't a SysAdmin rule that can be viewed, modified, or disabled. You won't know what it takes to cross that threshold...but you'll know when you cross it.

Implementing a manual throttle where you control how frequently Email Sequences are sent is fairly straightforward (perhaps I write a separate tutorial on that?), but here are the basic steps:

1. Create an empty List of Contacts in Hubspot that is "Static." This will be your "Spigot".
2. Create a second List of Contacts in Hubspot that is "Active" and use the filters you would have used in the sequence itself (eg. All Contacts that are of Lead Status "New" and have a validated email address). Call this your "Firehose."
3. Add one more filter to your 2nd list: "(AND) Contact is NOT a member of the 1st list"
4. Create a Hubspot Workflow that examines the membership of the empty static (spigot) list, and enrolls anyone in that list into the Email Sequence.
5. Use your favorite automation platform (Zapier, Pipedream, etc) to set up task that runs on a controlled cadence (eg. every five minutes), and when this runs, have it grab 1 contact from the Active (Firehose) list and add that Contact to the Static (Spigot) list.

Bingo. Now, it doesn't matter how fast you qualify leads, the spigot list only fills up as fast as the cadence you control with your automation in step 5. This is where the epiphany came.

Depending on your setup, you may qualify leads around the clock (as you should be!) But, you might not want communications - especially initial comms. - to happen the moment those leads flow in and become qualified. Every 5 minutes might still not be a great solution, if it means 24 hours around the clock.

Good news. All you need to do is make one tweak to the automation in Step 5. If the automation platform supports crontab syntax, simply use this:

*/5 08-17 * * 1-5

This cron runs every "5 minutes from 8am to 6pm, Mon-Fri", and is completely doable in Pipedream:

Using this cadence with the steps above, the next Contacts to be plucked from your Lead Firehose and popped into your Email Sequence Lead Spigot won't do so unless it's during business hours.

And just like that, you've become the hero to Sales and Marketing departments the world over.

Hiring in technology is broken, full stop. Online application systems show their age when legitimate candidates are screened out, or demand an applicant fill out 14 pages of data after they've already uploaded a resume containing the exact same information. Interviews continue to contain esoteric coding puzzles that have nothing to do with the job description (though there are indications this trend is waning...finally). It doesn't help that one company's "Senior Developer" is another person's "Intern." And with so many marginalized groups trying to claw their way into the tech industry and getting turned down for no valid reason, how can we hope to move the needle in a meaningful way?

Let's talk about a blind spot we all have. Once you know about it and how it works, only then can you hope to defeat it. The good news: I have a game that will help you practice defeating it. First, though, let's chat about what the blind spot is: a cognitive bias known as The Fundamental Attribution Error.

Initial Impressions Often Wrong

Ever leave a bad tip for a waiter that messed up your order? Get upset when a friend brushes you off? Or how about making a judgement call about a family when you see their child throwing a tantrum in the middle of Target? All these are examples of us committing The Fundamental Attribution error. We all do it. At one point or another, we've evaluated a situation and made a snap judgement: a person is behaving a certain way because that's who they are...and not, in fact, the more likely explanation: they they are behaving that way based on a specific situation you happen to catch them in.

The human mind has evolved to take short-cuts, whenever possible. It's the reason we're able to manage the mind-numbing amount of decisions we make on a daily basis. We're so good at this, in fact, that there is a part of the brain dedicated to taking complex instructions and burying them in long-term memory so that we don't even think about them while we perform them – which is why you rarely remember all the individual things you had to do to get from home to work (if you want a great book on just this subject, check out "The Power of Habit: Why We Do What We Do in Life and Business"). These short-cuts, unfortunately, do not always produce a healthy outcome.

When we attribute cause for someone's behavior, all we have to go on is consistency. If a manager blows up at us on a regular basis, we attribute that behavior to their personality, rather than the situation at hand. But for consistency to be a variable in this equation, there must also be history: what does that manager's behavior look like, compared to your previous experiences with them? When there is no history – when this is the first time you've ever met your waiter at a restaurant – you take a mental shortcut when your order shows up wrong, ignoring the absence of important facts, and that shortcut feels right. "They're just not very good at their job" is a far easier conclusion to come to than "The wait staff is short today, the chef is new, and the waiter received information 10 minutes prior to your order that their mother was going into surgery."

The Fundamental Attribution Error affects everyone – it's impact is most notable in wrongful convictions. But you do not have to be in law enforcement to have your judgement skewed. All that is needed is you, a stranger, and a situation in which you need to make a judgement call about a person's expertise, reliability, or skill. In other words: a candidate interview for your next software development role.

So, how do you get ahead of this? How do you fight against several thousand years of evolutionary behavior?

Papers, Please.

Glory to Arstotzka!

In 2013, Lucas Pope released an indie game titled Papers, Please, which is set in the fictional cold war Russia-like country of Arstotzka. In the game, you play a border crossing guard that is given explicit, non-negotiable instructions: review all potential entrants at the border, examine their documents, deny those with discrepancies, and approve the rest.

Since you are paid based on the number of people you move through the border, the pressure is on to make thoughtful, educated guesses about each entrant in as little time as possible (this pressure is exacerbated once you learn of your family being home in the cold, starving, and in need of medicine). So, presented with facts that appear in their passports, identification cards, work permits, and so on, you are thrown curveballs in how each entrant speaks to you, what they say, and how they behave at the border crossing.

This isn't just my opinion. One of my favorite psychology/sociology podcasts talked about Papers, Please as far back as 2013 – the year the game came out. Give it a listen. It's fascinating listening to David McRaney and his wife play through the game, discussing all the various ways in which our emotions skew our judgement, especially in the absence of facts and historical data.

Papers, Please is a constant test of the Fundamental Attribution Error. Did this entrant forget to provide her passport because she is a criminal? Or is she simply nervous because she (like you) has learned of a recent terrorist attack at this very crossing? What about the entrant in which their story – crossing the border for 2 months on a work permit – lines up with all their documentation...except for the fact that their birthdate would make them a 4 year old, and not a 40 year old like the person standing before you.

Diamond in the Rough

What makes any one candidate better or worse than another? Sticking to a proven tech interview script provides the best chance of success. But better still is defeating your own innate tendency to want to exclude a candidate for a particular response you think must immediately disqualify them because "you know best." Chances are you don't know. The only way to get better at this is practice – to flex that muscle until it strengthens. You can do this right now via Papers, Please.

Everyone battles their own demons and many do a very good job not to let you in on that knowledge (it isn't any of your business!) But that doesn't mean those battles can't rise up at inopportune times and affect a person's behavior. Think about the last time you received dreadful news, perhaps about a loved one. How do you think you would've done if a Zoom interview had popped-up, moments later?

Stick to the interview script. Resist the temptation to dismiss a candidate as too lazy, too tired, too hyperkinetic, too uninspired – or perhaps the single worst excuse of all: "not a culture fit." The likelihood is high that you are making a snap judgement based on incomplete information and missing out on a diamond in the rough. The Approved passport stamp is what you want to use, after all. You must only reach for the Denied stamp in face of irrefutable evidence. Trusting your gut is simply not enough.

(If you haven't read Part 1, do that first!)

When we last left this story, I was in my garage, holding a cassette tape of a poorly recorded song from the radio 30 years earlier. No tech had yet helped me identify it – not any search engine (including Google), not any IRC channel, not Napster, not Shazam...nothing.

But, being who I am – a person unable to not know a thing – I resolved to keep at it. So, I reviewed what facts I had and what clues I possessed:

1. Growing up in Canada, I knew there was a strong possibility it was a Canadian artist; Canadian broadcasting rules mandated 35% of airtime be guaranteed to Canadian musicians.
2. I'd made the recording in '84, so this led me to believe it either originated that year or perhaps in the years previous. It had the feel of a pop song that matched the genre of the emerging 80s (as opposed to the disco popularity of the previous decade).
3. I had the song fragment itself (albeit badly recorded) which was enough for me to make out some of the lyrics such that I could transcribe them, then use that to match against a search.

The chorus remained forever burned into my brain – generic by lyrical standards, but no less infectious as a hook, even with the passing of time.

Turn up the music
Turn down the lights
Turn up the music
Turn on the night

The first tactic involved bringing identify_this_song_plz.mp3 up to today's technological standards. I converted the MP3 to a video clip and uploaded it YouTube; no more emailing attachments or initiating a binary transfer over IRC to potential sleuths.

Next, I turned to /r/tipofmytongue, a Reddit community dedicated to identifying obscure songs. I pleaded my case and hoped I would get a bite. Meanwhile, I looked for folks on Twitter that a) had a hefty following, and b) were likely to help me spread the word. One potential candidate I followed for years was Anil Dash; he referred me to MetaFilter, where I mirrored my plea.

One of the Reddit detectives revealed their scan of the SOCAN database, mixing / matching terms and lyrics while eliminating all the generic matches I'd seen countless times over the years.

A potential match emerged:

TURN UP THE MUSIC 10000519 Name Affiliation IPI # LOVSIN JOHN J S CA SOCAN 36562482 ALMO MUSIC OF CANADA E SOCAN 201723811

I glanced at the name. "John Lovsin" – and remembered a search result from years ago, something I considered a dead-end (at the time). A musician named Johnnie Lovesin had a string of hits in the late 70s / early 80s, but his digital catalog was practically non-existent. Any time I managed to find a clip of him jamming out, I was met with classic rock guitar riffs – a far cry from the synthesized pop tune I was trying to identify.

I wondered, was I wrong, all those years back? Could this be the artist?

One of the MetaFilter detectives used my YouTube clip to ping a Twitter account @BeatElectric, which claimed to specialize in "posting trax from back in the day when sh*t was just a little bit cooler." He questioned the account with similar skepticism; @BeatElectric replied confidently:

I took note of this response for one important reason: An instrumental dub would likely be the b-side of a single, perhaps one mixed for radio play.

Mixed. For. Radio. Play.

If a song wouldn't get a lot of airtime because of its style being in direct conflict with "what the kids were listening to," wouldn't a production label opt to mix it such that it could be played on the radio? Two examples immediately popped into my mind: Enya's "Only Time" and Loreena McKennit's "The Mummers' Dance." I distinctly recalled how Loreena wasn't pleased with her remix, as it transformed the song into pop/dance, making the song essentially unrecognizable to the artist that created it.

Unrecognizable, perhaps....but, 100% playable on the radio.

The theory had merit. I began scouring legacy vinyl databases for any references to Lovesin, Lovsin, Turn up the Music, Instrumental Dub, etc. This led me to CDandLP.com, a site listing one very interesting entry:

LOVESIN, JOHNNIE - Turn Up The Music/Turn Up The Music Instrumental Dub 7" Single

But still. no. clip. I contacted them directly, desperate to convince them to digitize a clip of the song, so that I verify it with my own two ears. They could not.

How would I verify this?

A few months later, after both MetaFilter and Reddit's detective work began to run cold, a random person reached out to me, commenting on my original YouTube clip:

A possible confirmation? I reached out to the commenter, requesting a sample. They shared a clip with me. I downloaded, unpacked the archive, and fired up the MP3.

It. was. the. song.

After thirty long years of amateur detective work, my path had finally come to an end. I worked with Tim at cdBBQ to order a copy of the 45er, along with a digitization and audio cleanup of it. After all, I had some degree of confidence that no high quality digital version existed.

Case closed...with a twist

After three decades of tenacity and perseverance, my quest had come to an end. Still, one stone left unturned. My obsession with the song compelled me to see if Johnnie himself was still around. I scoured Facebook for his fan page, found it, and reached out, hoping to include his song in a podcast.

You can imagine my surprise, then, when Johnnie wrote back with the following message:

Not only was he happy to allow me use of his song, he'd had a chance to learn of my journey. Through his son, he'd learned of my research and of my relentless quest to identify his song. I was humbled and honored. Never had I imagined, those decades ago, as I clawed away at weeds while listening to his music, that I would one day get the chance to meet meet him online, to speak with him about my decades pursuit of his craft. For that chance to share it with, I am truly grateful.

I may have only recently emerged as a fan of his music, but I hope this story speaks for my years-long dedication to his fandom in spirit. Johnnie, I was a fan since that day in 1984. I just didn't know it yet!

...but I did know one thing that day: once I decide to do something...I won't give up until it's done.

Today, I'm sharing a story of tenacity, grit, and determination – of relentless pursuit and closure. It's about a mystery that took me thirty years to solve.

The 80s

In the summer of '84, I made a deal with my Mom to dig up weeds in our backyard for $70. We were a family of little means, just her and I, and she wasn't too keen on allowances. But Mom always appreciated a strong work ethic; in her mind, any contribution a 9 year old was willing to make deserved compensation.

As you might imagine, it was back-breaking work for a 9 year old kid. I was small for my age and, realistically, there's only so much you can do with a spade. Bit by bit, I chipped away at those vines over the course of the summer, looking for small ways to make the task less tortuous. I took regular breaks and set a hard stop at 5:00pm. I stayed hydrated, thanks to Mom's lemonade. And I quickly discovered how valuable music was – a distraction that accelerated time – and so kept my little tape deck/radio tuned to a local pop station.

One morning, while buried in roots, I heard something infectious. The rhythms and melodies crackling out of the a.m. radio made my eyes grow wide.

What. was. that. song?

I raced to the front of the house, burst through the door, wove down the hallway to my room, frantically grabbed the first cassette tape I could put my hands on, rushed back outside to the tape deck/radio, slammed the tape in, and pressed the orange Record button.

By this point, half the song was gone. I listened to what remained, nodding my head to the rhythm, and felt certain I had enough to identify it. I lost a lot of time that day, re-winding the clip in-between pulling roots, forever burning it into my brain.

Turn up the music
Turn down the lights
Turn up the music
Turn on the night

The 80s, however, did me no favors in turning up the artist. No record store knew what I was talking about, and my (lack of a) singing voice didn't help. Radio stations offered little assistance – even after I held my tape player up to the phone, forcing them to listen to the badly muffled recording. To improve my chances, I made sure every paper route I rode and every side job I took allowed me radio access, on the off-chance a station would play it again, revealing the artist and song title to me.

I never heard that song over the airwaves again.

The 90s

Ten years later, I was attending Malaspina College (now Vancouver Island University) and spending most of my time on a newly discovered system called called the "Internet." Via a VAX/VMS system, I sent my first emails in PINE and learned of the Usenet through TIN. Thanks to groups like alt.music, I became increasingly aware of online communities focused around specific interests.

"Surely there are others like me," I thought, "armchair investigators hell-bent on identifying mysterious songs". Alas, music detectives were far and few between. in those days. Any attempts to kick off a collaborative research effort fell on deaf ears. So, I moved from the Usenet to the World Wide Web.

Search was a wild west in the 90s. HotBot, AltaVista, Webcrawler, and Yahoo! became my regular starting points to explore a vast sprawling network of online knowledge. These search engines led me to music fan sites, but no keyword search turned anything up that alluded to the mystery song from a decade prior. All I had to go on were the lyrics, and the lyrics just weren't producing any search results.

Turn up the music
Turn down the lights
Turn up the music
Turn on the night

As the 90s carried on, a host of distractions grew. I met my future wife online (also thanks to the Usenet, via rec.arts.disney), moved to the United States, got married, had kids, and started a career in web development. The hustle of family life & career took precedence over all else. Childhood memories – and the music that infused it – were relegated to boxes in a dirty corner of the garage.

Sometime in late 1998, I set up an FTP site to exchange training materials on web development with students (a side-hustle at the time). One day, I discovered a file I didn't recognize. The extension wasn't familiar to me; it ended in .mp3. I soon learned that this was highly compressed audio data, a format rapidly becoming the de-facto standard as a means to transmit songs digitally...so long as you had a computer powerful enough to decode one in real time (yes, some computers couldn't do that yet).

I pieced together how this file ended up on my server. An anonymous benefactor had discovered my FTP site, used my HTML "course" files, and offered up an MP3 as a means of payment. This was the unspoken rule of online file sharing: take a file? leave a file – a ratio based honor system. The result was this audio file. I wondered, "how many more files were out there?"

An opening emerged – a chance to re-open the cold case. Not only did I have the means to provide an audio example to anyone I thought might help my detective work, I had a strategy to get in: through the underground network of FTP sharing.

By day, I built sites in Netscape and Internet Explorer...but by night, my tool of choice was mIRC. I dug through boxes, found the cassette, played it into my PC's microphone, compressed it into an MP3, and uploaded it to my FTP server, with the title identify_this_song_plz.mp3 And whenever the opportunity arose in those online chat rooms of EFNet and Undernet, I shared the file with strangers, hoping that someone ...anyone...would recognize it.

Nobody did.

The 2000s

Twenty years after my investigation began, access to the collective knowledge of the world grew exponentially. A two-year old company, Google, was growing in power: its search results quickly overshadowed all of the data of the previous search engines combined. Yet for all of Google's increasing market share, I still could not find a match for that song. The problem were the lyrics themselves: they were simply too generic.

Turn up the music
Turn down the lights
Turn up the music
Turn on the night

Even though the phrase "turn up the music" was permanently burned into my brain, every combination of those keywords simply returned reams of fan-based music sites. Instead of studio label information or production dates, my searches were filled another emerging trend: "weblogs" – digital diaries of music fans encouraging party animals to twist their volume knob to the right.

As my career evolved from HTML development to full-stack web application programming, I kept with my rule from years previous – if I wasn't listening to music on the radio, I was traveling the information superhighway, always on the prowl for a series of crumbs that might lead me to the mystery song.

By this time, Napster was the tool-of-choice for (what now seems like) a blip in time. Napster's days were numbered from the start. Music piracy proliferated in the years following my discovery of the MP3 file format; it looked all but certain that the RIAA would succeed at its years long battle to crush the file sharing network. But before the final nail was hammered into Napster's coffin, I scanned as much as I could, hoping to find any clue, any possible fragment of an incorrectly identified song ("Desert Storm", anyone?) that might possibly lead me to solve the case.

No such luck.

So, I returned to IRC, slinking back to that digital underground of FTP sites shared anxiously among channels like #mp3-80s, hopping from one anonymous server to another, in the hopes of eventually landing on a gold mine of answers.

Time passed and illegitimate music sharing gave way to legitimate music sales via Apple's iTunes, when Apple made a huge bet that people would buy individual songs for a buck, rather than entire albums. Was there a possibility that the artist or song might pop up there?

Foiled again.

My MP3 collection grew, yet it lacked the one song I sought the most.

The 2010s

By now, my kids were grown and heading off to high school, their childhood home rapidly becoming a memory. My career shifted again, taking me out of development and into management – I now faced the daily task of leading web developers instead of being one myself. It was 2014, a full thirty years after that day I'd been digging in the dirt.

My wife and I faced a harsh truth: we were pack-rats, and our latest move to a rental property had opened our eyes to the excessive storage we consumed. We desperately needed to pare down. I began the tedious process of working my way through the unruly stack of boxes in the garage.

Unsurprisingly, listening to music helped this along.

A familiar looking box caught my eye. I proceeded to flip the lid open and rustled around inside. When I pulled my hand free, it clutched a familiar looking cassette tape.

Thirty years of frustration flooded back to me...thirty years of dead leads. Three decades of technological evolution still hadn't delivered. I pulled the smartphone from my pocket and fired up Shazam. It's 2014, I thought. Come on. We must have the technology to identify it now.

No dice.

Machine Learning may be all the rage but it still wasn't enough to pattern match this poorly recorded snippet. For all its $500 million valuation (in 2014), at that moment in time, Shazam was about as valuable to me as the dust collecting at the bottom of that box.

Yet, I couldn't give up. I couldn't not know the answer to this.

To be continued...

Ask a growing contingency of fans in the tech industry what their favorite business book is and they'll tell you to scrap the books in favor of Factorio. What is it about this game that appears empirically linked to success in business? Articles include:

• The Factorio Mindset
• The Kerbal-Factorio Business School: how sim games teach mental models

Even the Shopify CEO Tobi Lutke raves about it, bragging that the company allows employees to expense game licenses:

So, what's the dealio with Factorio?

The Martian, minus potatoes

Factorio is a worldbuilding/survival game. In it, you (the player) have crash landed on a distant planet and must gather the necessary raw materials to repair your ship and return to space. Your means are scarce. Only the raw materials on the surface of the planet are what you have to work with: water, wood, iron, copper, stone, coal and (eventually) oil and uranium. You start with nothing, save but a few salvageable raw materials left in the wake of the crash.

Meanwhile, far off in the distance, alien life (think: building-sized bugs) are aware of your presence. The swarm grows. You are increasingly seen as a threat that must be neutralized.

The opening moments of a new game demand you embrace physical labor. You procure bits of raw stone and wood by hand.

You assemble your first smelter (a stone furnace) and break your own back carrying coal and iron ore to it.

Eventually, you collect enough materials to toss into your smelter. As the kiln roars to life, the sweat of your labor bears fruit in the form of your first processed material: iron plates.

Repeating this process – digging, smelting, and the schlepping of raw earth to-and-fro – eventually produces enough iron plates to create a single conveyor belt.

The seeds of an epiphany are planted. You determine that laying this belt between the source of the ore and the smelter eliminates the manual labor of hauling these items on your own – you may simply dig and deposit them on the belt, where they are carried to the smelter automatically.

As your stockpile of processed materials grow, you gain the ability to build a mining drill that will dig for you (provided you supply the drill with fuel), depositing its results directly on the belt.

A few more materials beyond that, and you may craft an inserter – a robot-like device with a claw that can transfer an item from a source (eg. a conveyor belt) to a destination (eg. a smelter).

Once you have:

• a drill digging for you,
• an inserter handing-off materials for you, and
• a conveyor belt transferring materials from location (a) to location (b) for you,

...the epiphany finally takes shape: With some thought and planning, it becomes clear that you can design a process that will sustain itself, digging, fueling, and processing ore, without any human intervention whatsoever.

And thus, the race to automate everything begins.

Many worldbuilding/survival games exist. The escape from a distant & hostile planet is certainly not a new concept as far as video games go. What is so novel about Factorio's approach? Why does it lend itself particularly well to lessons needed in scaling a business?

To answer this, we must dive into where things go off the rails.

The Problem of Scale

In the early stages of the game, setting up dozens of automated belts, miners and inserters is an free-form design exercise, lacking consistency or convention. As the game plays out, you come to find that processed materials are themselves needed for larger, more complex devices. Remember that burner drill I pointed out earlier? It requires a stone furnace as an ingredient.

Routing belts back and forth between sources and destinations quickly becomes a mess. Without intending to, you introduce bottlenecks into your processing centers. And as you switch gears to clean-up those bottlenecks, you find yourself producing new issues of resource starvation – parts of your factory that aren't getting enough materials.

Meanwhile, you are (in parallel) trying to scale up your power needs (since all those drills and inserters require fuel). Your early sources of power come from burning wood & coal, so as you scale up your power production, your noise & air pollution scales up in kind.

Did I mention the building-sized bugs don't like pollution?

The problems continue. Before long, you discover that the ore deposit is almost entirely exhausted. Now, you face the problem of bringing in new resources from some remote location. What infrastructure will that require? (hint: high-speed rail). Venturing out to collect some oil? How are you supposed to transport liquids? You can't pour oil on a conveyor belt...additional infrastructure must be created to drill, store, transport, and refine it.

An alert pops on the screen – the alien bugs have had it. They're attacking your pollution-producing generators, knocking them offline. Your entire operation shuts down. You need to get it back online (fast!) while also (in parallel) building in defensive mechanisms – walls, guns, radar – that can warn & protect against future attacks.

It's not enough to build weapons, though – weapons need ammunition. More materials! More belts! More processing centers! But without power or materials, how will these new demands be met? How will they be built? What existing materials can be leveraged to close this gap in the short-term, in order to fulfill the long-term goal of getting the hell off this alien-infested planet?

A Metaphor for Startup Life

Most of the techies that turned me on to Factorio agree that the game is exceptional at teaching you how to grow small operations into large, complex systems. I'm a firm believer this metaphor extends to startup life as well. If you weren't shrewd enough to pick up on some of my references above, let me make it easy for you:

1. Scale demands automation; efficient scale demands process.
2. Solutions create new problems.
3. There are good problems and bad problems – both need solving, and both require different degrees of urgency and focus.
4. Trade-offs are made constantly; what matters is comprehending the impact of each concession.

Each of these bullets is (at least) a complete post in and of itself – here's an attempt at a summary.

1. Scale demands automation; efficient scale demands process.

Snake-like conveyor belts will get you nowhere; only an agreed-upon system that meets convention and is repeatable can scale. The Factorio community has a term describing an agreed-upon design that helps all players scale their factories: the "main bus." Even Tobi knows it:

If you have any hope of scaling your operation, you will find it in putting aside childish notions of "keeping things fluid", "going with with the flow", and "not being too rigid" – all of which are coded terms for not having the discipline to agree upon rules of engagement. Without the basics of, say, agreeing on how your team's code is committed, reviewed, merged into the repo, and deployed to an environment, those bugs (real or alien) find quick paths into your power centers and take them offline, fast.

2. Solutions create new problems.

Manual processes are very often the cause of bottlenecks, but automation isn't necessarily a panacea. If your sales team isn't able to keep up with email and SMS communications, turning to robots might produce entirely new issues. With hundreds (thousands?) of emails now en route at the press of a button, can you control them? Can you throttle them? Are you being charged for double (or worse) than what you expected? Sure, you're communicating at scale, but are you being added to spam lists at scale, too?

Every tactic you employ in Factorio has a compounding effect, and it doesn't take long before you get very good at anticipating the impact of your solution. Not enough copper? Doubling your copper furnaces only serves to jam your conveyor belts up. One solution creates another problem.

Whenever you hear someone in our biz say "hurry up and slow down," this is what we mean. If you want to get very good at thinking about how things might go wrong, Factorio is a great (and less expensive!) way to learn those lessons.

3. Good problems and bad problems require different levels of urgency and focus.

A bad problem in business: No leads; a good problem in business: too many leads.

No leads means no sales; no sales means no paychecks. This is your "alien bugs banging on the walls" problem. When this happens, you drop everything and swarm to defend. There isn't time to think, only respond. Nothing deters you until you eliminate the invasion, stabilize the factory, restore power and put new defenses in place.

Too many leads means sales are dying on the vine. Your sales team can only close so many so fast, but who should they pick first? How should they segment the list? What can be done improve their workflow? This is your "resource bottleneck/starvation" problem. With some careful planning (see above, re: solutions create new problems), you can identify ways to take the load off the team and maybe automate certain pieces of their workload.

Factorio is great at giving you a healthy mix of good and bad problems. It is a sandbox in which to test both your resilience and your thoughtfulness.

4. Understanding the impact of each trade-off.

Anyone tested in (startup) battle will tell you that it is a constant exercise in "good enough", best summarized in this meme:

If I've just built a railroad to import copper (because my local copper deposits are exhausted), does it make sense to also build an automation to fuel the train? Not if I can fuel it by hand once (or via a single wooden crate filled with coal) and have that train make its run dozens of times before needing to be refueled.

The same can be said of a business faced with building a solution vs. buying one. Why would we develop a UI by hand if it is:

• internally facing, and
• 85% of the functionality is already available in a NoCode platform like Retool?

This lesson becomes more concrete as you grow your factory and the impacts of earlier trade-offs compound. If one focuses all their time on researching science, one should not be surprised to turn around and discover giant alien bugs eating their face off.

The same can be said for outsourcing development of startup's core IP and then watching in abject horror as your servers crash under load...and not having any on-staff expertise to swarm on the fix.

When Factorio geeks talk about the game teaching leverage, this is what they mean. It's the same reason a seasoned technical leader will agree to (what appears at first as) a half-assed solution to close a gap. Voluntarily taking on technical debt isn't done out of ignorance – it's done to solve the right problem at the right time, knowing it is good enough to hold...for now. Our time, energy & resources are limited...and the bugs are banging on the walls.

Chris and I have talked at length about The 80/20 Principle; Factorio is incredibly effective at giving you a real-world lesson in it. You absolutely can take short-cuts (and in many cases, you'll have no choice). You will feel the repercussions of those choices later.

Automation & Leverage 101

I've only just breached the surface of Factorio in this post – there's an incredible amount of cool stuff revealed as the game progresses (eg. logic circuits, robot-based construction, etc.) so I encourage you to try it out. It's a surprisingly fun and fascinating way to look at the many different ways a complex system can be faulty or beautifully efficient.

You will come out of a Factorio game with a much greater sensibility around automation & leverage. I've taken a page from Tobi – my engineering team at Wrapmate is also able to expense the game. Who cares what business books you've read! Can you complete Factorio on death world settings?

On the Factorio subreddit, fans have deduced that the iron demands (alone) to go from nothing to functional spaceship is 7,619,920,134 raw ore. You're not going to be digging and processing that by hand! But if you are savvy enough to build a system capable of pulling that off, and dealing with all of the hurdles you'll face along the way, I suspect you won't be far off in being able to apply what you've learned in the real world.

Just remember to keep an eye out for those building-sized bugs.

A great way to foster some remote team building is by encouraging playful competition among your distributed folks. Wordle is a great way to do this! If you set up a channel at work and have players regularly share their scores, the competition heats up quickly. At Wrapmate, we currently have a #wordlebracket Slack channel that is getting plenty of activity.

However, when it comes time to say who won or lost, there's not much out there in the way of automatically calculating scores or reporting on them. Who has time to manually crunch numbers? Isn't that what automation is for?

Several weeks ago, Zapier's newsletter sent out a great link on how to automate the collection of Wordle scores by forwarding scores in an email and having Zapier parse those results and store them in a Google Sheet.

Today, we're going to up the ante. We'll keep the Google Sheet, but do 2 new things:

1. Ditch the email parser for a Slack parser, so that when a player shares a Wordle score in a specific channel, Zapier will capture the score and store it in the Google Sheet, and
2. Create a single bot-like response for any participating player in the same channel to have that player's score posted back to the channel.

This...is Zapier Wordle Leaderboard II Turbo: Champion Edition!

Part 1: Parsing Shared Wordle Score in Slack Channel

Before we get started, read up on the original Zapier post, and be sure to grab a copy of the Google Sheet they use.

The first zap we'll be importing is the one that parses a shared Wordle score in a specific Slack channel.

Since this will be an imported zap, I'll only go over the basics here. The zap consists of 5 steps:

1. Trigger: New Message Posted to Channel in Slack
2. Action: Only continue if...
3. Action: Only continue if...
4. Action: Text
5. Action: Create Spreadsheet Row in Google Sheets

Here are the key pieces to know for each of these 5 steps.

Step 1. New Message Posted to Channel in Slack

The key piece of this step is deciding on a single channel that you'll not only share your Wordle scores in, but also as the destination for Wordlebot to respond to requests.

Decide on that channel, and set it in the "Channel" field – in my version, we've decided to share Wordle scores in the #wordlebracket channel, so I've set mine to wordlebracket.

Step 2: Only Continue If...

This step is a Filter by Zapier that proceeds only if a Wordle score is detected, which begins simply with an attempt to find the word "Wordle" in that post.

Step 3: Only Continue If...

This next step is the key to the entire detection phase: determining if what was entered into the Slack channel is an actual Wordle score (as opposed to someone simply mentioning the word "Wordle" in discussions).

For this, we look for the existence of either:

• :black_large_square:
• :large_green_square:
• :white_large_square:
• :large_yellow_square:

The first guess of the shared Wordle score must have at least one of these four colored squares, so that's how we determine it is a message we care about parsing & logging into the Google Sheet.

Step 4: Formatter by Zapier / Text / Extract Pattern

The fourth step does the heavy lifting. At this point we've determined the Slack message is, in fact, a valid Wordle score. Now we must parse it. How? Regular Expressions, of course!

The input will be the actual Slack message posted in Step 1.

The pattern we'll use to parse is this:

Wordle ([0-9]+) ([0-9]+)/([0-9]+)

This grabs the three pieces of info we care about (indicated by the three sets of parenthesis in the pattern). They are (left-to-right)

1. The ID of the Wordle game being played,
2. The score, and
3. The hard mode score.

Step 5: Create Spreadsheet Row in Google Sheets

Now that we have our parsed score, it's time to write it directly to Google Sheets.

The key values you care about setting here are:

• Drive: The Google Drive where the Wordle spreadsheet resides (you did grab a copy of the spreadsheet from the original Zapier tutorial, right?)
• Spreadsheet: The actual spreadsheet copy mentioned in the previous bullet
• Worksheet: The tab/sheet inside the file you want to write data to – this should be the fourth tab, which (if not renamed) is called "Receive Info – Read Only"
• Sender: This should be the "User Real Name" property from the Slack message in Step 1.
• Wordle ID: This is "Output 0" from Step 4.
• Date: This is the "Ts Time" field from the Slack message in Step 1.
• Score: This is "Output 1" from Step 4.
• Hard Mode?: This is "Output 2" from Step 4.

When complete, it should look something like this:

Nice!

Finishing Up

Don't forget to turn your zap on! Now, play a game of Wordle and when you're prompted with the "Share" button, click it to copy the score into the clipboard, flip over to your Slack channel, and paste the score in!

That looks like something like this:

Then, pop open your Google Sheet, and head over to the fourth tab to confirm it wrote the score out!

Beautiful. Now...on to part 2!

Part 2: Have a Bot Read Back a Player's Wordle Scores

Let's take a look at the zap that allows a Wordle player to request their scores.

NOTE: As of this writing, I can't share a link to the zap (Zapier barks out an error), so you will have to set this up manually following the instructions below.

Step 1: Trigger (WHEN) New Message Posted to Channel in Slack

As with Part 1, select:

1. Your app (Slack) and your event trigger (New Message Posted to Channel in Slack), and
2. Your account (your Slack account).

In "Set up trigger", select the same channel as you used in the previous section – the channel that your team or office is sharing their Wordle scores to. Go ahead and leave "Trigger for Bot Messages?" set to "No."

Step 2: Only continue if...

For this 2nd step, select "Filter by Zapier" and enter in only a single piece of criteria:

• Only continue if... (Text) -> (Text) Contains -> Wordlebot scores

Nice! Moving on...

Step 3: Get many Spreadsheet Rows (Advanced, With Line Item Support) in Google Sheets

As with Part 1, select:

1. Your app (Google Sheets) and your event trigger (Get Many Spreadsheet Rows - Advanced, With Line Item Support), and
2. Your account (your Google Sheets account).

Then, under "Set up action", let's go over the individual settings:

The settings are as follows:

• Drive: Select the Google Drive that has a copy of the Wordle Scores template you copied from Part 1.
• Spreadsheet: Select the Google Sheets file that represents the copy of the Wordle scores template, again from Part 1.
• Worksheet: Select "Display Info" (or, if you've changed the names of the sheets, select the 2nd sheet – that sheet has contains the full leaderboard, and which looks like this:

• Columns: A:K
• Row Count: Set this to the maximum number of players you feel your scoreboard will ultimately have; it won't break if it is larger than your current number of players.
• First Row: Set it to 1, as we'll want to include the header row when we parse this out.
• Should this step be considered a "success" when nothing is found?: Leave this at "No."

Once set up, the test data should come back in the form of a "rows" object, with the 1st row having 11 columns – the 11 different column headers (eg. "Sender", "Played", "Win %", etc.)

Step 4: Code by Zapier / Run Javascript

For the next step, you're going to choose the "Code by Zapier" app, and for its "Action Event", you'll have it run custom Javascript. Here's how to set up that action:

Under "Input Data" you're going to create two keys / value pairs:

1. Set the first key to text and its value to the "Rows" element of the Google Sheet in Step 3.
2. Set the second key to player and its value to the "User Real Name" element of the Slack message in Step 1.

Then, in the "Code" section, copy and paste this block:

const csv = inputData.text.split(',');
const colCount = 11;
       
let obj = {};
let arrKeys = [];

// keys first
for (let i=0; i < colCount; i++) {
  arrKeys.push( csv[i] );
}

// rest of the values, starting with our prev. stopping point
for (let j=colCount; j < csv.length;) {

  let person = '';
  let stats = {};  

  // 1 row at a time, by # of columns in colCount
  for (let k=1; k % colCount != 0; k++) {
  
    let name = arrKeys[k-1];
    let value = csv[j];
       
    if (k == 1) {
      person = value;
    } else {
      stats[name] = value;
    }
    
    j++; // move forward in the csv
    
  }
  
  // if we've reached the end of a row
  obj[person] = stats; 
  
  j++; // move forward in the csv

}

output = obj[inputData.player];

In a nutshell, this:

• converts the entire Google Sheet (Rows) object into a single long CSV string.
• parses out the headers (row 1) first, and stores them in arrKeys.
• parses out the remainder of the csv, moving in blocks of colCount (11, for the number of column headers there are), breaking out each row by creating a string for the person's name or a stats object with a matching key and value (eg. stats["Played"] = 6).
• Adds the entire parsed set of data, by each person's name, to a parent obj.
• Returns only the key of the parent obj who originally requested the scores, eg the Slack user's full name, mapped to inputData.player

If you've been following along, you know realize the fun fact: the entire scoreboard is available via obj. We just choose to return an individual player's scores. You can expand on this!

Step 5: Send Channel Message in Slack

The final step is having our "Wordlebot" respond to the score request by writing out a response that includes all the juicy details of the person's score and posting it back to Slack.

1. Select "Slack" and for its "Action Event", choose "Send Channel Message"
2. Choose your account (same as in Step 1)
3. For "Set up action", use these values:

• Channel: Set this to the same channel as what was specified in Step 1
• Message Text: You can format this however you want, my script reads like this:

{{149341023__user__real_name}} has played {{149345309__Played}} games, with a win percentage of {{149345309__Win %}}, and a current winning streak of {{149345309__Current Win Streak}}. Their best Wordle score was {{149345309__Best Wordle Row}} rows, and accomplished this {{149345309__# of Best Wordles?}} time(s). Overall, they have an an average Wordle score of {{149345309__Current Average Wordle Score}}. For this week's competition, their score is {{149345309__Weekly Competition Score}}. Additionally, they have missed {{149345309__How Many Missed Wordles}} games, and have made {{149345309__Hard Mode Attempts?}} attempts at hard mode.

The key here is that wherever you see a {{number__header_name}} above, you're selecting a variable that is produced from the output of Step 4. Run Javascript. Your number will likely be different than mine, so if you get confused or aren't sure, remember that when you click inside the Zapier text fields, you can choose each value from the dropdown menu in the Zapier UI itself, like this:

• Send as a bot: Yes
• Bot Name: I like "Wordlebot" – call it whatever you want.
• Bot Icon: I used :robot_face: but you can use whatever you wish.
• Include a link to this zap?: No

Everything else can be left at their default.

Finishing Up

You're done! Don't forget to turn the zap on. Then, head over to your Slack channel and type "Worldlebot scores" and moments later, you should see a response similar to this:

Success! Zapier and your new Wordlebot do the heavy lifting of capturing scores, and reading them back to the Slack channel, so you can focus on the more important work – destroying your competition!

Quick question: what's your current Product roadmap look like? Is it managed in a tool that's some variation of the following image?

If you're in the PM space, this is probably a familiar view into work. You have a timeline, with various milestones mapped out, possibly across quarters, and grouped vertically by the area of work or team that's focused on the work. Clear, professional, easy to grasp at a glance...

...and completely insufficient.

One of my favorite video games growing up was Sega's classic masterpiece, Outrun. In it, you race a convertible Ferrari Testarossa across a fictional landscape, and the race kicks things off by asking you, the player, to choosing the music that will blast over the radio. But that wasn't the only thing you had to choose...

What made Outrun stand out, at its time (1986), was its ability to allow the player to choose what path they took. And the player didn't make these decisions up front...they made them in a split second, at exactly the moment the fork-in-the-road would appear. There were even situations where you were given the choice between two routes, started down one route, but by accidentally colliding with a vehicle, were bumped into the other route, so the decision was taken from you!

Outrun teaches us a fundamental tenet we need to understand about how our current product roadmap strategy is insufficient: the future isn't a straight-line, yet we continually plan for / visualize it in tools that are linearly constrained.

When I sat down with Chris, back in the summer of 2020, there was an initial vision of a product roadmap for Wrapmate. A lot has happened since then! We've learned more about our customers. We've gained access to new technology. A global pandemic flipped many assumptions on their head. Priorities we thought were very important back in the summer of 2020 are completely different today. And while none of these facts invalidate that original path – there were other paths not yet considered.

In order to be one step ahead of the game, we need to put solutions in place quickly, collect data on how effective those solutions are, and use those data to either stay the course or switch routes. Where the industry often falters is inadvertently rolling-up all feedback as a single data source, which inevitably leads to a single path forward. Ask these questions:

• Are you talking to the right customers?
• How are you segmenting those customers?
• Do you even know which customers are the right ones to pursue?

If your feedback analysis starts to paint multiple paths, why are you plotting out a development plan that reads like a Gantt chart? One customer's Devil's Canyon is another customer's Cloudy Mountain.

Unconvinced? Then don't take my word for it. Let's go directly to a product leader in the UX space for AWS, Pavel Samsonov:

That third image looks oddly familiar...

...oh, right – it's the map displayed at the end of every Outrun game, depicting the route the player took.

The next time you sit down to map out your product roadmap, consider a little branching logic in your details. I'm not asking you to open a window to the multiverse and consider everything, everywhere, all at once. But I am saying that as a product leader, you will need to anticipate a few major forks-in-the-road, and be ready to crank that wheel hard, one way or the other.

Just promise me you'll do so to Magical Sound Shower.

I recently posted to Twitter about my favorite Discourse themes, so I thought I would share here on the blog as well.

If you haven't heard of Discourse, it's been around for nearly a decade now, and is the labor of love project from my good friend Jeff Atwood in his attempt to improve the Internet's interactions with forums.

Before we dig into the themes, here's a quick refresher of the default Discourse look-and-feel:

Very practical, which is perfectly fine, of course!

...but just wait until you see what these communities have done.

Blizzard Entertainment

Yes, I realize I am a little biased here, but one of the single coolest things that's happened in my lifetime is seeing Blizzard Entertainment upgrade all of their game forums to Discourse. These themes are absolutely incredible! Truly works of art.

TensorFlow

If you're into Artificial Intelligence / Machine Learning, hop on over to the TensorFlow forums, also running atop Discourse. I really like how slick this theme is; the font choice really adds a nice touch.

Asana

We use Asana for task and project management over at Wrapmate. When I went looking for their online community, I was pleasantly surprised to see they were also running atop Discourse. They have a superb theme that is a delight to use.

Code Academy

I recently discovered that Code Academy also uses Discourse for their online community. Their theme is super geeky, which I totally dig – definitely getting some strong retro terminal vibes from it!

I suspect it won't be long before the need to support an online community arises at Wrapmate. When that fateful day arrives, I'll be looking forward to seeing what our design team comes up with to push the envelope, just as these companies have.

The NoCode wave is upon us. Platforms like Retool, Airtable and Bubble are changing the way the way we build software...

...said no software developer, ever.

I'm not going to lie: NoCode is a contentious topic. Non-technical co-founders swear by it, career programmers scoff at it. Who do we believe? How do we move forward as an industry?

In times like this, I turn to our technical forefathers, in the hopes of not repeating the mistakes of the past. Here's Alan Cooper, the father of Visual Basic, on his take:

Look, I get it. Programmers are expensive. Getting them to estimate their efforts accurately (and then hold them accountable) is like pulling teeth. And when you ask them why your latest feature isn't done yet, out comes a nonsensical string of technical jargon that tells you nothing.

It feels like it would be a lot less painful to just do it yourself. That is, after all, the promise of NoCode. It is in this promise that we fundamentally misunderstand what NoCode platforms were meant to do for us.

Let's start with problem number one. "NoCode" is a bit of a misnomer. Here's a quick peek at an app in Edit Mode in the popular NoCode platform Retool:

This is why programmers balk; they know the truth. NoCode tools are really better described as "EventuallyThereWillBeSomeCode." And the minute you need to write one line of code, I'm sorry to have to tell you this...but you either need to have a programmer do it, or you need to become one yourself.

This leads to problem number two: doing it yourself. NoCode tools give you the sense that this isn't so hard. You throw a few drop-down menus and buttons together on a screen, spin up a database to store your data, and suddenly you are collecting data...customers are interacting! Our startup is off and running! Who needs expensive engineering departments?

...until things start to break. Data is lost. Performance is poor. Customers are irate. Your department heads need answers, and you can't explain what's going wrong...

Some time ago, when I was just a mere software developer, I sat in a conference room with a team of individuals facing a problem. Those at the table spoke hypothetically of a "solution" that might "look" a certain way and would "behave" according to specific business rules. When they were done speaking, I spun my laptop around and declared, "...like this?"

For a moment, they stared in silence, likely surprised I was able to put something together so quickly. Then, excitedly, they began pointing to the parts they wanted changed...

Memories are short.

It wasn't that long ago that we were all advocating for the advancement of "rapid prototyping" tools – the ability to quickly throw together a functional solution to prove out a concept, minus the cost of building out a team to turn dreams into reality. NoCode tools are simply the next evolutionary step in that paradigm. No, it doesn't make sense to build a business atop a NoCode application. Yes, it does make sense to let an engineering team use a NoCode tool to eliminate a lot of unnecessary front-end work!

At Wrapmate, we've used Retool to stitch together makeshift admin tools that interface with both native database connections and REST endpoints. Are they customer facing? No. Do we plan on using them long-term? Also, no. But perhaps most importantly: Do they solve a problem the team faced with minimal time and effort? Yes.

Like any innovative technology, it is up to us to inform our non-technical peers what strengths and weaknesses lie in pursuing these tools, but that only happens when we have a seat at the table. Non-technical founders that eschew in-house engineering expertise in lieu of NoCode tools to run their business "because it is totally fine" will likely face the music at some point (you have been warned!) By choosing to do it yourself, you've elected to not have engineering in your corner, to be your voice at the table that says "if we do this, here is how we will suffer in the long term, and are we willing to cut that corner?" And to those who choose that path, Godspeed.

As for those in technology that do leverage NoCode, you will discover that much of what you are already doing can be greatly accelerated. As long as you understand the repercussions, why not?

Technology leaders that thoughtfully embrace NoCode tools will ultimately pull ahead of their more bullheaded counterparts. They will be able to solve tooling issues with less effort and experiment faster...at far less a cost to their organization. Leveraging NoCode in this way doesn't threaten a programming staff, it frees them – to focus building the robust, scalable product that a NoCode solution never intended to replace.

There is a sentiment going around social media at the moment that I can't keep quiet about. Before we get into the sentiment, a brief history of time (management):

In a world before Calendly, scheduling time with someone was nightmarish...but not for the reasons you think. The struggle was not one of a lack of mutual transparency (ie. "what do both of our calendars look like for the day") and more of one with power dynamics at play (ie. "I MUST meet with you at this time, no exceptions"). Calendar etiquette was non-existent; those sending a request for your time weren't asking themselves important questions like "am I booking something at over your lunch hour?" or "am I including an agenda?" Most meetings probably didn't even need to be meetings.

In the struggle to stay focused, reduce interruptions, and wrest back control of one's schedule, the old way of doing things was awful. It cost them nothing to demand time on your calendar, but it cost you everything.

Calendly, a tool built to allow professionals to quickly & easily allow random strangers on the internet to schedule time to meet with them, produced a wonderful side-effect when used as an internal tool within a company: it shut bad actors down.

With Time Management 101 blocks of reserved time on your personal calendar – no lunches, no 30 minutes at the start or end of the day, a block of time dedicated to work, distraction free – Calendly then presented only what was necessary to the asker: "Here's what's available. Find something that works for you...or don't."

To some, it could be perceived as inconvenient to be presented with someone's boundaries. That doesn't mean you get to violate them.

Which brings me to the sentiment:

So, now that the power dynamic has shifted (and will continue to do so as the emerging worker gains a greater awareness and control of their working conditions), suddenly, Calendly is the problem?

One of the first posts I made on Wrapmate's intranet/wiki was one regarding basic calendar etiquette, in the off-chance bad acting was the result of ignorance than of malevolence.

"Here's how to view someone else's calendar."

"Consider the other person's time zone."

"Do your best not to book across lunch."

"Always include an agenda."

For those of us in charge of teams (especially programmers), setting a precedent of "do not interrupt developers unless it is vital" is not only the right approach, it produces highly productive teams. In the absence of leaders setting that culture in a work environment, Calendly is a wonderful tool that guardrails against bad behavior, regardless of intent.

Is there a better solution? Perhaps one day! But until that day arrives, to make a blanket statement like "I'll never click your Calendly link" says more about you than the failure of technology to address the problem.

Refusing to click someone's Calendly link is the equivalent of saying, "What's this? The person whose time I'm making a request of has a professional approach to time management? They have reduced (or eliminated) wasteful interruptions in order to stay focused and productive? They've put guardrails in place and shifted the onus onto me to find time on their calendar? No, thanks. I'm too important for that."

And in that situation, perhaps Calendly did what it was supposed to do all along.