Staying Human in the Age of AI: What Tech Leaders Need to Preserve

Now, I was thinking the other day, I don't know when the first time I used AI was. I don't remember the prompt. I don't even particularly remember having this, aha, this is the future moment. I co-host a podcast called Compressed FM. I went back and looked, and episode 130, which aired April 12th, 2023, we did our first AI episode called Chat GPT and AI, initial reactions. Funny to go back and listen to it. We spent part of the episode explaining the difference between OpenAI and Chat GPT and what 3.7 turbo versus GPT format. And it makes me laugh now because these terms are common knowledge, and they almost seem obvious. But since recording episode 130, now it seems like we talk about AI almost every week.

My point is for something that has become so ubiquitous, it had a modest-ish start, but it took over, and it took over quickly. Like most people, I think my favorite use case is asking it to do a task I really don't want to do. And a lot of those small menial tasks, AI has gotten so good. It can do a lot of that work just as good, if not better than I can. It can definitely do it faster.

So two weeks ago, Raycast announced their GitHub Copilot extension. I quickly installed it and fired off several tasks from my backlog. I was able to ask it to do five different things all in parallel on my family, and I sat down to eat dinner. That's kind of the dream, right? Well, at least some form of the dream anyway. In some ways, it's commoditized developers. It's definitely made things like building web applications easier, democratizing the whole process. Did you know there's only 0.2 or 0.5 percent, that's half percent, 1 percent of the world's population that can code.

That's about 20 million people. But if you look at some of these AI services like Repl.it, they're reporting 34 million users. Granted, there's probably some overlap here of people that can code and people using Repl.it, or just staying honest, Gemini does say that that 20 million is professional coders. But the point is that Repl.it has bigger numbers. The pool is widening and more people can code now than ever before. AI makes it more accessible and the numbers are only going to continue to trend in that direction.

So if more people can code, if more robots can do what we do, what makes us so special? And I feel like that's kind of the fear that everyone is facing right now. It's this weird paradox. On one hand, AI is making code itself more commoditized. The actual writing of functions, the crafting of algorithms, even complex refactoring, all of it becomes literally point and click easy. But on the other hand, and this is a paradox, our technical decisions are becoming more complex, not less.

So think about it. When you could only choose from technologies your team already knew, decisions were simpler. When implementing a feature meant weeks of careful coding. You thought twice about scope creep. When debugging required deep system knowledge, you built teams around expertise. But now, now AI can help your team adopt almost any technology. Now features can be built in hours instead of weeks. And now debugging often means asking AI to interpret error logs. The question isn't what technology should we use anymore? The question is, what kind of team do we want to become? And AI can't answer that for us. I think the answer is simpler than we make it out to be. Our value isn't in the code we write anymore. It's an understanding the human complexities that AI completely misses. Things like team dynamics, values alignment, and how we make decisions as a culture. These aren't soft skills. These are the hardest skills. Because it turns out, while AI is incredibly good at generating code, it's terrible at reading the room. So let me give you an example of what I mean. And I'll be honest. This one took me a while to figure out.

So I was leading a team and I had this junior developer. Smart guy, good technical skills, great communication. But he seemed to need a lot of guidance. Every task he'd come to me with questions. How should I approach this? What do you think about this solution? Can you review this? And I'll admit I was getting a little frustrated.

I kept thinking, why can't he just take a task and run with it? Why doesn't he show more initiative? I want him to have autonomy, take ownership. So I tried to give him more space, more independence. And I thought I was helping him grow. But instead of thriving, he seemed to struggle even more. The quality of his work was OK. And honestly, our working relationship felt tense at times.

For months, I thought this was a performance issue. Maybe a skills gap. Maybe he wasn't ready for more responsibility. And I was looking at this through a purely technical leadership lens. How do I get better output from this developer? Now, imagine if I'd asked AI for help with this situation. How do I get a junior developer to be more independent? I probably would have gotten some great advice. Set clear expectations. Provide structured feedback. Create growth plans. Maybe even specific techniques for building confidence and autonomy. All technically sound leadership advice, but it would have missed the core issue entirely.

AI can suggest management techniques, but it can't read the underlying dynamics. It doesn't understand that what looks like a performance issue might actually be a values mismatch. AI can generate leadership frameworks, but it can't navigate individual personalities. It doesn't know that some people thrive with independence while others do their best work through collaboration.

AI can optimize processes, but it can't align human values. It has no concept of the fact that both autonomy and teamwork are both valuable. They just don't always play nicely together. Because here's what I eventually discovered. This wasn't a technical leadership problem at all. I valued independence and autonomy. He valued collaboration and teamwork. Both are great values to have until they come head to head.

I was trying to solve a human complexity problem with technical leadership solutions. And it wasn't working because I was solving the wrong problem. This is what I mean by the human complexity layer. Every leadership challenge we face gets filtered through human perspectives and values always. Some people on our teams value independence. They want to figure it out on their own, own their own solutions, prove they can handle it. And others value collaboration. They want to work together, get input, and make sure they're on the right track.

Some prioritize speed and decisive action. Others prioritize thoroughness and getting it right. None of these things are wrong, they're just different. But when they clash, what looks like a technical or a performance issue is actually a human values issue. This is the complexity layer that AI completely misses. And this is where we as tech leaders add irreplaceable value.

We don't just manage tasks and deliverables, we navigate those human dynamics that make or break our teams. For a long time, I thought all of this human stuff was just fluff, something companies talked about because it sounds nice. But then I tried something I was kind of skeptical about, actually, to be honest, I'm not even sure what provoked me to do this. But at the risk of sounding like a BuzzFeed article, it changed everything.

So I was reading this book, Engineering Leadership for the Rest of Us by Sarah Drossner. It's a great book. I can't recommend it enough. There's lots of practical advice. One of the first chapters is about values. And I'll be honest, I kind of rolled my eyes. Team values. This sounds like corporate HR fluff, like those posters in conference rooms that say innovation or excellence that nobody actually pays attention to.

Of course, every team in the world wants to innovate with excellence. We're engineers. We solve problems. We write code. We ship features. Do we really need to sit around in a circle and talk about how we feel about teamwork? But OK, so here I am reading this engineering leadership book by Sarah Drossner, whom I've respected from a distance for years. And she's talking about values.

So here's a quote from the book. She wrote, Working to understand values isn't a silver bullet to solving every problem, but it affords us a deeper sense of where to start when building understanding and trust within a group. Unpacking a person's values with them can also help us understand what drives and motivates them. And the core of working together is mutual understanding. I love that. The core of working together is mutual understanding.

So I thought, what do I have to lose? Worst case, we waste an hour and confirm that this values stuff is indeed corporate fluff. So in a team retrospective, I decided to bring up our values. I kept it simple. We had company values that everyone on my team was familiar with, but we also have individual values. So in the book, Sarah has a list of about 40 values to start with. I used her list and asked everyone on my team to put their initials next to the values that they resonated with. And why? Give us some context. What motivates you and makes you the most effective and fulfilled in your work?

And then we went through each value and commented on the ones that we put our initials next to. It was fascinating. Some people talked about the way that they were brought up or adversities that they had experienced. And then we got to my junior developer. He talked about how much he valued collaboration, how he felt most confident when he could work through problems with others. He could hear their ideas and get input and validation along the way. And that's when it hit me. This wasn't about him being needy or lacking independence. This wasn't about me being a bad mentor or him being a slow learner. I valued autonomy and independence.

I ran my own company for seven years. I felt most effective when I could take something and run with it. I could figure it out on my own, prove I can be trusted and handle it. He valued collaboration and teamwork. We're better together. Both are great values. Both lead to good outcomes. But in our case, they were completely at odds with each other and how we were trying to work together.

Think through the conflicts that you've had on your own teams. Think things that you may have thought were technical disagreements or personality clashes. Maybe in code review, you had someone that prefers minimal high-level feedback. LGTM looks good to me. But another member on your team will leave detailed line by line comments. It's easy to interpret this one person as being lazy and this one person as being nitpicky. But what if it's actually about values?

One person values trust and autonomy. They assume, you know, what you're doing looks good to me. The other values thoroughness and precision and knowledge sharing. They want to help you grow and catch potential issues. Maybe this shows up in your own team's approach to new features. One person wants to spike out a solution quickly, see if it works, and then iterate. But another team member wants to spend more time upfront understanding requirements and planning out the architecture. In both of these scenarios, neither person is wrong. They just have different values about how to approach uncertainty and risk.

They just have different values about how to approach uncertainty and risk. And here's what was so powerful about this realization. It's just everything from judgment to understanding. Instead of thinking, why can't they just? I started thinking, oh, they value this. So, of course, they're going to approach it this way. Instead of seeing resistance or difficult personalities, I started seeing people trying to work in ways that aligned with their values. It's like a colorblind person putting on colored glasses for the first time. Suddenly, they realize their shade and nuance and all of these interactions that seem frustrating or confusing suddenly made perfect sense.

Once you start seeing this pattern, you realize we've been having the wrong conversations. We keep debating the right technical approach when we should be talking about what we value as a team. So I started changing how I approach technical decisions instead of just asking the traditional questions. What's most performant? What's most maintainable? What scales the best? I started asking different questions. First, what does this choice say about what we value? Second, how does this support different team members growth? Third, what kind of team culture does this reinforce? These aren't questions AI can answer for us. They require understanding the humans on our team, their values, their growth paths, their working styles.

Let me give you another concrete example of how this played out recently. So I'm part of the Redwood JS core team, and we faced a significant architectural decision. Recently, we pivoted away from GraphQL and we rebuilt the entire framework on top of CloudFlare Services, initially leveraging D1 for our database layer. Now, I absolutely love D1. It's fast, it's simple, it integrates beautifully with the rest of the CloudFlare ecosystem. But we discovered there were concerns about D1 and GDPR compliance. There's kind of unclear data storage locations and potentially cross-border data transfers. Now, to be clear, CloudFlare is addressing these concerns. And some of the burden does fall on how developers configure and implement their solutions. But here's where the values come into play. As framework authors, we could have said, this is a configuration issue. Developers can handle GDPR compliance themselves. And that would have been technically correct. But my team, many of whom are based in South Africa, they value inclusivity. They prioritize users with slow internet connections, smaller budgets, and, yes, developers who need to comply with strict data regulations without becoming legal experts. So, we made what seemed like a huge architectural change.

We shifted to SQLite databases running in durable objects, where you can process data strictly within specific geographical regions. Was this more complex? Not necessarily, but did it slow us down in the short term? Yes, we had to provide an alternate solution for a feature that was already working. So, from a pure technical efficiency standpoint, it might not have been the optimal choice. But when you understand the why behind the change, what we value and what we prioritize, it puts everything in a different perspective. We weren't just making a technical decision, we were making a decision about what kind of framework we wanted to build, and what kind of community we wanted to serve.

And you know what? When you start understanding how these changes align with our values of inclusivity and global accessibility, it's hard to resist. It's easy to get buy-in because people understand how the decision supports the kind of project we're trying to build. And this is what I mean about human-centered technical decisions. And this is exactly the kind of thinking that becomes more valuable, not less, as AI takes over more of our coding tasks.

So, how do you actually do this on your team? Let me walk through what works, or at least what worked for me. First, just keep it simple. I literally just brought up values in our team retrospective. There was no big announcement, no formal workshop, just, hey, I've been thinking about how we can work better together, and I want to try something. I used Sara Dressner's list from her book. There's about 40 different values like accountability, autonomy, collaboration, fun, growth, and preparedness. You can find similar lists online, I'm sure, or maybe this is the question you can ask ChatGPT.

Honestly, just brainstorm a few values that seem relevant to your team. Give everyone the list and ask them to put their initials next to three or four values that resonate with them. Listen for the stories behind their choices as they share. Watch for big gaps in values, especially between you and those you closely work with. Understand your team's values to apply them in various aspects like code reviews, architectural decisions, and onboarding new team members.

For future tech leaders, understanding people becomes crucial as AI improves in code writing. Practice discussing values and priorities, asking what they are optimizing for instead of focusing solely on technical solutions. Consider resistance as information, not obstruction, and inquire about the intentions behind technical disagreements. Teams aligned with their values make faster decisions, implement them smoothly, and adapt effectively to change. Building and leading value-aligned teams will be a significant advantage in a world where technical skills are becoming standardized.

When implementing value-aligned practices, encourage open conversations about values within your team. Address different optimizations by team members, ensuring everyone understands the reasoning behind decisions. Recognize that AI enhances coding but human interactions and team dynamics are critical for success. Teams that grasp their values and integrate them into technical choices will excel in decision-making, implementation, and adaptation, ultimately creating a cohesive and enjoyable working environment.