Think Like a Journalist
Everything I know about being a great engineering leader, I learned from being a journalist.
For the first two years I spent working as a software engineer, thoughts of my “otherness” were all-consuming. I don’t mean “otherness” in the sense that I’m a woman in tech. I mean that I’m a career switcher.
To live with myself, I immersed myself fully in web development, so that no waking hour was free from HTML, CSS, or JavaScript. I worked late on weeknights. I taught front-end workshops on the weekend. I read books, attended conferences, listened to podcasts, and did tutorials in my spare time. I solved interview-style coding challenges “for fun,” which is a normal and totally enjoyable thing to do.
I have a lot of compassion for who I was back then. I did all of this because I was desperate to be seen as a “real” developer. After all, I didn’t have a degree in computer science; I had learned how to code in a bootcamp. Rather than seeing it as a massive success that I landed multiple job offers before my bootcamp had even ended, it left me paralyzed by fear. I was miserably insecure and terrified that someone would find out my biggest secret of all: I was really just a journalist who had learned how to code.
Being a journalist defined my teens and early 20s, a time when I believed my identity was in my work. After all, I got my start in journalism when I was just 14 years old. By the time I graduated high school, I felt like my path as a journalist was ordained and set; I never even considered studying anything other than journalism in college.
My sophomore year, I lived with a friend who was majoring in electrical engineering. Every morning she’d head off to her computer science courses, and every evening I watched her program circuit boards; I just assumed that computer science meant hardware — and I wasn’t interested in that. Never great with my hands or anything physical (so I told myself), I preferred subjects where I could advance and succeed with my brain.
I loved being an editor for the school newspaper, and by my junior year I was running the whole thing as editor-in-chief. During that year, I realized that I truly loved editing, even more than reporting. Don’t get me wrong: There’s no thrill like a byline, seeing your name above your work in print. But I found the process of reporting — gathering information, talking to sources, synthesizing the facts — grueling and exhausting, often both mentally and emotionally.
Editing gave me life in a way reporting never did. I loved the process of assigning stories and working with writers to revise their drafts and bring out their best work. I loved seeing a rough first draft become a masterful narrative with my help. I loved knowing that I had a hand in crafting the stories that people talked about on campus. As it turned out, being a leader in the newsroom was what I truly loved.
In the professional world, though, one does not simply become a newspaper or magazine editor; young journalists typically have to prove their chops as a writer for years before being promoted into management. I had no interest in doing that, especially once I arrived in D.C. and realized I was up against journalists who actually enjoyed everything I found terrible about reporting (think: congressional correspondents, political breaking news reporters, etc).
Around that time, I started learning how to code and, to my great surprise, there were no circuit boards involved. Instead, I found languages with rules and syntax, not dissimilar from grammar rules in a spoken language. I found my flow in debugging and reviewing PRs. It turned out that working in an engineering team and writing code was incredibly similar to working in a newsroom and writing the news, except that I almost never had to talk to strangers.
By the time I landed a job as a software engineer at The Washington Post, I was ready to leave my days as a journalist behind for good in order to fully complete my metamorphosis into a “real” developer.
I’m not sure the complete metamorphosis ever happened, but what I do know is this: The longer I’m in engineering, the less I feel compelled to hide my background as a journalist. I’ve come to see it not as a weakness, but as an advantage. I am a better engineering manager because I think like a journalist.
Journalism taught me how to handle uncertainty and how to make good decisions when I don’t have all of the information. We often think that being able to perform well under pressure is an innate talent, but it’s not; it’s a skill. Journalists build this skill — and are forced to excel at it — because they are constantly facing breaking news events where they don’t have all of the information and still need to act.
Watch any reporter and you’ll see her respond well, because journalists accept and expect that breaking news is going to happen, typically at the most inconvenient time. When it does, it is a journalist’s job to make sense of things, gathering the necessary facts and creating clarity for readers.
This is true in software engineering teams as well. Whether it’s a P0 outage in prod or a new executive steamrolling the team’s roadmap with their initiative, engineering leaders often are called upon to respond in high-pressure situations. Yet, this is where many of us struggle; we’re unprepared for the unexpected. We think it shouldn’t happen or that it’s our job to prevent things from occurring within our team.
As a result, many engineering managers are stuck in a reactive mode — fire fighting, triaging, and trying to get out from under deadlines. The problem is, reacting is what we do on instinct; it’s often an impulsive or emotional response to try and control a situation. Our reactions often are not thoughtful, deliberate, or well informed.
The reality is, engineering managers would do well to think more like journalists. We need to adopt a better mindset, one that accepts the unexpected and inconvenient. No matter how well we plan, how carefully we roadmap, how hard we work, there will inevitably be dumpster fires, and that’s okay. We need to get comfortable with the idea that it’s not our job to prevent all disruptions, but rather, to mitigate what we can and respond well to the situations we can’t avoid. Engineering — and life — are full of them.
Unbeknownst to me when I was a college journalist, I built the skills I needed to succeed not just as a reporter, but as an engineer and leader of cross-functional teams. I didn’t study computer science, but I did study everything to which I attribute my success in this field.
It’s been nearly 10 years since I switched careers, and I’m still thinking like a journalist who knows how to code. I don’t think I’ll ever stop.
Read more about how to think like a journalist:
