Dylan Beattie: “What even is leadership anyway?"

[00:02:08] Welcome and Introduction to Tech Leaders Launchpad

Andrew Murphy: Hello, everybody, and welcome to the Tech Leaders Launchpad livestream. If you're new to this series, I'm Andrew Murphy—tech leadership trainer and coach. I started my journey 20 years ago as an engineer; since then, I’ve learned to be a leader, but back then there weren’t many resources—no books, no blogs, and definitely no livestreams to help me do my job better. I had to learn the hard way, and after 15 years of that, I decided to spend my time teaching and helping people become better tech leaders.

I also love to share the people who are my own coaches and mentors, the folks who helped me become better—I want to get their knowledge and experiences as widely shared as possible. So, with me today, I have Dylan Beattie. Dylan, do you want to say hi and introduce yourself?

Dylan Beattie: Hello, good folks! How's everybody doing? I’m Dylan. My little strapline is “Dylan does fun things with code, comedy, video, music, technology and then travels around the world talking about it.” Honestly, I struggle to summarize my own career better than that. I’ve been a developer most of my life—started programming on an Amstrad 128 when I was about 8, got into MS-DOS, Windows, early web, HTML in the early ‘90s. I went from webmaster to application developer, technical team lead, distributed systems architect, a short stint as a CTO... then the world changed in 2019–2020. Now, I balance technology, entertainment, music, and speaking—sometimes teaching, sometimes writing code, and sometimes just turning up and talking about whatever I think is interesting. If you’re a technical speaker, it’s a lovely point to get to, just being told: “Do anything you want.” So, welcome to the stream, folks. Thanks for having me.

[00:07:06] The Value of Context and History in Tech

Andrew Murphy: Yeah, you’re welcome! Dylan, I’ve seen you do many talks over the years, and I love the eclectic nature of what you do. It’s nerdy, but not “here’s the latest ReactJS thing.” You go deeper. You nerd out the nerds.

Dylan Beattie: What I realized—especially with the latest ReactJS thing—is, that talk may have a shelf life of six weeks if you’re lucky. The event cycle for most conferences is around three months from confirming speakers to delivering talks. Either you say “put me down for a JavaScript talk” and scramble up something fresh, or by the time you speak, it might already be deprecated.

For professional developers, there’s as much value in context and history as there is in “this line of code will fix your bug.” There’s a kind of timelessness to it. I really enjoy our industry’s heritage and folklore—stories people swap over coffee at conferences. The first book I know that called itself “software engineering” said right up front, “Right now, this is all folklore.” We figured it should be written down.

I enjoy how sharing what we find interesting sometimes coalesces into “oh, this is important.” In software, we cycle through innovations; we’ve come full circle—serverless now looks a lot like Perl CGI scripts in 1997, just more efficient thanks to per-second billing. The frameworks and languages evolved, but every new dev cycle is built on top of stuff that’s been around for ages. Context helps us see our place in the ecosystem and what might become significant in the future.

[00:10:47] Different Levels of “Magic” in Technology and The Importance of Understanding

Andrew Murphy: Scott Hanselman talked about how everything is magic to different levels. Using electricity as an analogy: you plug something into a socket and it works—that’s magic for a lot of people. But you might know that wires go back to a consumer unit, then to a distribution hub—more magic. The deeper your understanding, the more you can troubleshoot at your own level; you should always understand at least one or two levels below where you operate.

Dylan Beattie: Hanselman does great stuff with this. Joel Spolsky wrote about “Leaky Abstractions”—all abstractions leak. My favorite analogy is airline travel: airlines want you to think you’re just in a floating cinema. When turbulence hits, the “magic” leaks. The same is true with electrical sockets—at one end is your hairdryer, at the other, a nuclear reactor. We need abstractions to function, but understanding some of what’s under the hood helps.

The same applies to Linux, too—sometimes, it’s like every house built their own electrical system. No two plugs are the same, and it’s a pain to adjust to that when we want standards.

[00:14:34] Why Tech Leadership? Stream Q&A Info and “What is Even Leadership?”

Andrew Murphy: That’s a good analogy. We’re not here to talk about that, though it’s interesting. Today, it’s all about tech leadership. We’ll have a chat, I have some questions, and we want to hear from the audience—post questions in the chat on YouTube, LinkedIn, or Twitch, and we can answer them live. If you have to leave early, the recording is available, and if you’re watching on LinkedIn, I suggest you switch to YouTube for a better experience.

So, Dylan, when we met up over Taiwanese fried chicken, I asked: if you could implant a message into every tech leader’s brain, what would it be? I’ve gotten some great answers—Rands said “delegate until it hurts,” Phil Haack said, “treat your team as active volunteers.” And you said: “What is even leadership anyway?” Why?

Dylan Beattie: The question you asked—about “engineering managers”—really clicked with me. There’s a fundamental incompatibility between engineering and management. Complexity theory and the Cynefin framework teach us: there are problems to be solved and problems to be managed. Solved problems can be engineered—like JPEG compression, complicated but not complex. But management is about dealing with complex problems—like city traffic, unpredictable every day.

[00:16:54] Engineering vs. Management: The Peter Principle and Career Pathways

Dylan Beattie: So “engineering manager”—here’s my take: the industry often promotes great engineers based on the old notion that career progression equals managing people, not systems or strategy. And suddenly, someone who excels at code is now responsible for people—a huge mismatch. That’s the Peter Principle: you promote someone to their level of incompetence.

IBM even had a system where you could try management, and if it didn’t fit, return to engineering and keep the pay bump. Nowadays, “IC” (Individual Contributor) is recognized as a valid, rewarding path. Seniority doesn’t require managing people anymore; you can lead systems, architecture, products instead.

So, the message I’d implant in every engineering manager’s mind: Make up your mind—are you engineering or managing? When I and others have tried to do both, it’s rarely satisfying for anyone. The point where this breaks down sometimes only becomes obvious as you scale—a solo dev or small team can brute force things, but as teams grow, yesterday’s approach stops working. At, say, 15 developers, you really need different structures.

[00:23:56] Aligning Team Needs and Personal Passions as You Scale

Andrew Murphy: There are real intersections here—what someone enjoys and is good at, what the company and team need—and those don’t always overlap as the team grows. When you hit 15 people, what worked and felt good before may now be totally misaligned. No one is wrong, but the system’s needs changed.

Dylan Beattie: Yes—and another thing is, for creative “maker” types, when they’re given the power to decide what gets built, it’s hard to be truly impartial. I’ve built things because they were cool, not because the team needed them. Optimization projects, hunting for incremental improvements—they can all be distracting if they’re not prioritized relative to what the team and company actually need. The person spec’ing direction shouldn’t necessarily be the one doing the building—they’ll be tempted into rabbit holes that aren’t always valuable.

[00:28:59] The “Trifold” Model of Leadership in Consultancies

Andrew Murphy: I’ve seen this play out both as a SaaS company CTO and as a consultancy director. In consultancies, I used what I call the “trifold leadership” model: people, project, and technology leadership were distinct roles. People leadership is all about caring for your fellow “fleshy sacks of meat”—supporting, enabling, and listening. Technology leadership is ensuring work is built well and appropriately. Project leadership is about progress, delivery, and communication. If you’ve got someone in charge of each, things go well, but they don’t have to be the same person.

[00:31:15] Kipling’s Six Questions and Reductionist Problem Solving

Dylan Beattie: That reminds me of Kipling—“what, who, when, why, where, and how.” In a tiny team, one person does it all. As you grow, you split the roles, and each question can become someone else’s responsibility—the who and where go to people managers, the when and how to tech leadership, the what and why to project/product. When things go wrong, troubleshooting which “question” is at fault can clarify things. Sometimes reductionism helps you find the mismatch.

Andrew Murphy: Models like that help me spot where the conflicts come from. I like to boil issues down to the basics and build them back up—often, you finally spot the root of a problem.

[00:33:05] On Reductionism, Scrum, and Survivorship Bias

Dylan Beattie: Reductionism is most useful for troubleshooting, but not always when things are working. The scrum industry, for example, tried to break down great teams into routines and rituals, but missed that standups, ceremonies, etc. are the emergent properties of a great team—not the cause. If it’s working, don’t take it apart!

Andrew Murphy: There’s survivorship bias, too—we see successful teams and copy their behaviors, but don’t always notice failure cases where those same practices didn’t work. What’s missing from the data?

Dylan Beattie: The people who failed at 15 out of 20 projects using scrum didn’t get to write the playbook. Survivorship bias is real.

[00:35:34] Why We Need More War Stories and Learning From Failure

Andrew Murphy: Someone should create a “fail” conference of just war stories from projects that didn’t work. If it doesn’t exist, let’s start it.

Dylan Beattie: I love talks that share what went wrong. Once, a case study went off the rails between its conference acceptance and delivery—the speaker turned it into a “here’s what failed and why.” We learn more from other people’s failures—it’s cheaper and leaves fewer scars.

[00:36:04] Tech Leadership: Real World “War Stories” and Lessons Learned

Andrew Murphy: Speaking of things going badly, let’s get back on topic. Dylan, tell us a war story—either as a leader or about a leader you had. What went wrong and why?

Dylan Beattie: That’s a tricky one—some bodies are still fresh, so to speak! But, as is public, I was CTO at Skills Matter in London when they went into administration in 2019. They were successful at in-person events, but events don’t scale like technology does. The industry’s obsession with exponential growth didn’t really fit—and by the time the realization that “we’re an events company, not a tech company” sunk in, it was too late. In this kind of abstraction, it's critical to understand the fundamental mechanism of your business.

[00:38:18] Running a Business vs. Practicing Your Craft and Administrative Overheads

Andrew Murphy: I’ve found, being self-employed, that most of my time is spent not doing what I’m best at (coaching and training), but just running the business. That was a real eye-opener.

Dylan Beattie: I might be an outlier, as admin is about 10% of my time. My company is just me, so as long as I handle accounts and taxes, I’m free to do what I want most days. But even so, when you’re self-employed, you have to constantly check if you’re working on the right things—does this make money, is it important, is it fun? Employees don’t necessarily see the costs or opportunity costs of spending weeks on the wrong projects, but independents feel it right in the bank balance.

Also, I kept a mental spreadsheet for hires—good devs often double their salaries in five years, and employers need to plan for that or expect to lose talent to greener pastures.

[00:42:49] Should You Be a Manager? A Decision-Making Framework

Andrew Murphy: I want to give our viewers actionable takeaways. We talked about how some folks get into leadership and maybe shouldn’t stay—not because they can’t, but because it’s not what they love. What framework would you recommend for someone deciding between continuing down the IC (individual contributor) path or switching to people leadership?

Dylan Beattie: The most important thing—be transparent with yourself and your coworkers about what you will stop doing. The biggest struggles come from people who want to keep coding even after moving into management. For a dev, coding is often core to their identity. Management means you will have to stop writing code, and you’ll need to resist the pull of “I know how, I’ll just do it.” It’s easy to take things on optimistically, but the reality is filled with meetings, context switches, and less visible contributions—sometimes you feel like you didn’t do anything, yet everything depends on others’ delivery.

So: ask yourself, “Are you ready to not code? Are you ready to step back completely?” If you’re only saying yes for the raise or title, that’s a red flag.

[00:48:29] The Manager’s Manager’s Role; The Challenge of Motivation

Andrew Murphy: It’s the job of the manager’s manager to help people realize if this decision is or isn’t right for them, or not put them in that position in the first place. If you don’t care, or don’t enjoy leadership, that’s a problem—and training can only solve lack of knowledge, not lack of interest or care.

[00:49:11] Seniority: Four Different Kinds and the Karaoke Analogy

Dylan Beattie: Something we’ve noticed is we use “leadership” and “management” interchangeably, but I think of four types of seniority: expertise, mentorship, leadership, and management. Sometimes one person embodies more than one, but as a dev it’s critical to know where you get each. Management is practicalities; leadership is inspiration and vision; expertise is technical depth; mentorship is personal growth.

A mentor tells you when it’s time to leave. Great leadership and management are not always the same. In karaoke metaphors: leader gets everyone excited, manager handles logistics, expertise is the singing pro, and mentor keeps you from making a drunken fool of yourself. All have unique value.

[00:53:01] Multiple Engineering Pathways: Clarifying Roles

Andrew Murphy: I love that framework. There’s a great article from Pat Kua about “the trident” engineering career paths: engineering management, staff/principal engineering, and pure IC/expert. Across your four elements: engineering managers embody leadership and management; staff/principal engineers combine leadership and expertise; and pure ICs are expertise and mentorship. The key difference for staff/principal engineers is helping the system scale—not just building, but enabling others… which is both expertise and leadership.

Dylan Beattie: Yeah, I like that. That adds clarity.

[00:56:38] Value, Money, and the Importance of Visibility

Andrew Murphy: If you want to get paid more, you must provide more value. If your work isn’t more valuable, the company won’t pay you more.

Dylan Beattie: I’d push back a little—it’s possible to get paid as much for creating the illusion of value as for actual value, especially in VC-backed tech. Sometimes people get credit or rewards for optics, not output.

Andrew Murphy: And the reverse: if you provide huge value but nobody knows, it’s the same outcome as providing none. Personal branding is partly about making sure your work is seen; otherwise, you might lose out.

Dylan Beattie: Absolutely—there are folks who do nothing and don’t get recognized (fair); those who do great work and don’t get noticed (tragic); those who do and get recognized (ideal); and those who don’t do anything but harvest recognition anyway (hustlers, hype merchants). Tech bubbles—Ethereum, blockchain, and now AI—are full of people chasing the illusion of value. Be aware some are just riding the hype train, and “recognition” is as much part of advancement as genuine contribution.

[00:59:22] Wrapping Up and Final Thoughts

Andrew Murphy: That’s a powerful point—investors jump on hype trains, not value; recognition is as important as reality. Thank you so much, Dylan, for a wide-ranging conversation—both in breadth and depth. Thank you for spending the last hour with us.

Dylan Beattie: I had “lacks focus” on school reports, and nothing’s changed unless you put some gnarly JavaScript in front of me.

Andrew Murphy: Next week, we have Scott Hanselman, and we’re talking about why you should share what you know—via blog posts, talks, whatever you can do to get your knowledge out there. Don’t forget to subscribe or book a chat. Dylan, you have a YouTube channel and podcast, right?

Dylan Beattie: If you Google “Dylan Beattie,” it’s all me now, and for some reason Google thinks I’m a musical artist, which is fun.

Andrew Murphy: My name's common—still battling up the Google rankings, but getting there!

Dylan Beattie: (Funny story about demographics and the spike in Dylans named after Beverly Hills 90210 and before Columbine. For a while, a Facebook group brought together all the Dylans Beattie globally, mostly 15-year-old boys from Scotland; it was a window into an era.)

Andrew Murphy: Andrew is making a comeback, so I’ll have more competition for usernames soon. Thanks everyone!

Dylan Beattie: Thanks for tuning in, folks.

Andrew Murphy: See you next time on Tech Leaders Launchpad Livestream. Goodbye!

Dylan Beattie: Bye bye.