Analyst to Senior Manager (2000 to 2008)
I aimed at this job for four years before I got it. In 1996, as I was starting at the University of Montana, the chair of the business school’s management and marketing department pitched me on a brand-new emphasis in information systems, not yet even a credentialed minor, and told me where that road could lead: a consulting firm called Andersen Consulting, where business and technology were the same career. I loaded up on computer science and IS courses, showed up at Andersen’s campus recruiting events every single year to be seen, and in my senior year finally got to go all the way through the process. I had another offer on the table, a Montana e-tailer riding the dot-com wave with one of a handful of exclusive licenses to sell Sony products online, and a grandmother from the Chicago area who had spent years trying to teach a Montana boy some big-city sophistication. I chose the bigger adventure. I started at Andersen Consulting on July 19, 2000; six months later the firm woke up with a new name, Accenture, and one year to the day after I started, it went public. I stayed eight years, and it is the chapter where I learned the trade: how large software actually gets built, how a program with a hundred moving parts holds together or does not, and what it takes to lead people through both.
I did not arrive completely green. Through college I had co-founded a two-person web shop building sites for Missoula businesses, worked at a small Montana carrier during its prepaid wireless launch, and helped a college radio station build its sales and promotions. Small things, but they meant I had already touched a customer, a bill, and a deadline before I ever billed an hour.
The apprenticeship: learn the whole machine
My first client was Portal Software, whose Infranet platform did real-time billing for internet and communications providers. I was a QA analyst, the bottom of the ladder, and the assignment that shaped me was not a test script. It was infrastructure: the test environments did not exist, and nobody senior was free to create them. So I learned system and network administration on the job, determined the technical architecture, got the client to approve the hardware, and stood up an integration environment where seventeen applications had to work together, Clarify’s CRM on a Tuxedo middleware layer, Oracle underneath, Vitria BusinessWare stitching it to Portal’s billing engine. When the Clarify install defeated its own error-filled documentation, I pushed until an expert was brought in from Minneapolis, then wrote down everything he did so the knowledge would not leave when he did. When I decided I needed to understand the database layer properly, I pursued Oracle DBA training on my own and later got certified. None of this was in my job description. All of it became the foundation: I have never since been able to look at a software system as anything but the whole machine, environments and interfaces and data included.
The reviews from those first years tell the story better than I could, and I have kept them. A manager wrote that the team gathered several times a day around a whiteboard chart I had made of every system’s state, our improvised operations center. At Cisco, I designed a new portal interface in a day, and it was demonstrated to senior leadership including the CEO with, as the review put it, outstanding feedback. At SBC, the Baby Bell that would go on to buy AT&T itself and take its name, I became the architecture lead for the online DSL ordering work as a first-year consultant, writing SQL against the production reports when the business needed answers faster than the tooling could give them. The analysis I ran there killed one of our own projects: the data showed the client simply did not need it. That cost Accenture billable hours. It also won something worth far more. The client began requesting me by name, and contracts were extended on the condition that I stayed. I made consultant at fourteen months against a two-year norm, and the lesson stuck for good: make the client’s problem smaller, not your timesheet bigger.
By late 2002 I was on the AT&T Wireless account near Seattle, designing tests for the Siebel systems behind GoPhone, the prepaid offering the company launched in 2003. Within three months I was leading the test design. There was a small full-circle pleasure in it: four years earlier I had watched a tiny Montana carrier launch prepaid. The work was the craft I was becoming known for, and by then I had become one of the firm’s go-to people on the Rational toolchain and the Rational Unified Process, presenting on it firm-wide. I reorganized the requirements so that sixteen test scripts covered what forty had covered before, ran a traceability review that found half the system’s functional requirements missing from the test scripts entirely, a gap we drove to more than ninety percent captured, and helped deliver the release on contract terms that had put Accenture’s fees at risk. When the client’s test design lead was reassigned, the client chose me to lead the design team over its own people, across three releases. I was teaching the V-model to everyone who would sit still: specify, build, and verify in matched pairs, catch every defect before it ships. I believed it completely. The next year taught me exactly where it breaks.
The crucible: wireless number portability
In the spring of 2003 I moved onto the project that would mark me more than any other: AT&T Wireless’s rollout of wireless local number portability, the FCC mandate that let Americans keep their phone number when they switched carriers. It is worth pausing on what that actually required, because the scale is the story. Porting a number is not one company’s feature; it is a transaction between competitors. Every carrier’s ordering, billing, and network systems had to exchange messages with every other carrier’s, through clearinghouse vendors, against a shared national numbering database, correctly, at volume, starting the same morning: November 24, 2003. The FCC set the date; an industry body called the Wireless Testing Sub-Committee was where the carriers’ test coordinators met to define the shared test phases and keep one another honest.
My assignment was inter-carrier testing for AT&T Wireless. The role actually worked like this: it was my first experience with a structure I have used many times since, two in a box. The client’s own test coordinator, a sharp operator who held the industry seat and by that August chaired the WTSC itself, was one half of the pairing; I was the Accenture lead beside her, running the test program day to day: a team of about fifteen across three sites, inside a thirty-seven-person Accenture program, inside a client testing organization larger still. The first document I produced on the project was a list of five questions for her, asking where the industry requirements lived and which test phases were real. By autumn I was maintaining the industry’s end-to-end test flows workbook, authoring AT&T Wireless’s inter-carrier testing requirements through seven versions, and sitting in WTSC sessions in Redmond and Overland Park, still in my mid-twenties, alongside the test leads of Verizon, Sprint, Nextel, and T-Mobile. The business side of the program ran through the client’s portability program lead, a member of the industry’s wireless portability operations team, and my notes from one session record a carrier escalating a slipped test date to another carrier’s CEO. That is the altitude number portability operated at, months before the public ever heard of it.
Here is the hard part, and the record is specific about it. We did test, extensively. The industry defined four phases, network, systems, end-to-end, and round robin, and by launch AT&T Wireless had worked through them with every major carrier; I have the completion charts. What nobody ever ran was a true performance test: the whole inter-carrier machine under production-scale volume, with the error paths triggered and exercised. It was not unknowable. The question of an industry load test was raised at the WTSC that August, in the very room I sat in, and what came of it was a proposal to port 250 numbers, a token, deferred as one carrier’s contribution. AT&T Wireless and Cingular’s own filing to the FCC that same month warned that porting volumes could reach thirty million messages a month and pointed at carriers overseas whose systems had crashed under the same load. And there was a structural risk underneath us: nearly every other carrier used one clearinghouse vendor; we alone had chosen a different one, and the two vendors had built to different interpretations of the same industry guidelines. Then, in the final four weeks, the other clearinghouse pushed two software upgrades that shut down inter-carrier testing for nearly two weeks. I was not experienced enough to fight for the thing that was missing. I sat where the load test was deferred, and it did not occur to me to insist. We had proven the parts. Nobody had proven the system.
On November 24 the system taught us the difference. Under real volume, our clearinghouse could not keep pace; the other side’s systems, built to strict time limits, rejected the delayed requests instead of absorbing them, and the backlog fed on itself. The company’s separately crashing CRM upgrade took away the tools the call centers needed just as the port failures arrived, and the whole thing became one of the most publicly documented IT failures of its era. I spent that stretch between Bothell, Washington, and the porting call centers in Jackson, Mississippi and Oklahoma City, hundreds of call-center reps working from triage sheets my team wrote overnight, in a warehouse-sized building on, as our own morale deck described it, 1.23 acres of sprawling black asphalt.
What the public record cannot show is how it felt from the ground. For days that ran together like weeks, nobody could say why the ports were failing: not the carriers, not the clearinghouse engineers on call after call, not our own IT experts, not the specialists I pulled in from around Accenture. Every carrier was struggling, but our failure had a signature all its own. My team hand-worked the worst of it; when a high-profile customer was stuck, and some were very high profile, someone would log into the switch and complete the port manually, which for a stretch meant their job was keeping us off the morning front page. The client was bleeding customers in public, and standing in that Jackson call center I felt something close to desperate.
What I had left was trust, built over two years on that account, so I spent it. I told my client I knew an engineer who could fix this: a former Andersen consultant, now independent, with deep experience in large-scale telecom systems, my college friend Mike Sparr, one of the fastest root-cause minds I have ever known. I got a verbal approval that was just barely strong enough to act on, called Mike, and told him to get in his car and start driving, from the Reno foothills down to the clearinghouse vendor’s office in Oakland, our old stomping grounds, while I worked out how to put an independent engineer into a federal-deadline crisis without harming the client or my firm. One Accenture partner let me know precisely what he thought of that, then conceded that nobody had a better idea.
Mike drove down from the Reno foothills that day and walked into the vendor’s Oakland war room, where I made sure he was authorized to see whatever he needed. Then he did what the best engineers do: he set aside everyone’s theories and read the system itself. He called me back within hours, and by my memory of that call, the diagnosis had taken him about thirty minutes. The picture he gave me was the one that had eluded days of conference calls. The vendor’s platform was misconfigured for the load it was facing, down to the threads, the memory, and the connections. And at the boundary between the clearinghouses, the systems were talking past each other: when a request failed on our side, the error went back written in machine code where the other side expected plain readable text, and what the other side could not read, it dropped, so to the rest of the industry we looked as if we had never answered at all. Everyone had tested their own side of the interface. It took an outsider with no side to read the boundary itself. A diagnosis is not a fix; the changes were benchmarked against the vendor’s own labs and rolled out over the week and a half that followed, and the industry relaxed its strictest validation rules. But the ports began to flow again, still backlogged, finally recovering, and for the first time in days I could stand in front of my client with an explanation instead of a mystery.
Something else happened in those weeks that I have thought about often. The AWS vice president whose strategy portfolio suddenly included this operational fire, Jonathan Tinter, leaned all the way in beside us. He was young for what the moment demanded and so was I. We were both in over our heads and we both knew it; what mattered was that we stayed in the work, which it turns out is most of crisis leadership. When it finally quieted he gave me a bottle of something nice as a thank-you. He was a class act. Watching a leader stay calm, stay present, and stay generous inside a public failure taught me as much as the failure did.
Two things about that winter stay with me. The first is the conviction it bought. The V-model had taught me to catch every defect before shipping; number portability taught me that a system of systems cannot be proven in pieces. You must test against reality, under real load, before real users arrive, and then let them arrive gradually so any failure stays small. That conviction has run through every role since, all the way to the products I build today.
The second is what the people above me saw. In January, while my Tiger Teams were still working the backlog out of Jackson and Oklahoma City, my manager wrote the case for my promotion, built almost entirely on the crisis: the teams I organized, the escalations we cleared, the industry seat I held, and the line that I had helped the client’s vendor secure the services of an outside expert to fix its performance problems, which is the polite contemporaneous record of Mike’s drive to Oakland. The promotion to manager landed in March 2004. The hardest launch I ever touched is the one that made me. It left me suspicious of tidy success stories, and a little tender toward the people inside the messy ones.
India: build the machine that finds the defects
Two weeks after the promotion paperwork was written, and before it had even taken effect, I was in a kickoff room with Microsoft. Their OEM business unit, the group whose systems put Windows licenses on every PC shipped in the world, had an offshore testing operation that was not working; of twenty-three testers once brought on in Hyderabad, ten remained. Accenture proposed something bolder than staff augmentation: an integrated testing organization across Reno, Redmond, Hyderabad, and Dublin, designed, run, and answered for by us. I was one of four people in the founding room, and I made the choice that defined the engagement: I went. For close to a year I lived that project, first from Redmond and Reno through the assessment, then, from May into late November, from Hyderabad itself, roughly two hundred days on the ground as interim manager of the system-test team, because the only way I know to transfer a methodology into a new organization is to live inside it, not mail it a binder.
We built it like a product. A single methodology across three countries, entry and exit criteria, traceability wired into Microsoft’s own Product Studio through custom fields, automation in Rational Robot, and a scorecard the client graded us on every quarter. We started a Testing Community of Practice in Hyderabad, a tools lab, brown-bag talks, certification drives, which outlived the engagement, and the two Indian engineers I grew from senior engineers into my team leads were still being coached by me over late-night calls a year after I rotated home, by then leading teams on the account themselves. The results are the kind I still care about, because they are unit economics with a referee: testing budget down roughly thirty percent, resource needs down eighteen percent, production defects down thirty-six percent, and on requirements traceability, Microsoft’s own vendor scorecard graded us at one hundred. Anyone can cut cost by testing less. We cut cost while quality rose, and the client’s scorecard, not our slideware, said so. Within a year, Accenture’s delivery center in Dalian, China, asked me to help define how to build the same capability there, which is when I understood we had not built a team. We had built a playbook.
The Ballmer decision: my first subscription business
The Microsoft work earned a stranger and more important assignment. While I was building the test organization in Hyderabad, another corner of Microsoft was living with a quiet crisis. Software Assurance is Microsoft’s volume-licensing subscription: enterprises pay annually for rights to every new release plus a set of benefits. The next major Windows and Server releases kept slipping, customers had begun timing their renewals to guess at ship dates, and inside Microsoft the renewal math on a business with a revenue base around six billion dollars was eroding. That December, a fix was carried into a review with Steve Ballmer and approved: rebuild the value of the subscription itself, so that renewal made sense on its own merits rather than as a bet on a ship date. I was not in that room. I was the program manager hired the next month to make what came out of it true.
It remains one of the densest experiences of my life, and I understood it later as my first real product work: new offerings taken from requirements all the way to launch, with packaging, positioning, readiness, and delivery as one inseparable problem. In roughly ten weeks we drove the definition of the new benefits across twenty teams and more than fifty stakeholders, over six hundred fifty requirements spanning marketing, sales, operations, licensing systems, and IT: deployment planning services delivered through partners, a restructured training-voucher program, around-the-clock problem-resolution support, new tooling like Virtual PC Express, and the piece the market remembers, a version of Windows available only to subscribers. Underneath the visible benefits sat a configurable fulfillment platform that more than one person told us could not be built. It was a thorn in everyone’s side until the day it worked.
The launch itself taught me as much as the definition. The announcement date moved twice while the delivery estimates caught up with the scope, and then we reset it honestly and hit the reset date to the day: September 15, 2005, with the benefits reaching customers the following spring. The date was not arbitrary. A large cohort of customers came up for renewal that quarter, and the whole point, as my own notes from that year put it, was to minimize subscriber loss in the coming quarter: announce the value before the renewal decision, not after. I was not yet thirty, running the program for a client executive who was openly skeptical of consultants, and earning twice-weekly access to him anyway.
The two days after the announcement webcast are their own small story. Questions and escalations poured in from Microsoft’s field, and one consultant on my team was, for forty-eight hours, effectively the only subject-matter expert answering them. He turned that firehose into the program’s FAQ, which taught me a launch truth I still apply: the person closest to the customer’s confusion should be the one writing the answers.
What I took from it has outlasted every benefit we shipped. This was my first lesson in subscription economics: the durable question in any recurring-revenue business is whether the customer can see enough value to renew, and when the core product cannot carry that case, you engineer the value, through packaging, services, and proof, or you watch the renewals erode. I have re-run that exact play, with better tools and my own P&L, in every subscription business I have touched.
Writing my own next chapter, literally
In the spring of 2005, mid-program, something happened that rearranged my ambitions: Jonathan Tinter, the executive from the number-portability crisis, by then running e-commerce at the carrier that had acquired AT&T Wireless, offered me a director role on his team. I turned it over for weeks. I had never once thought about owning something myself, and suddenly it was the only thing I could think about. Being me, I wrote it down. That July I sent a memo to one of our partners, a document I still have, titled What I want. It took inventory of what I loved and was best at, creating new things, establishing trust fast, studying obsessively (“I will literally sit in book stores and study”), noted with a young man’s bluntness that pure delivery no longer stretched me, and proposed a new role for myself: supporting our communications and high-tech accounts on offshore and outsourcing strategy. Within weeks, I was doing exactly that job. I have re-read that memo many times, because the pattern it started, write the next chapter before you live it, turns out to be how I have run my whole career.
The role was the economics education I did not know I needed, and it kept me in the product seat Software Assurance had opened: this time the product was Accenture’s delivery capability itself, and my work was to package it, price it, and take it to market. Over the next year and a half I supported fifty-five clients on offshore and delivery strategy, from Microsoft to Level 3, advising on where work should go across Accenture’s global network, then forty-plus delivery locations and growing past fifty. That advice was not theoretical. I toured five delivery centers across India in ten days, Mumbai, Pune, Bangalore, Chennai, Hyderabad, negotiated staffing and rates with center leads weekly, and pushed the first work from our group into the new Dalian center in China over a client’s understandable nerves about a delivery location none of us had used.
The deals I drove directly came to nearly eight million dollars, tens of millions counting the wins I supported. At Level 3 I got my first engagement with my own name in the statement of work as project lead, an assessment that scored the client’s application portfolio for outsourcing readiness, and I later flew to India to teach it as a case study inside our own delivery organization.
The habits that formed in those years mattered more than the pipeline. My 360 review rated me in the firm’s top ten percent of career counselors, with a dozen counselees and mentees scattered across the practice, and my idea of a good evening was reviewing the threading and persistence architecture of Mike Sparr’s startup, for fun. Selling for its own sake was never what pulled me, and I said so at the time. The point was that senior clients were trusting real money to a plan because the person carrying it had run the delivery himself and would speak as plainly about risk as about upside. That trust, and the pricing, sourcing, and deal-shaping mechanics underneath it, is the commercial foundation everything later sits on. In early 2007 the firm resolved a career conversation we had been having by promoting me to senior manager and handing me the largest program of my Accenture life.
The last program, and the door out
I spent my final Accenture year as the program manager on an eleven-thousand-day custom development effort: a web-based quote-to-order system built to deliver real-time quotes on millions of parts to a distributor’s hundred thousand manufacturing customers, with a seventy-person team split between the client’s home city and Pune. Real-time quoting at that scale is a brutal engineering problem: pricing and availability logic that has to answer in seconds, against catalog and ERP data that was never designed to move that fast, rendered in a browser expected to feel like the green-screen terminals it replaced. It was the full weight of everything I had learned, estimating, offshore delivery, testing discipline, executive stakeholders, applied to the configure-and-price complexity at the heart of how industrial companies sell. The lesson from it travels to any industrial business: a digital transformation succeeds only when the new experience respects the pricing, availability, and ERP realities underneath it. It was heavy enough that even while running it I was still reflexively hunting the next deal, spending part of 2007 helping eBay think through scaling its own technology capacity in China. And it was, though I could not have articulated it yet, the last mile of a road I had outgrown.
Here is what I could articulate, because once again I had written it down. In 2007 I built a career evaluation for myself, on the firm’s own template, with my own copyright line on every slide, and treated my future like any other decision worth making well. The pull came first: the deck literally says my desire was to engage in product development, and every company on my interest list was a product company. Then I did the diligence the way I would for a client. I called my old clients, directors and VPs by then, traded compensation numbers over some laughing phone calls, built a spreadsheet, and found that with time value and equity accounted for, the client side could stand toe to toe with the partner track I had been aiming at since 1996. The analysis did not make the decision; it gave me permission to admit what I already wanted. Somewhere between standing up test environments in 2000 and reading architecture reviews on that last program in 2008, I had stopped wanting to advise on the machine and started wanting to own what it made.
So in 2008, when the program wound down, I took a leave of absence, my first real pause in eight years, and used it to figure out what ownership actually meant for me. Before the leave ended I had signed a tiny statement of work with my own name, not Accenture’s, on the signature line, three weeks of test-strategy consulting for a small development shop: my first invoice as just myself. And I had answered a call from a forty-person insurance software company that needed someone to run professional services, and pitched them a plan. That story, what happened when the Accenture playbook met a company with no playbook at all, and what I had to unlearn, is the next chapter.
What I take from it
Accenture gave me the trade: delivery at scale, offshore operations from the inside, the economics of technology services, and a technical floor built by hand, environments and databases and middleware, that I have stood on in every architecture conversation of the twenty years after. It gave me the conviction, paid for in Jackson, Mississippi, that you must test against reality before you ship, because the most dangerous moment in any launch is the one where you cannot. And it gave me, in a stack of memos and decks I wrote about my own career, the habit of treating myself as my own most important product: define the requirements, test against reality, ship the next version. In 2008 I shipped one: the consultant became an operator. Every chapter since is a release note.
This chapter is part of My Work, my career told one company at a time.