Gears are hard

Nearly two years ago, I decided to 3D print a mechanical calculator.

This project is extremely in character for me. I love old technology, and especially mixing old and new technology (like sending digital data via ham radio).

When you want to 3D print something, there are different levels of how sane you can be. The sanest option is to find a design on a site like Printables or Thingiverse that someone else made. Ideally, one that consists of as few parts as possible.

When I looked at the available 3D calculator designs, there were everything from simple ones with just a few gears, to modular ones based on historic designs (like Blaise Pascal’s calculator), all the way up to a 3x scale replica of the Curta Type I, the most advanced mass-produced mechanical calculator before electronic calculators took over the market.

There were two main features I wanted: a modular design, and a simple design. Unfortunately, the only modular design was modeled after Pascal’s calculator, and not very simple at all.

So, I decided to take the less sane option and design one from scratch. I did not realize how big of a challenge I was jumping into.

My first design was straightforward:

Design #1

The two gears each had 10 teeth. One gear (blue above) would let you read out a number from a dial. The other (orange) would have an extra nub on a single tooth, which would serve to carry a sum into the next decimal place. The posts the gears sat on would be tilted, so only that extra tooth would make contact with the next gear.

I was having trouble getting the correct angles, when I realized there was a more elegant solution. By flipping every second set of gears upside down, they’d be lined up naturally.

When I printed the first prototype, I discovered that the gears I had made in TinkerCAD were not interlocking and turning correctly. There was way too much of a gap between the teeth:

The advantage of 3D printing is that it lets you fail quickly. I realized I needed to know more about how gears were designed.

It turns out that there is an optimal gear tooth shape that was discovered in the 18^th century, potentially by Leonard Euler. They’re called “involute gears”, and they transmit force along a straight line between gears of any number of teeth.

Involute gear teeth

There are plenty of CAD libraries to generate custom involute gears. I found a good one, and designed a ten-toothed gear. After a few iterations to test the fit, I had my first full draft print:

Also note the lightweight base design

But this version still had a big problem I hadn’t foreseen. I had presumed that when one tooth of a ten-toothed gear fully passed through a gap in a second ten-toothed gear, both gears would turn one tenth of the way. As it turns out, this is completely wrong.

Notice that the gears have turned through two teeth, not just one

So it was back to the drawing board. Eventually, I found the appropriate bit of trigonometry and determined that I could use a gear with 30 teeth of a specific size, with the carry tooth turning its partner gear by exactly 3 teeth. To make the design easier, I also decided to have the carry tooth stick out from the rest of the gear. This meant the carry gear needed to be printed with supports, but the support would be small and easy to break off after printing.

This design kinda worked. The main issue left was that the gears kept slipping upward on the posts. My first solution was to use little c-clips on top, which worked okay, but wore out over time. Still, I was satisfied enough to declare the project finished.

About a year and a half later, I decided to come back to the project and make an improved version with a better fastener. After trying and failing to build a system that screwed together, I settled on a version held together with pegs that rotate into place.  This version has held up for the last couple of months, so I’m ready to share it with others.

3D model of final version.

Side view. I will add a photo when I return home.

You can find the model and print instructions on my Printables page here.

Coming Soon: Fiction: A Leap of Logic

Statistics are interesting because they are often used to sway arguments, or entice people. This discussion looks at the impact of normal statistics without an underlying context. Take the example of a cookware company that uses statistics in its advertisements (very few other companies provide statistics of any sort). Some of the statistics are shown below.

• 103 Michelin-recognized restaurants use the cookware.
• The cookware is used in over 2,000 global restaurants.
• 90,000 pans in service.

These numbers may seem significant, but in the context they are not. For example in the first statement, “100 Michelin-recognized restaurants use the cookware”. Worldwide there are approximately 18,713 Michelin-recognized (not starred) restaurants. So 103/18713 = 0.55%. One would argue that this really isn’t a significant number. If we were to look at only Michelin-starred restaurants, some 3700 worldwide, the number would increase to 103/3700 = 2.78%. The number looks a lot better if we only consider North America, where the number is 1941, so 103/1941 = 5.3% which is 10 times as significant, but still not that much.

For the second statistic, that it is “used by over 2,000 global restaurants”, let’s look at a number of scenarios. This is hard to quantify, because how do you define a “global restaurant”. It has to be different from a run-of-the-mill restaurant, because there could be 15-25 million of those. A better way to look at is to consider the number of professional chefs who run restaurants. Let’s consider just Canada first, where there are 62,200 chefs (2023). This would give us 2000/62200 = 3.2%. If we look at the USA, this number climbs to 286,000, and 0.7%. Neither is earth-shattering, and if we include worldwide restaurants the number just plummets.

The last statistic, 90,000 pans, is quite meaningless. It’s just a reflect of how many pans have been sold, and can’t really be compared to other companies because they don’t publish their data. Some vague figures suggest the Le Creuset foundry in France produces 25,000 items a day. Restaurants use either stainless steel or aluminum pans, and to put the number into context, there are circa 97,000 restaurants in Canada alone (of course the 90,000 pans were not suggested to come from restaurants exclusively).

There is nothing to say that the numbers used in the advertisements are whatsoever incorrect, but they do provide a level of ambiguity because they aren’t given in any frame of reference. Numbers only mean something if put into context.

When you're leading a team of five or 10 people, feedback is pretty easy. It's not even really "feedback”: you’re just talking. You may have hired everyone yourself. You might sit near them (or at least sit near them virtually). Maybe you have lunch with them regularly. You know their kids' names, their coffee preferences, and what they're reading. So when someone has a concern about the direction you're taking things, they just... tell you.

You trust them. They trust you. It's just friends talking. You know where they're coming from.

At twenty people, things begin to shift a little. You’re probably starting to build up a second layer of leadership and there are multiple teams under you, but you're still fairly close to everyone. The relationships are there, they just may be a bit weaker than before. When someone has a pointed question about your strategy, you probably mostly know their story, their perspective, and what motivates them. The context is fuzzy, but it’s still there.

Then you hit 100#

Somewhere around 100 people, the ground shifts underneath you, as you realize you don’t know everyone anymore. You just can't. There aren't enough hours in the day, and honestly, there aren't enough slots in your brain.

Suddenly you have people whose names you don’t recognize offering very sharp commentary about your “leadership.” They’re talking about you but they don’t know you. There’s no shared history, no accumulated trust, no sense of “we’ve been in the trenches together.” Your brain has no context for processing all these voices.

Who are these people? Why are they yelling at me? Are they generally reasonable, or do they complain about everything? Do they understand the constraints we're under? Do they have the full picture?

Without an existing relationship, it feels like an attack, and your natural human response is to dismiss or deflect the attack. Or worse, to get defensive. Attacks trigger our most primal instincts: fight or flight.

This is the point where a lot of leaders start to struggle. They still want to be open to feedback—they really do—but they're also drowning. They start trusting their intuition about what they should pay attention to and what they should ignore. Sometimes that intuition is right. Sometimes it's just... self-selected, stripped of context, pattern matching against existing biases and relationships.

On top of that, each extra layer of management, each extra level to the top has separated you, and now you’re just not like them anymore. Their struggles are not your struggles anymore.

At 200, it's a deluge#

By the time you reach 200 people or more, feedback isn't an actionable signal anymore. At that size, feedback stops being signal being noise. A big, echoing amphitheater of opinions, each louder than the last, each written in the tone of someone who is absolutely certain they understand the whole system (they don’t), the whole context (they don’t), and your motives (they definitely don’t).

And all those kudos you used to hear? Those dry up. When you had a close relationship with everyone, kudos came naturally. You were just talking. But now folks just expect you to lead, and if they’re happy with your leadership they’re probably mostly quiet about it. They're doing their jobs, trusting you, assuming things are generally fine.

The people who are unhappy? They're loud. And there are a lot of them.

From where you sit, it feels like everybody's mad about everything all the time. And maybe they are! Or maybe it's just selection bias combined with the natural amplification that happens when people with similar grievances find each other. You don't know if this is a real crisis or just three loud people who found each other in a Slack channel. You just can’t tell anymore.

Because feedback doesn’t scale. Humans scale poorly. Your nervous system definitely doesn’t scale.

Why this happens#

Feedback doesn't scale because relationships don’t scale. With five people, you have some personal interaction with everyone on the team. At twenty, you interact with some, but not all. At 100 you still have personal relationships with 10 or 15 people, so there are a lot of gaps. At 200, your personal relationships are a tiny slice of the overall pie.

Making matters worse, as the din gets louder and louder, channels for processing all that feedback get smaller and smaller. Where you once had an open-door policy, now you have “office hours.” Sometimes. When we’re not too busy.

Where once All-Hands meetings had open questions, now you’re forced to take the questions ahead of time. Or not at all.

Even your Slack usage dwindles, because half the time you say anything, someone’s upset with it.

We tell ourselves we're "staying close to the ground" and "maintaining our culture,” But we're not. We can't. Because the fundamental math doesn't work. The sheer volume of feedback we’re getting absolutely overwhelms our ability to process it.

So what do you do about it?#

First, you have to admit the problem exists. Stop pretending you can maintain personal relationships with 200 people. You can't. Nobody can. Once you accept this, you can start building systems and processes that work with this reality instead of bumping against it. You have to filter, sort, and collate the feedback coming in, and you need to do it at a scale larger than your own capacity.

When you can’t rely on “just talk to people,” you need systems that distinguish between:

• legitimate issues
• noise
• venting
• misunderstandings
• and “this person is projecting a whole other problem onto leadership”

That means: structured listening, actual intake processes, and ways to synthesize themes instead of reacting to every single spike.

Build proxy relationships. You can't know 200 people, but you can know 10 people who each know 10 people. You should already have strong, trusting relationships with your leadership team, and then set the expectation that they have strong relationships with their own teams, and explicitly ask what’s on people’s minds. When feedback comes up through this chain, it comes with context. Pay attention.

At small scale, trust is direct: I know you. You know me. At larger scale, trust must be delegated: I trust the leaders who are closer to the work than I am. If you don’t intentionally empower those leaders to absorb and contextualize feedback, you’ll drown. They’re the ones who can say: "I know who said that, why they said it, and here’s what’s actually going on."

Build structured channels for feedback. For example, you can set up working groups to dive into thorny problems. The people closest to the problem understand it better than you do, and they can turn a flood of complaints into something you can actually act on. Or consider starting an "employee steering committee" for the sole purpose of collecting feedback and turning it into proposals. You’re essentially deputizing people who care deeply to listen for you, and then manage the feedback din.

Remember that every angry message is still a person. When someone you know well gives you feedback, you might not like it, but you’re likely to say "Oof. Okay. Let’s talk." At scale, you need to find ways to respond with humanity — even when the feedback you received lacks it.

Close the feedback loop. Let people know when you’re acting on their feedback, and if you’re not going to act on it, let them know that you at least heard it. Nobody wants to feel unheard.

In fact, you'll probably think — if you haven't done it already — that you should have an anonymous comment system to capture feedback. Don't. It's a trap. Anonymous feedback is the most contextless feedback you'll get, which makes it the least actionable. And it inevitably turns out to be contradictory or lacking key information, all those folks feel even more unheard and unhappy than before.

Finally, accept that you're going to get it wrong sometimes, and own that. You're going to ignore feedback that turns out to be important. You're going to overreact to feedback that turns out to be noise. When you make a misstep, be transparent about how you're correcting it.

The uncomfortable truth#

Past a certain size, you have to make peace with the fact that a lot of people in your org are going to be frustrated with you, and you're going to have no idea why, and you may not going to be able to fix it.

Not because you're a bad leader. Not because you don't care. But because feedback doesn't scale, relationships don't scale, and the alternative—trying to maintain authentic personal connections with hundreds of people—is a recipe for burnout and failure.

This is genuinely hard to accept, especially if you came up through the early days when you did know everyone. That version of leadership was real, and it worked, and it probably felt really good. But it doesn't work anymore, and pretending it does just makes things worse.

Note: The photo is of a large crowd gathering for a union meeting during the 1933 New York Dressmakers Strike. That's scaling feedback.

I considered it a possibility. Now it's set in stone. Instead of fully shutting down in the coming year due to tumbling revenue, leadership decided "What if we use someone else's platform?" It just so happens, the platform they chose is vibe coded.

Like many tech companies during the pandemic, we over-hired and had to contract over and over again. Without the VC-funded war chest that our competitors had, we couldn't compete in marketing and sales. Our brand-awareness shrunk into obscurity.

So, in all fairness, we lost the capitalism game. And, I'm fine with that.

We had a plan to gracefully wind down, unlike Redbox (archived). Once the balance hit a certain threshold, a plan (prepared a year in advance) would have made everyone whole and return the remaining funds to the investors.

Except, the investors changed their mind and would rather take a chance on a future sale than admit defeat.

What's changed their mind?

The technology costs are but a single digit percentage of the monthly spend – the majority is tied to headcount and benefits. When I saw the numbers going towards headcount costs, I fully understood the situation we were in.

The previous reduction truly cut headcount to the bare minimum that can still keep the technology we have operating. Any fewer, and there's a high risk of business interruption within a few months.

At the same time, the current revenue projection calls for the end of the business within a few more months.

We used to have a thousand people. Today, I can count everyone on my hands. A cut beyond this will fundamentally need a different operating model.

Given that our revenue can no longer support the staff needed to run our own technology, how do the finances work on someone else's platform?

Assuming that this Software as a Service (SaaS) can deliver what leadership believes, the napkin math suggests it'll work out.

With this SaaS, they expect...

• No engineering headcount
• No implementation headcount
• No support headcount
• Contracted sales teams to pick up the rest

So if they're going to lay everyone off and migrate to a SaaS, who's going to do the migration?

I'll be on my own for an extra month or two to migrate it all over.

Somehow, I need to keep the tech coasting in its last days while migrating all the data that I can.

I've expected either a winding down or a transition for over a year now. I've come to terms with an ending like this already.

While my peers are bitter about having a closer end date than me, I'm not as emotionally invested into when or how it ends.

What I didn't expect is how a vibe coded app passed as legitimate to the board of directors. We don't even have a contract with this platform yet and people are told they're being laid off.

Legal Concerns

In my two hours of testing and feedback, I found that — without immediate changes to the SaaS — we'd be immediately in violation of the California Consumer Privacy Act (CCPA), California Privacy Rights Act (CPRA), Telephone Consumer Protection Act (TCPA), CAN-SPAM Act, Americans with Disabilities Act (ADA).

How could a platform be that bad? This SaaS has no customers in the United States. Their team is based in another country without similar laws or regulations.

Even so, I'm confident that vibe coded platforms made by people in the United States also unknowingly violate state and federal laws around privacy, communications, and accessibility.

One of our tech acquisitions was through a bankruptcy fire sale after the original company could not make penalty payments for violating the Telephone Consumer Protection Act. These issues cannot be ignored to do business in the United States.

Things don't work

I've used LLM assisted auto complete. I've generated inline functionality. I've generated classes and modules. And I've generated entire web apps. I've seen what GPT, Claude, Z.ai GLM, Grok Code, and Gemeni do across the entire spectrum of software development.

Within a minute, I could tell it was made with Claude or GLM. Every picture zooms in on hover for no reason. There are cards everywhere. Links go to # in the footer. Modals have an closing X button that doesn't work. The search button up top doesn't do anything...

It's like someone took some screenshots of a competitor, asked an LLM agent to create design documents around all of them, and then implement those design documents without any human review.

At the shallowest depth, I can see how a CEO got bamboozled. The happiest path is implemented. The second happiest path is rough. The third happiest path is unhinged.

No hacks. No reading the source code. Just innocent clicking around allowed me to break a critical invariant to running a business: I could place orders without giving my contact details or payment.

Besides displacing jobs, issues like this concern me deeply.

LLM-generated code can enable a business process quicker and cheaper than hiring a full team with benefits. With the experts that still value their craft steering the development, software can be produced just as well as without these tools. Business processes meaningfully affect people's lives, whether staff, customer, vendor, or share-holder.

At its extreme with vibe coding, LLM-generated code will have such poor quality that it is negligent to use LLM-generated code without expert oversight and verification. More lives are going to be affected by negligent software than ever before.

It is so much easier to accept that my life is changing because my employer couldn't stay fit in the economy than to accept it being displaced because of broken software made by a machine. The fiscal performance of my employer in this economy is the root cause, of course. And I accept that. Having to pivot everything to some broken SaaS that breaks the law? That's harder to accept.