Sample Chapter
Sample Chapter
For most adults, work occupies a huge share of waking life—commute, email, meetings, projects, then doing it again tomorrow.
When work feels miserable, it's hard for life not to feel miserable.
For a long stretch, that's where I lived. My days felt like:
Wake up.
Go to a job I didn't like.
Come home.
Repeat.
One of my only real escapes was the weekend, when I could get high and disappear into a different world where work didn't matter so much, at least for a little while.
It was especially hard because I was the primary breadwinner. I had a wife and two daughters depending on my income. Quitting wasn't a neutral choice; it would affect them immediately. So with the exception of Safenet, I stayed, even when I hated it.
At the time, my internal story was simple:
"I hate work, but I have to keep doing it."
I didn't yet have any language for "fit" or "wiring"; I just assumed this was what adulthood felt like.
After the diagnosis, and especially as I aged into my fifties and sixties, that story got more complicated. I started to see that I wasn't just "unhappy with work." I was repeatedly trying to do work in ways that didn't fit how my brain is wired.
This chapter is about how my view of work has changed—from "necessary misery" to "puzzles I choose to engage with"—and what it actually looks like now.
What Work Used to Mean
Back in 2002, during career counseling, I was asked a question:
"What is work to you?"
I didn't just answer in the session. I went home, opened a document, and wrote it out in detail. My list included:
Work is how I earn money to provide for my family.
Work is where I make my contribution to society.
Work is where I create things I can point to and say, "I did that."
Work is where I demonstrate my abilities and learn new skills.
Work represents my status in life.
Work is where I expend most of my effort.
Work is something I should enjoy and like doing.
I even wrote that work was "the place where I get to engage with people in a political manner." Looking back, I think I wrote that because I assumed that's what successful professionals did—that "playing the game" was simply part of adult working life, even though I never felt naturally equipped for it.
Alongside that, I listed characteristics of an ideal job: long-term focus, problem solving, design and architecture, cross-functional work, constant learning, independence, working with smart people, seeing the whole product, being a kind of "authoritative source" in the middle of complex systems.
If you strip away the noise, the picture that emerges is:
I wanted work to matter.
I wanted it to be intellectually demanding.
I wanted to build things that actually did something in the world.
I wanted to be recognized as competent.
I assumed politics came with the territory.
What I didn't yet understand was that the "status" and "politics" parts of that list were going to clash head-on with the way my brain works.
Getting an MBA, in theory, prepared me to move toward those director and VP roles—the places where strategy and "leadership" live on the org chart. But in reality, those jobs are built on politics: alliances, subtext, reading the room, subtle signaling. As my career unfolded, it became obvious I was never going to be comfortable in that arena. Much later, the autism frame gave that mismatch a name and an explanation.
When Restlessness Was a Signal
Looking back now, certain patterns jump off the page. I didn't leave jobs because I couldn't do the work. I left when the conditions that made the job livable stopped being met, frustration built up, and it became clear nothing was going to change.
The times when work felt truly "too hard" were usually when I was stuck in a political situation I had no realistic way to influence or win.
Usually, I'd be working long hours, the conditions that made the job tolerable would erode, I'd start quietly looking, and if nothing improved, I'd leave.
I grew restless—sometimes to the point of quitting—when:
There was nothing to hyperfocus on.
If a role didn't offer at least one complex, meaningful problem to sink into—designing a feature, working through a data model, architecting an interface, managing a genuinely complex program—I felt like the engine was idling. Busy, but not engaged.
It wasn't clear what came next.
If I couldn't see any upcoming work that felt interesting or important, my motivation disappeared. "Busywork now, mystery later" never sat well with me.
The organization pushed death-march projects.
Sometimes executives made promises—usually tied to their own incentives—that translated into nights and weekends for the product team. Features were committed to impossible dates. I watched teams burn themselves out for schedules and scope that were never realistic. In more than one case, the leaders who set those schedules were eventually removed.
Leadership stopped caring about the end customer.
In some companies, the focus shifted from solving real problems to shipping something—anything—that could be sold. Corners were cut. Technical debt piled up. People were told to be proud of products no one actually wanted.
The work didn't feel meaningful.
At one company, I was assigned to a meandering side product that wasn't strategically important. It bothered me less only because I was in business school at the time; I could tell myself the job was just a bridge while I finished the MBA.
The culture turned toxic.
Micromanagement, poor leadership, and politics with no rational basis were huge red flags. At a couple of companies, including Corporate Personnel Systems (after BrianT was fired) and later Advanced Systems Lab (after BruceR was fired), I watched the environment degrade in slow motion. My journals from that time read less like personal reflections and more like system logs. I was documenting failures in leadership and structure the same way an engineer documents failure modes—things others ignored but I couldn't.
The company looked doomed.
In a few places, it became obvious that the business wasn't headed anywhere sustainable—startups burning cash with no real product-market fit, small software companies going sideways. Once I concluded that liquidation or shutdown was likely, it was hard for me to keep investing my energy. Continuing to build systems I believed would be scrapped felt dishonest.
The work diverged from what customers actually wanted.
I've been in situations where customers were promised things that weren't true and systems were built that didn't match real user needs. That violated something deep in me. If we're building on a lie, my work starts to feel like complicity.
Because of all this, I was often looking for my next job almost as soon as I started the current one—sometimes within a month.
At the time, I treated that pattern as a character flaw: I told myself I was impatient, not a "team player," a quitter, unable to "tough it out" like everyone else.
In reality, it was often an alarm system:
There is nowhere to put your hyperfocus here.
Or the thing they want you to build doesn't make sense.
Or the system itself is heading for a wall.
Once that internal alarm stayed red long enough, my brain wanted out—even if I couldn't always articulate the reasons cleanly at the time.
From Career Ladder to Puzzle Board
For years, I compared myself to a standard template:
Get promoted.
Manage more people.
Become "a leader."
Make more money.
It's what most of the corporate world seems to reward—and what I saw modeled around me.
My actual career looked nothing like that. I moved across roles:
software engineer
process engineer
project manager
program manager
product manager
systems analyst
I often started strong—especially when there was a clear problem to solve—and then ran into the same walls: politics, loss of meaningful puzzles, cultures that rewarded spin over substance.
The story I told myself was: you failed at building a career.
After my diagnosis, and especially after I shifted into contracting, that story started to change.
As a consultant, I'm not climbing anyone's ladder. I'm brought in to solve problems:
untangle a gnarly legacy system
straighten out a broken workflow
help a team get serious about Agile/Kanban
bring clarity to an overloaded product organization
Most of my engagements have been part-time but long-running—anywhere from 14-30 hours a week per client, sometimes two clients at once. Working 60-65 hours a week doesn't bother me if I'm in the zone and the puzzles are real.
The metric shifted from "Am I progressing up the org chart?" to "Am I helping untangle real problems in a way that makes sense to me?"
Now that I'm in my early sixties, something else has changed:
I don't have to work in the way I once did. The financial urgency is lower. If a situation became truly miserable, I could walk away and stay home.
And yet I still want to work—because the right kind of work gives my brain the puzzles it craves. The treadmill version of work has mostly fallen away. What remains is the problem-solving version.
Where My Wiring Fit
It's easy to tell the work story as a sequence of exits and misfits. That's not the whole truth. There were also stretches where work fit so well I didn't have to force anything.
The pattern is simple: when the system was coherent and the incentives were aligned, my wiring became an advantage. I could see the whole system, write the spec, spot the failure modes, and help a team deliver something real. And when I was surrounded by competent, honorable people, work didn't feel like a treadmill. It felt like craft.
A few examples stand out—not as a resume, but as evidence of what "fit" looks like for me:
Quiq (AnswerPoint): The objective was clear, the problems were real, and it was genuinely fun working with our lighthouse account, Ask Jeeves.
HP (Quality management): HP shaped me. I learned the HP Way, studied Deming, and cared about metrics and integrity long before it was fashionable. When quality mattered, I felt at home.
Accruent (Sumatra): I landed with an all-star team implementing XP and Scrum. When a team actually works as a team, my job gets easier—and better.
Accruent (Abstraction Control Solution): I'm proud of what we built. The patent came later without my name, but the point isn't the credit—I helped design and deliver something solid. The six weeks of training in the Philippines was hard at times (including a couple of meltdowns), but it was real work with real impact.
iMANY (Validata): I still think fondly of that project—especially the team—and the feeling that we delivered something GlaxoSmithKline actually needed. We scrapped what had been built before and replaced it fast, iteratively, and on purpose.
iMANY (Medicaid Analytics): A high-level puzzle—brilliant people, rigorous thinking, forecasting models, and a UI we made sane. The market outcome was mixed, but I was proud of what our team delivered, working across five sites around the world.
Genentech (PathLIMS): One of my favorite projects. I wore multiple hats—product owner, delivery manager, development manager—and worked with a wonderful offshore team. I had autonomy, and I had a kind, appreciative user community. I landed that engagement in June 2013, a few weeks after my diagnosis, and it became a 12 1/2-year anchor that ran through December 2025. It brought continuity and mental ease: I could stop panicking about the next gig and just do the work. Over time, PathLIMS became a special interest. I learned it end-to-end, and you could see that in the reams of documentation I maintained.
Genentech mattered for reasons that went beyond the work itself. Along with a few smaller part-time gigs I picked up through a small network of people who already trusted me, it let us save for retirement and get our daughters through college and grad school.
We didn't pay for everything. My parents covered room and board for college; my wife and I covered the rest. For grad school, we helped some and the girls took out loans. But the work removed a fear I've carried for as long as I can remember: running out of money as I got older. We lived below our means and saved as much as we could.
Even so, what made it work for me was the same set of ingredients as the other good stretches: a real problem, competent people, and enough clarity that I didn't have to force a corporate persona just to survive.
Those were the kinds of environments where my wiring became an asset. But understanding why they worked—and what my brain was doing in them—took the autism diagnosis.
There's one rule underneath all of it—one that explains a lot of my job changes:
When I'm in an organization and I see problems, I'll work until I resolve them. If I can't fix them and still have to work inside the broken system, I'm done.
That sounds rigid. I'm less rigid now. Plenty of systems are imperfect. But if the dysfunction becomes the job—if I'm being asked to build on top of lies, politics, or incentives that punish good work—my motivation collapses. Not because I can't "tough it out," but because excellent work is the whole point for me. If excellence isn't possible, I start looking for a place where it is.
Detail, Documentation, and "Thinking Like a Computer"
A couple of things about how I work only made sense after the autism diagnosis. One is the way I document.
As a program manager, I captured detailed meeting minutes, wrote detailed project plans, captured issues and risks, kept decision logs, and tracked dependencies. As a product owner, I wrote excruciatingly detailed requirements and specifications in Word and Excel documenting: data models, interface behavior, edge cases, integration points. It never occurred to me that this was unusual. I thought that was the job.
Over time, I realized most people weren't working that way. Some colleagues wrote brief bullets and called it done. Others held most of the system in their heads—at least until something was forgotten and broke.
For me, not documenting feels unsafe. My brain builds dense internal models, but it can't keep every detail in active memory. A lot needs to be externalized—onto paper, into documents, into diagrams—or it will degrade. Once the pieces are written down, my mind can start connecting them—turning scattered details into a mental model I can rotate, probe, and adjust.
So I write things down:
not because I love bureaucracy,
but because if something lives only in conversation—requirements, designs, edge cases, dependencies—I will lose details unless I externalize it,
and because systems with no written model eventually fall apart.
One very specific example is email. I spend far more time than most people writing emails—drafting, proofreading, fixing, rereading, fixing again. Part of that is me trying to be precise, but part of it is risk management. In a live conversation, I can miss tone, miss subtext, or say something that lands wrong and not realize it until later. In writing, I can slow it down and control the variables.
People have told me, in more than one job, that I'm the most detail-oriented person they know. From the inside, I don't experience that as "obsessing over detail." I experience it as building a workable model of a complex system. In her notes, Dr. E wrote: "occupational difficulties due to being overly-detailed, literal. "
From the outside, that level of detail can look like a deficiency—something to be corrected or managed. From the inside, it feels more like a special power: the ability to spot patterns, edge cases, and failure modes that most people miss. That's not modesty or arrogance. It's just what happens when your brain refuses to skip steps.
I didn't realize how visible that trait was outside of work until it showed up in mundane places. In 2014 I was at Home Depot and showed a clerk a long, detailed chat I'd had with their online support the night before—around 12:30 a.m. She scanned it and said, "You're the most Type C person I've ever met." She was referring to the DISC system, but the label didn't matter. What landed was the fact that she could see it instantly: I don't just ask questions. I build a little case file. And until people started pointing it out, I thought that was normal.
At one point, a colleague (GlennS) said I "think like a computer." For him, it was a compliment. He meant that my spoken and written language often follows the same kind of logical, conditional structure you'd see in code.
With AI tools, that same wiring is less of an oddity and more of an asset. I'm comfortable turning fuzzy goals into clear inputs, constraints, and expected outputs—the same thing I've been doing for years in specs.
This is simply how my brain works. If someone hires me and doesn't provide me with the time to capture that level of detail, I'm probably not the right person for the job.
Part of what makes that level of detail possible is the kind of hyperfocus my brain does. When I drop into it, the rest of the room falls away. I can write a spec, build a small tool, or work on this book for hours. On walks, I put on a podcast and the world narrows to that one track. During the discovery years I read Tony Attwood's book The Complete Guide to Asperger's Syndrome three times: once straight through, once with a highlighter, and once underlining the highlights. It wasn't casual reading; it was me trying to confirm, line by line, that I wasn't imagining this.
In open offices this looked like a feature. I remember EdK (from Corporate Personnel Systems) once asking how I could work with all the noise and people walking by; I honestly hadn't noticed. Once I'm in the zone, I don't need headphones—I just focus and stay there. The downside is how I react when someone breaks that focus. If a coworker walks up behind me and says, "Hey, Doug," I jump. My heart pounds. At home, my wife mostly sees that downside: I disappear into a task and miss small bids for attention until she is frustrated. To her, it can look like I am ignoring her. From the inside, it feels more like being pulled out of a narrow, deep channel.
Seeing the Whole System
Because I've held so many different roles over the years—engineer, tester, business analyst, project manager, program manager, product owner, delivery manager—I've accumulated multiple perspectives on how software and systems actually get built.
It's a little like having worked as host, busboy, waiter, and cook in the same restaurant. You don't just know your station. You understand how the whole place runs.
In software and systems work, the "restaurant" is much more complex: multiple teams, interlocking systems, regulatory constraints, legacy integrations, ever-changing business priorities.
My brain likes that kind of complexity. It wants to see:
how work flows end-to-end,
where handoffs fail,
how decisions in one part of the system ripple into others.
In practice, that means I'm often the person who:
notices when a requirement is underspecified because I've seen that exact kind of ambiguity explode later,
spots when a "simple change" will affect three other systems no one is talking about,
can sit with engineers and discuss data models and then explain trade-offs to business stakeholders in plain language,
keeps asking, "What problem are we actually trying to solve?" when everyone else is already attached to a particular solution.
I don't have formal authority as a contractor. I don't sign off on budgets. I don't do performance reviews. What I have is analysis and recommendation.
My job, as I see it, is to understand the system deeply and then say,
"Given how this actually works, here are your options."
It's up to the client to decide which option to take—or to ignore my analysis entirely.
Consulting on My Own Terms
In the years since my diagnosis, most of my work has fallen into two broad patterns:
Long-term, part-time roles inside complex systems.
These are multi-year engagements where I help maintain or evolve a system that real people rely on to do demanding work. I'm drawn to environments where the work has real-world consequences—scientific research, critical business processes.
Helping software organizations improve how they deliver.
In other engagements, I focus on process: using lean, Agile, Scrum, and Kanban to help teams see how work flows, where it gets stuck, and how to improve predictability and quality. It's a mix of teaching, analyzing, and designing experiments.
Most of these roles have been part-time. Sometimes I've had two at once. It also matches my reality: I'm not good at self-promotion, and most of my work has come through a small chain of people who already knew what I could do. That structure suits me:
It keeps me at an angle to company politics rather than in the middle of them.
It lets me focus on value delivery instead of climbing ladders.
It gives me enough distance to say, "This doesn't make sense," without feeling like my entire identity is at stake.
One of those engagements—Genentech—has been in my life for more than twelve years now. The most compelling part was the mission: knowing that my small team was helping the company develop new therapies to save patients' lives. I began that work in 2013 and stayed with it through my fifties and into my early sixties.
When an engagement isn't offering a good place for my hyperfocus—for example, if the meaningful work slows down or the organization stalls—I need to redirect some of my energy into something else:
reading more about Agile, systems thinking, or organizational design,
experimenting with AI tools and how they might change software work,
literally anything that gives my mind something to lock onto.
As I wrote on Wrong Planet, my brain is much calmer when it is able to hyperfocus on a problem that feels useful or important.
Leaving a Mark
There's something else that's driven me since I was young: I'm accomplishment-oriented. I've always wanted my life to amount to something—to leave behind something real and useful, not just a trail of jobs.
For a long time, I assumed work was where that would happen. Not just shipping features, but building something that mattered: a principle, a model, a "Doug's Law"—a name for a pattern other people could recognize.
I was never happy with "good enough." That drive helped me, but it also set me up for frustration when work didn't deliver what I'd imagined.
After the diagnosis, I had to redefine what "mattering" could realistically mean, given my wiring:
Solving interesting problems.
Creating order out of complexity.
Being dependable.
Being kind where I can.
The small, predictable routines that keep me stable.
That's a different definition of a good life than the one I started with. But it fits me better.
The impulse to name patterns didn't go away. If anything, I noticed it more. Over the years I've seen the same failure modes repeat across organizations, and I've wanted a way to make them explicit.
One of those patterns comes straight out of how my brain works—the same wiring that makes me document everything, externalize system models, and write detailed specs even when others don't. I call it Doug's Law of Documentation:
"In software organizations, what doesn't get documented will get reinterpreted. What gets reinterpreted will eventually break."
That's why the "excessive detail" I've been labeled with for decades doesn't feel excessive to me. It feels protective. My brain sees what ambiguity turns into later, and documentation is how I close the gaps while there's still time.
And that leads to this book. This memoir is part of the same impulse: to turn decades of pattern observation into something concrete. If someone reads this and thinks, "Oh—that's why that never worked for me," or "That's what I've been trying to explain," that's enough.
What Still Bothers Me About Work
It would be easy to spin this into a tidy story:
I hated work, I learned I was autistic, I redesigned my work life, and now everything is perfect.
That's not how it feels.
There are still parts of work that bother me:
Age and opportunity.
Now that I'm in my early sixties, I'm aware that many tech companies don't line up to hire older people, especially if they're not willing to work full-time and work crazy hours. As I write this, my longest engagement—Genentech, more than twelve years—ended in December 2025, earlier than I would have hoped. Work keeps my mind busy, and that engagement was genuinely stabilizing. Now, at 63, the question of 'what next' is no longer theoretical. I rely heavily on people I've worked with before to pull me into new engagements. I've also burned some bridges along the way—or simply drifted out of touch—which narrows the field. I'd like to keep working, but I'm realistic about the market.
The harder part isn't just finding the next contract. It's what happens when work—which has been my primary special interest for forty years—is no longer available. When the structure that organized my days, the puzzles that kept my brain engaged, the professional identity that made sense of me—what comes after that? I don't have the answer yet. I'm living the question
Politics I can see but can't fix.
One byproduct of thinking in systems is that I'm often quick to notice when decisions are no longer about what makes sense for the customer or the system, but about internal power games. When people choose obviously suboptimal paths to protect status or bonuses, I can usually tell there's a political story underneath. I can name it. I can sometimes explain it. I rarely have the power to change it. These days, I'm more likely to accept that and move on than to beat my head against it.
Restlessness when there's nothing worth doing.
I still get uneasy when the work available to me is shallow, misdirected, or obviously pointless. The difference now is that, because I'm closer to retirement, I have more freedom to say no. If the only option on the table is to be paid well to do unimportant work for long stretches of time, I have to decide whether the money is worth what it would do to my mental state.
These aren't new problems. They're the same problems I've always had—I just now have better ways to identify them, and more freedom to walk away when I need to.
Reflection
Work hasn't turned into a passion project or a fairy tale. I didn't discover a single "true calling" and ride off into the sunset.
What has changed is this:
I understand that my brain needs meaningful puzzles, not just a paycheck.
I recognize that my restlessness at work has usually been a signal—sometimes accurate—that the system, not just the person, was broken.
I see my documentation, detail-orientation, and "thinking like a computer" not as oddities, but as the way my wiring contributes value when it's allowed to run the way it runs.
I'm more willing to choose engagements that align with how I work and to walk away, or not engage, when they don't.
I no longer treat work struggles as proof that I'm fundamentally defective; I treat them as information about fit.
These days, my work can be summed up simply:
I try to spend my working hours on problems that matter, in ways that fit the way my brain actually works.
If that's no longer possible in a given place, I'd rather step back than go back to living on the treadmill.
After everything that came before, that feels like a substantial change.
That shift didn't stay confined to work.
Once I started seeing "fit" at work, it was hard not to apply the same lens to everything else: my routines, my marriage, my social life, and what I needed to feel okay in an ordinary day.
That's what the next chapter is about.