Blog

Part 3 of “Before I Go”, a career retrospective.

Sixteen years. That’s how long I worked for LA County before I understood what it actually meant to serve the public.

I didn’t arrive at that understanding in a meeting or through a training program. I arrived at it by walking into a lobby.

It was an ordinary morning at the Medical Examiner-Coroner’s Office, the kind where you come in, get your coffee, and start working through your list. Except when I walked through the entrance that day, there were about a dozen people clustered in the lobby, holding each other up. Some were crying. Others stood quietly with that particular stillness that grief produces in people who have run out of words. At the counter, one of the staff was at the computer looking up information, while an investigator stood nearby explaining the process of what happens next, what the family needs to do, and what the office can tell them and when.

I had seen public-facing service before. I just had never seen it look like that.

The sixteen years before the Coroner were a good career. A real career, even. I moved through Internal Services, the Superior Court, the Public Defender’s Office, and ISAB offices in Cerritos. I built things, solved problems, and got promoted. But those assignments shared a common feature: I worked in buildings where the public didn’t come. Internal Services was exactly what the name suggests, a support organization that served other county departments, who then served the public. The connection to the people LA County actually existed to help was real, but it was indirect, abstract, and easy to lose sight of on a busy Tuesday.

I understood, intellectually, that the systems I maintained mattered to someone. I just rarely saw who that someone was.

There’s a particular kind of drift that happens when you work that way for long enough. It isn’t negligence or indifference, just distance. You optimize for the system in front of you because that’s what you can see and measure. The person whose life is actually affected by whether the system works becomes theoretical. Someone you’d describe in a requirements document as a user or a stakeholder, but never actually meet.

The Coroner fixed that for me.

Getting the job required passing a biology tour first. The department wanted to make sure candidates could handle the environment before hiring anyone into it. The work was, to put it plainly, icky sometimes. You’d sit in meetings where the conversation moved casually from budget line items to bone saws to the particular challenges of cases that had been left too long. I wasn’t entirely sure I could handle it before I walked in. Fortunately, the person running the tour kept things moving and we didn’t dwell on any one thing for too long.

I took the job but I stopped eating red meat for about a year.

What I didn’t anticipate was how much the environment would change how I thought about the work. Families came to that lobby every day. They came because someone they loved had died, often suddenly, often violently, and the Coroner’s Office was the first place they had to go to begin understanding what happened. They came with questions, they came needing information that was hard to give, and they came in the middle of the worst days of their lives.

The IT systems either worked or they didn’t, and now I could see exactly what that meant.

For the first time in my career, I could trace a direct line from the work I did to the experience of a specific person in a specific kind of pain. When the case management system was slow, someone at that counter was slower to answer a question. When a database was unavailable, a family waited longer for information they had driven across the County to get. The abstraction I had been living inside for sixteen years was simply gone, and the work carried a weight it hadn’t before.

I’ve thought a lot since then about what those first sixteen years cost me in terms of perspective, and what they cost the people I was serving, indirectly, without knowing it.

I don’t think bad work gets done in government IT because people don’t care. I think it gets done because distance makes it easy to optimize for the wrong things. When you can’t see the person at the end of the chain, you optimize for the system. You solve the technical problem in front of you and call it done. You measure success by uptime and ticket closure rates and project milestones, because those are the things you can see.

The Coroner taught me to measure by something harder to quantify: whether the person in the lobby got what they needed.

I’ve argued ever since that every County IT employee should spend time in a public-facing role. Not a one-day field trip, but real time, long enough to feel the connection between what you build and who it affects. I held that view before hybrid work became a policy question, and I hold it more strongly now. I understand the arguments for flexibility and I support them for the right reasons. But something is lost when the people building and maintaining public systems never have to look at the people those systems are supposed to serve.

The lobby at the Coroner’s Office was not always a comfortable place to be, but It was, in a way I’m still grateful for, exactly the place I needed to be.

Part 2 of “Before I Go”, a career retrospective

I’ve spent 35 years inside government IT, and in that time I’ve watched the same cycle repeat more times than I can count. Someone discovers that government IT is slow. They write about it, speak about it at conferences, and build a startup to fix it. Then government IT remains slow, and the cycle starts again. What those observers usually miss is that the slowness isn’t the problem. In most cases, it’s the point.

The structures that govern how government IT operates exist for reasons that predate your frustration with them. Procurement rules exist because public money was abused. Civil service requirements exist because hiring was once done as political patronage. Oversight layers exist because, without them, accountability disappears. These aren’t bureaucratic accidents. They’re responses to real problems, encoded into policy over decades.

When you’re waiting 12 to 18 months to hire a single position, you’re not experiencing organizational incompetence. You’re experiencing the full weight of that history.

Here’s what that process actually looks like from the inside. You identify the need for additional staffing early in the year. A budget request goes in during October or November. After budget hearings and multiple reviews, if approved, it clears the Board of Supervisors in late April. The hiring process can’t start until the new fiscal year begins in July. Then the civil service process begins. The job listing is posted; applications are accepted; civil service exams are scheduled, taken, and scored; candidates are ranked; and finally a candidate list is certified and promulgated. That list is only valid for one year. Candidates are contacted, interviews are scheduled and conducted, and finally a selection is made pending a background check that can take three months on its own. If top candidates accept other jobs while you’re waiting, the list shrinks. If it expires before you hire, you start over.

The best case is 12 to 18 months from request to first day. That is the optimistic scenario.

I’ve had this conversation with department managers, executives, and people who were genuinely just trying to get someone hired. The reaction is almost always the same. They hear the explanation, they nod, and somewhere behind their eyes I can see them deciding that I’m either making excuses or describing a problem I should fix. They accept the answer. I’m not sure they ever fully believe it.

After three and a half decades, what I’ve learned is that you can’t fight the structure. You can learn its shape and plan around it. Start the budget request before you think you need to. Anticipate the exam cycle. Know which steps have flexibility and which ones don’t. The people who get frustrated and try to find shortcuts usually end up taking longer than the people who work the process. What seems like the easy way is usually the hard way. The hard way is usually the only way.

I’ve come to think of this as steering into the curve. It’s a concept loosely borrowed from physics. When space curves, the straight path isn’t the one that looks straight to you. It’s the one that follows the curvature. You don’t fight the bend. You work with it, let the structure do what it’s designed to do, and get where you’re going by following the geometry rather than ignoring it.

There’s also something worth saying about what the CIO of a government department actually controls, because the assumption from the outside is usually everything with a power cord. The reality in LA County is that the mainframe, the network, the firewall, and the servers are all managed by central county departments. When something goes wrong with the network, I’m making a phone call, not a configuration change. When a security policy conflicts with a business need, I’m navigating an interagency conversation, not issuing a directive.

LA County employs roughly 110,000 people. The District Attorney’s Office, where I serve as CIO, has about 2,000. We are one department inside a very large county government, operating under shared infrastructure and shared governance. The idea that an executive at the department level can simply decide to implement a technology and have it done, without procurement, without central IT involvement, without security review, runs into reality quickly. The County is not a small independent office. It is a large, complex, interdependent system, and IT reflects that.

I think about this when I look at how the County is approaching artificial intelligence. A tool that a private company might adopt in a week requires a county AI governing board review before any department can authorize it. That once struck people as excessive caution. I’ve come around to thinking it’s exactly right, at least for AI. The technology is moving faster than anyone’s full understanding of its implications, particularly in criminal justice contexts where the consequences of getting it wrong are serious. The same structural slowness that frustrated me for decades when I was trying to hire a programmer is, in this case, doing exactly what it was designed to do, which is slow down something moving too fast for proper consideration.

The hardest part of a career in government IT isn’t the bureaucracy itself. It’s the gap between what you imagined you could accomplish and what the system actually allows. I had ideas about how I wanted to improve things, move the organization forward, make the work better for the people doing it. Some of those ideas happened. Many didn’t, or happened so slowly and incrementally that it’s hard to feel the distance traveled. You look back across 35 years and wonder whether you moved the needle enough.

I don’t have a clean answer to that. What I know is that the people who fared worst in this environment were the ones who spent their energy fighting the structure rather than learning it. The ones who fared best understood early that working within constraints isn’t the same as accepting defeat. It’s a different kind of skill, less visible and less celebrated than the technical work, and in my experience more necessary than almost anything else government IT asks of you.

The curve is real. You can’t make it straight. What you can do is learn to steer.

Part 1 of “Before I Go”, a career retrospective.

In the summer of 1986, I walked into a building in Industry, California that looked nothing like a college campus. There was no quad or clock tower, only an office park with classrooms. I was 18, just out of high school, and almost certainly the youngest person in the room.

Most of my classmates at DeVry University were older and embarking on a second career in technology. They had work history, rent, families. I had a scholarship that covered tuition and fees, a commute from Norwalk, and a conviction that I wanted to work with computers that I’d been carrying since I first heard Majel Barrett’s voice coming out of the Enterprise computer.

The scholarship wasn’t automatic. I applied, submitted an essay along with my SAT score, and DeVry eventually announced I was the winner. My high school wasn’t pleased. Their preference was a traditional four-year university, and a for-profit technical school didn’t fit the picture they had in mind. I understood the concern, but I wasn’t interested in a picture. I wanted to write code.

DeVry’s structure was unusual. Every student in the Computer Information Systems program followed the same fixed schedule. We stayed in the same room all day; the professors rotated in. The curriculum covered mainframe tools like COBOL, CICS, IMS, and JCL, alongside courses in financial accounting, business writing, psychology, economics, public speaking, and a senior project. Faculty were required to have real-world industry experience, not just academic credentials. That distinction mattered more than I understood at the time.

My first trimester brought Professor Chang, who taught Pascal. He was brilliant and difficult to follow, and he taught by making you figure things out rather than by giving you answers. His accent was strong enough that the whole class struggled to keep up, which led to one of the more memorable moments of that first trimester. He was explaining bit manipulation — how a byte has eight bits, and how a byte can be divided into two halves. He kept referring to each half by its technical name, but what came out of his mouth, in that accent, sounded unmistakably like ‘nipple.’ Nobody said anything for a while. Finally, one of the more outspoken students asked him to write the word on the board so we could make sure we had the spelling right. He wrote “nybble.” The room collectively exhaled. He noticed our reaction, asked what he had been saying, and when we told him, he spent a few moments practicing the correct pronunciation — nibble, nibble, nibble — before it dawned on him what we had been hearing for the past several minutes. He was genuinely embarrassed. We thought he was great. What I took from his approach, beyond that moment, was a habit of mind: when you hit a wall, your job is to reason through it, not wait for someone to open a door.

I completed eight trimesters in roughly three years and graduated Summa Cum Laude. The practical curriculum turned out to be a significant advantage that I didn’t fully appreciate until I hit the workforce.

DeVry’s placement office found me my first job. Douglas Aircraft in Long Beach hired me as an Engineer in Quality Systems at $28,000 a year paid weekly. I chose it over other offers because the commute from Norwalk to Long Beach didn’t require freeway driving. That’s the kind of logic that makes perfect sense at 22.

Douglas ran on an IBM VM/SP mainframe, and the setup was unlike anything I’d encountered at DeVry. Each user got their own virtual machine running CMS on IBM’s VM/SP OS, which functioned as a personal workstation at a time when personal workstations weren’t yet a real concept. We used REXX for scripting, ISPF panels for screens, SQL/DS for data management, and GML/SCRIPT for documentation. The company also ran PROFS, IBM’s office system, which handled corporate email, messaging, and calendaring across the organization. It was a complete, production-grade technology stack that predated the tools most people associate with that era by close to a decade.

My work was building administrative database applications that supported the quality assurance function. One of these tracked airworthiness directives which are FAA safety mandates that manufacturers were required to compile and deliver with each aircraft. Without a complete set, the plane couldn’t be handed over to the customer. If the system failed, a finished aircraft sat on the tarmac. That’s the weight the work carried.

Every morning I walked through the manufacturing floor to get to my desk. Twenty-five minutes past MD-80s and MD-11s. The physical scale of a commercial aircraft when you’re standing next to one is nothing like seeing it from an airport gate. I watched landing gear tests on planes lifted off the floor on hydraulic jacks. The MD-11 tail stabilizers were too large for the hangar and had to be installed outside. I wore Douglas t-shirts on flights and got attention from flight attendants who wanted to know what I did for the company. One of those conversations led to a date that ended in complete disaster, but that’s a separate story.

Then the layoff came.

I knew it was coming. That didn’t make it better. My manager arrived with an envelope, worked through a checklist, walked me to the door, and took my badge. Under California EDD rules, a layoff of that scale required six weeks’ notice, but they released me from duties after two weeks with pay continuing for the remainder. I called DeVry’s placement office. The same office that found me Douglas now found me LA County.

But first, a brief detour. While waiting for the County offer to come through, I took a job at a small software distribution company in Culver City. The owner had a vision of building the Nordstrom’s of software. It was twelve people, a long commute, rigid lunch rules, and an expectation that you’d stay late without asking questions. I had already interviewed at the County during my first week there. When the County offer finally arrived in late September, I gave my notice and served two of the best weeks of my working life. I came in when I felt like it, left when I was done, and genuinely did not care about much of anything. I didn’t understand at the time how precisely that feeling would echo something I’d feel 36 years later, but that’s getting ahead of the story.

I arrived at LA County’s Internal Services Department as an Assistant Programmer Analyst in 1990. I was part of a large training cohort, about 30 to 40 people in my group, with three groups total recruited from outside. Most of them were fresh from Cal State schools, trained in UNIX and theoretical computer science. I already knew COBOL, JCL, and IMS cold. Much of the training was redundant. The pay was $34,000 a year, more than Douglas. The commute from Norwalk to Downey was short.

What I found at my desk was a different story.

The County ran IBM 3270 terminals, massive machines with heavy keyboards. At Douglas I had been working in a virtual machine environment that gave every user the computing experience of a personal workstation. The County 3270 was a significant step backwards from everything I’d just left, and the difference hit me the first week.

The colleague in the adjacent cubicle had arrived in the first training cohort, a few months before me. Her terminal happened to be located on the desk I’d been assigned which, when you think about it, made it legitimately hers before I ever showed up. She would come to my desk to use it, and I’d wander the building looking for an open machine, or sit in a shared terminal room with about 15 workstations and most of the department competing for time on them.

Nobody at the County seemed to find this surprising.

There’s a version of this story where I’m the hero of it — the hotshot who showed up knowing more than his colleagues and had to endure conditions unworthy of his abilities. That’s not the story. The terminal situation was just a symptom of something structural. Government IT in 1990 was constrained by budget, procurement timelines, and a set of priorities that had nothing to do with giving any individual employee the best tools. I would spend the next three decades learning how those constraints work, where they come from, and why they’re harder to change than they look.

That’s the subject of a different article.

The question I keep returning to about those early years is simpler: what do you do with an advantage you didn’t ask for? DeVry gave me a running start. Douglas confirmed it was real. The County reset the clock, at least tactically.

What you do, it turns out, is show up anyway. You learn the environment you’re actually in, not the one you were expecting. And you wait for the work to start meaning something.

For me, that wait took sixteen years. But that’s also a different article.