I used to own a knitting shop. This is perhaps the most unexpected sentence I could write in a piece about technology leadership, so let me explain why it belongs here.
(I’m in more company than you might think. The overlap between serious knitters and engineers — software, electrical, mechanical, civil, and otherwise — is striking enough to be a running joke in both communities. The precision orientation, the tolerance for complex systems, the satisfaction of building something methodically from first principles, the ability to hold a multi-step process in working memory: these attract similar minds. Mention knitting at an engineering conference and someone nearby will nod knowingly.)
Over the years, I’ve come to believe that knitting and software development and engineering share more structural similarities than most people would guess — and that the skills I developed as a knitter transferred to coding and leadership in ways that weren’t metaphorical. They were concrete. The pattern thinking, the debugging approach, the attention to detail, and the relationship between following instructions precisely and knowing when to deviate from them: all of it applies.
Patterns as Programs
A knitting pattern is, in important ways, a program. It’s a set of instructions that, if followed correctly and completely, produces a deterministic output. “k2tog” (knit two together) is a function call with a predictable result. A pattern for a cable sweater specifies the exact sequence of operations, repeated across rows and columns, that produces a specific fabric structure.
But treating k2tog as a stand-in for any function call undersells the analogy. Mastery in knitting, like mastery in engineering, reveals that there is rarely only one way to accomplish a given goal — and that the choice between approaches carries real consequences. Consider the simple operation of decreasing stitch count to shape a garment. A beginner has one tool: k2tog. An experienced knitter has a whole toolkit:
- k2tog (knit two together): simple, prevalent, leans right. The default decrease, the one every pattern assumes you know.
- ssk (slip, slip, knit): leans left. Visually mirrors k2tog, but achieved through a different mechanical sequence — you slip two stitches individually before knitting them together, which changes how the resulting loop sits on the needle and how the decrease twists.
- skp (slip 1, knit 1, pass slipped stitch over): also leans left, but produces a subtly different texture than ssk. The raised ridge sits slightly differently on the fabric surface — not wrong, not right, but distinct, and noticeable to the eye that knows what to look for.
- sk2p (slip 1, knit 2 together, pass slipped stitch over): a double decrease that centers the remaining stitch. Essential at the apex of a V-shaped shawl where both sides of the decrease must be perfectly symmetrical, and neither a left lean nor a right lean is acceptable.
This is TMTOWTDI — “There’s More Than One Way To Do It” — in fiber form. Each technique accomplishes the same underlying goal (fewer stitches) but with different visual results, different structural characteristics, and different appropriate contexts. A raglan sweater with mismatched decrease directions won’t fail structurally — the stitch counts will add up, the seams will close — but it will look wrong to anyone who knows what they’re looking at. A lace shawl where skp has been substituted for ssk throughout is correctly executed and subtly off. The right choice isn’t arbitrary; it’s contextual, and understanding the context requires knowing not just what each technique does, but why it does it differently.
Software developers and engineers encounter this constantly. Sorting algorithms, each optimal against different data distributions and size constraints. Join strategies in SQL with meaningfully different performance profiles at scale. Caching architectures that trade consistency for availability in ways that matter differently depending on your use case. Synchronization primitives that solve the same concurrency problem with different throughput and safety characteristics. The engineer who knows only one approach will reach for it reflexively and sometimes inappropriately. The engineer who understands why the alternatives differ — what conditions make each preferable, what the real cost of the wrong choice is — can decide deliberately rather than by habit.
This means that reading a knitting pattern requires the same skills as reading code: understanding notation, tracking state across iterations, predicting how local operations will affect global structure. An experienced knitter looks at a pattern for a complex lace shawl and understands the relationship between each instruction and the eventual shape of the finished piece. An experienced engineer looks at a system design and understands how each component contributes to overall behavior — and how different implementation choices would shift the tradeoffs.
Both also involve pattern libraries. Knitters accumulate a mental library of standard techniques — basic stitches, increase and decrease methods, join techniques, finishing approaches. Developers and engineers accumulate design patterns — standard solutions to recurring problems. In both cases, the value of the library is that you recognize when a known pattern applies and can deploy a tested solution rather than inventing from scratch.
The Dropped Stitch
Every knitter knows the particular anxiety of discovering a dropped stitch several rows after it happened. A single missed loop, unnoticed in the moment, propagates through subsequent work in ways that become increasingly visible over time. The longer you wait to address it, the more it has affected, and the harder it is to correct without ripping back significant work.
This is an almost perfect analogy for technical debt and software bugs. A flawed assumption early in a system’s design creates problems that are minor and localized at first, then increasingly difficult and expensive to address as more code is built on top of that flawed foundation. The dropped stitch that costs two minutes to fix in row 12 can require ripping out a week of work in row 150.
Both knitting and software development and engineering have taught me to notice problems early and address them immediately rather than hoping they’ll resolve themselves or become less important. They don’t. They compound.
But the dropped stitch also teaches a more nuanced lesson — one that took me longer to learn. Not every discovered error requires ripping back to the source. There is a third option, one that beginners rarely know exists and that experienced knitters prize: you can intentionally unravel just the affected stitch, dropping it further down to the row where the error actually occurred, then use a crochet hook to work it back up through each subsequent row in the correct orientation. You rebuild only the stitch ladder that failed, leaving the surrounding fabric entirely intact.
I am particularly good at this type of repair. It requires an intimate understanding of stitch structure: which direction the loops sit, how the yarn feeds through each successive row, the distinction between a knit loop and a purl loop when viewed from below rather than above. Done well, the repair is invisible — indistinguishable from the original knitting. Done wrong, the intervention creates a worse problem than the one it was meant to fix.
The engineering analogy is surgical intervention on a running system: the targeted fix that corrects a specific error without a full rollback or rewrite. A precisely scoped database migration that repairs corrupt records without touching the surrounding schema. A hot-patch applied to a live production service. A careful refactor that untangles one module without disturbing its neighbors. These require the same depth of structural understanding — you must know not just what the system does, but how each layer relates to the layers above and below it. Applied correctly, the fix is invisible to users and leaves the system cleaner than before. Applied incorrectly, you have introduced new failure modes on top of the original.
The critical observation is that this type of repair is specialist work. On a knitting forum, you can ask who is comfortable dropping down to repair a complex cable or lace pattern, and a handful of people will confidently volunteer. Most will defer. On an engineering team, you will find people who understand the high-level architecture and people who can reason well about isolated components, but far fewer who can perform targeted live repairs on complex, stateful production systems — under pressure, with incomplete information, on a timeline — without making things worse. That skill is rare, and correspondingly expensive when you need it. Knowing the repair is possible, knowing whether you are the one to perform it or whether you need to bring in someone who is, constitutes its own hard-won form of operational judgment.
Frogging: The Cost of Undoing
“Frogging” is knitting slang for ripping out completed work — the term comes from the sound of undoing stitches (rip-it, rip-it). It’s sometimes necessary. A mistake that can’t be fixed in place has to be backed out.
Experienced knitters develop judgment about when to frog and when to work around a problem. Minor imperfections in a highly textured fabric might be invisible in the finished piece and not worth ripping back 20 rows. A structural error in the shaping of a sleeve requires ripping, because working around it will compound the problem.
Software developers and engineers face exactly the same decisions. Refactoring versus working around technical debt. Rearchitecting versus extending the existing system. The judgment required is similar: is this error minor enough to accept, or will it prevent the system from working correctly at scale? Is the cost of undoing and redoing less than the cumulative cost of leaving the problem in place?
I’ve made both kinds of decisions, in both domains, and I’ve made them wrong in both directions. The pattern I’ve observed is that the cases where I deferred addressing a structural problem because the immediate fix seemed too costly almost always became more expensive, not less, over time.
Following the Pattern vs. Understanding the Pattern
Beginning knitters follow patterns literally. They do exactly what the instructions say, in exactly the order given, and don’t deviate. This works until something goes wrong or until they need to modify the pattern for their specific situation.
Experienced knitters understand patterns — why each instruction is there, what problem it solves, what would happen if it were done differently. This understanding enables modification, adaptation, and troubleshooting when the instructions don’t quite work.
The parallel in software is the difference between code that works and code that’s understood. A developer who follows a tutorial step-by-step and gets a working result is doing something useful. A developer who understands why each step is necessary can adapt when the context changes, recognize when a standard pattern doesn’t apply, and debug when something goes wrong.
Leadership has the same dynamic. There are frameworks, methodologies, and best practices in every domain. Following them literally produces mediocre results, because they were designed for a typical situation that may not be yours. Understanding them — knowing the problem each practice was designed to solve, and therefore when it applies and when it doesn’t — is what produces good results in specific contexts.
Finishing: The Underappreciated Work
In knitting, “finishing” refers to all the work that happens after the main knitting is done: weaving in ends, blocking the fabric, seaming pieces together, adding buttons or closures. Finishing is unglamorous and time-consuming, and many knitters undervalue it. They spend weeks on a sweater and then rush through the finishing, producing a result that looks sloppy despite technically correct knitting.
Software has exactly this phenomenon. The last 20% of a project — documentation, edge case handling, performance optimization, testing, deployment infrastructure — feels less interesting than the core development work and often receives less attention than it deserves. The result is systems that are technically functional but poorly documented, inconsistently tested, and hard to operate in production.
The lesson from knitting: finishing is part of the craft, not an afterthought. The quality of the finished piece depends on both the knitting and the finishing. The quality of software in production depends on both the code and the work that makes that code reliable, understandable, and maintainable.
The Unexpected Gift
People sometimes express mild surprise when they learn that a technology executive is a serious knitter. I find the surprise interesting — though, as I mentioned earlier, the overlap between technical minds and serious crafters is more common than the raised eyebrows would suggest. The skills involved — precision, patience, systematic problem-solving, the ability to hold complex state in mind, the ability to tolerate detailed iterative work without losing the larger picture — are useful in exactly the domains that engineering and technology leadership require.
Hobbies that seem unrelated to your professional work often aren’t. The perspective shifts, the skill analogies, the cognitive habits built in one context transfer in unexpected ways. The knitter who becomes an engineer brings something different to the practice than the engineer who doesn’t knit.
Yarn bombing — the guerrilla knitting movement where crafters cover public objects in knitted or crocheted pieces — is a good example of this kind of unexpected transfer. It’s knitting applied to a completely different context: street art, public space, community statement. The technical skills are the same. The intent and the audience are entirely different. That shift in context, taking something you know deeply and applying it somewhere it wasn’t designed for, is exactly the kind of creative reapplication that makes cross-domain experience valuable. The best engineering ideas I’ve had came from applying a pattern I learned in one domain to a problem in another.
I should say, since this piece is written with the voice of a practitioner but the truth is past tense: I no longer knit. Years of intensive keyboard and mouse work — the accumulated load of a career in technology — combined with the repetitive fine-motor demands of the craft itself have given me thumb arthritis severe enough that knitting is no longer a realistic option. The activity that built these instincts, that gave me a vocabulary for thinking about patterns, errors, and repair, is one I had to give up.
There’s something worth sitting with in that. The skills transferred. The craft that built them is gone. How we adapt to the physical, emotional, and practical constraints that accumulate over the course of a life — setting aside things we loved, recognizing what persists, understanding which parts of an experience we carry forward when the experience itself is no longer available — is a subject worth its own examination. I’ll return to it separately.
This is, I think, the strongest argument for pursuing genuinely diverse interests throughout your life and career. Not as stress relief or balance — though they serve those purposes too — but because the cross-domain insights compound in ways that enrich both the professional and personal work. Even if the source of those insights eventually becomes inaccessible, what it gave you doesn’t disappear.
Pattern recognition is valuable. And patterns are everywhere, if you learn to see them.