
I’ve been thinking a lot lately about what it means to be an engineering leader right now. Not in a doom-and-gloom, “*AI is coming for our jobs*” way, but in the quieter, more uncomfortable sense of realizing that some of the things we anchored our careers to are shifting under our feet.

There’s a lot of noise about tools writing code for us. Copilots, agents, prompts, whatever the next thing is going to be by the time this gets published. The tooling is new, but the feeling is not. What’s becoming clear to me is that this shift isn’t really changing what teams need from engineering leaders. It’s just making the gaps more visible.

If I’m being honest, coding was never the hardest part of software development. It was just the most visible one. The hard parts were always human. Deciding what not to build. Explaining tradeoffs. Getting alignment. Helping someone grow without crushing their confidence. Shipping something imperfect and standing behind it. Code was just how we expressed all of that. AI doesn’t remove these challenges, it makes them harder to ignore.

## When craft becomes identity

One of my engineers told me recently that he was hesitant to lean too heavily on AI-assisted tooling. Not because it didn’t work, but because it worked really well. He was worried about losing his craft. Worried that the instincts he built over years of debugging, rewriting, and shipping would dull. Worried about skill atrophy in the thing he built his career on.

This wasn’t someone afraid of learning. It was someone afraid of losing a part of himself. I don’t think that fear is irrational at all.

For a lot of engineers, our value was tied directly to what we could produce with our own hands and brains. We learned through repetition and failure. We earned fluency the hard way. When a tool shows up that can do parts of that work instantly, it forces an uncomfortable question: if this is easier now, what does that say about what I’m good at?

That conversation stuck with me because it wasn’t really about tools. It was about trust. Trust that experience still matters. Trust that judgment still counts. Trust that we’re not erasing the past ten years every time we accept a suggestion from a machine.

## Coding was never the bottleneck

Here’s the part I keep coming back to: the code was never the bottleneck. It just felt like one because it was slow and manual.

What actually slowed teams down was poor decision-making. Unclear ownership. Missing context. Optimizing the wrong thing. AI doesn’t solve any of that. In some cases, it makes it worse because bad decisions get implemented faster.

I was taught that the idea of a “10x engineer” at the leadership level was about creating an environment of mentorship, guidance, and autonomy. Hire smart people, get out of their way, support them when they need it. I still believe that.

What I didn’t expect is how much time I now spend establishing shared approaches to tooling and workflows. Not because I want control, but because without some guardrails, everything turns into noise. Reviews get harder. Knowledge stops flowing. Growth becomes uneven. That shift took me a while to accept.

## Alignment is the new leverage

It doesn’t sound glamorous to say that part of my job is making sure we’re using tools consistently. It sounds like process. But in an AI-assisted world, alignment is where the leverage lives.

When everyone uses tools differently, outcomes vary wildly. Expectations drift. Quality becomes subjective. Consistency isn’t about stifling creativity. It’s about reducing cognitive load so people can spend their energy where it actually matters.

In that sense, tooling decisions are a form of mentorship at scale. They communicate what we value. They set expectations. They help newer engineers learn how to think about problems, not just how to solve them. This is where I think engineering leaders who feel disoriented right now might want to focus.

## Decision quality over code quality

When code is cheap, decisions are expensive. If AI can generate something that compiles in seconds, the real question becomes whether we should be building it at all. Or building it this way. Or building it right now.

As a leader, I’m spending less time nitpicking implementations and more time asking why we’re choosing one path over another. Teaching teams how to recognize irreversible decisions. Encouraging them to slow down when something has long-term impact. Making it clear that “working” is not the same as “correct.”

## Context as a first-class skill

AI has no memory of your organization. Your team does. It doesn’t know why a decision was made three years ago. It doesn’t understand customer pain that never made it into a ticket. It doesn’t feel the political or operational constraints that shape real-world software.

Helping engineers build and share context is more important than ever. Writing down the why, not just the how. Telling the story of how things got here. Pairing engineers closer to product and design earlier than feels comfortable. Context is what turns generated code into good software.

## Redefining growth without erasing the past

There’s a lot of quiet anxiety around career progression right now. If writing harder or more complex code isn’t the obvious path forward anymore, what is? I don’t have a perfect answer, but I’ve been explicit that growth now looks like better judgment, clearer communication, stronger ownership, and knowing when not to automate. Seniority shows up in the questions you ask, not just the output you produce. That doesn’t invalidate the craft people worked hard to build. It builds on it.

## So what’s the job now?

I don’t think engineering leadership has become easier. I think it’s become more exposed. When tools remove friction, what’s left is intention. Teams still need help forming that intention together. They still need mentorship, guidance, and trust. The shape of that work is just changing.

Lately I’ve been orienting my teams less around output and more around clarity. Clear goals, clear constraints, clear ownership, and shared context. The better we get at those things, the more leverage the tools actually give us.

I’m still figuring this out. Some days it feels like I’m letting go of things I used to be really good at. Other days it feels like I’m finally seeing the job for what it always was. The code changed, but the people didn’t. That’s still the job.

Modern engineering leadership


Y’all, I just hit nine years at Sprout Social! Can you believe it? Anytime a friend asks, "You still at Sprout?" I typically respond with, "Yeah, I’m still at Sprout." I don’t mean this in a bad way, its just that the folks I’ve interviewed and hired usually haven’t stayed even five years at an organization. Every year I go through an existential crisis of “<em>Am I providing value with what I do</em>?” I usually realize that's an annoying question, but this year is different. I’m not going to get a gold watch for my time at Sprout, but there are so many things I continue to learn in my day-to-day. I want to talk about nine lessons I’ve learned working at Sprout Social.

<ol class="list-decimal pl-8 lg:pl-12">
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be willing to adapt</h2>

Some of my biggest missteps in my career were due to my stubbornness or a “but that’s not what I’m used to” attitude. I spend a lot of time telling my team how important the ability to adapt is because things change! As an individual contributor (IC) software engineer or even a CTO, it is critical to adjust and adapt for the bottom line. A job is a job at the end of the day, but if you have resilience or grit, you’re going to be much better off than those who may be apprehensive about change.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be scrappy</h2>

This was an “old world” Sprout value, but it is an important virtue for the team I work with. Scrappy doesn’t mean “lazy,” and it doesn’t mean “hasty.” To me, being scrappy means accomplishing something with your own sense of urgency. Decision-making becomes difficult as an organization grows, but as an individual, if you have the willingness to accomplish something and the ability to sell it, you’ll be a valuable asset to the organization. Get it done however you need to get it done.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be around the right people</h2>

No engineering or management book covers this nearly as much as they should. I spent years talking about “the Sprout Game of Thrones,” which lent itself nicely to the fact that our executive squad used to be referred to as “The Small Council.” All of my growth within the organization is a direct result of putting myself in front of people that a marketing developer shouldn’t have been. You have to advocate for your worth, and it becomes easier once you really get to know the higher-ups. Some of my favorite moments at Sprout included playing shuffleboard or pool against my CEO. This isn’t easy to do, especially as a remote employee, but when you are trying to grow in an organization, it truly is about who you know. The Sprout alumni group is a beautiful example of this. I hate the “your net ‘worth’ is your ‘network’” sentiment, but especially at a company like Sprout, it’s really important to maintain relationships.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be a little lazy</h2>
Try to automate as much of your position as possible so it doesn’t require mental energy. This was easier to talk about pre-AI, but I truly think that being lazy begets being annoyed about something, which subsequently causes you to care about and finally fix it. Listen, no one loves work, but if you can be fulfilled and be a little lazy? Game over, you’ve hit the jackpot. Try to do as little as possible until you have to do as much as possible to bring you back to doing as little as possible.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be wrong</h2>

In every workshop about employee growth, they talk about the idea of going in with a “growth mindset,” and as much as I agree with this, they never really talk about being wrong. There have been so many circumstances in my time at Sprout where I was way wrong, and that’s how I actually grew. We talk about giving ICs the ability to “fail” but always knowing that there’s a life raft, but to have an IC feel like they were totally wrong? That, in my opinion, is how true growth happens.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be your own boss</h2>

I have an incredible manager. So much so that I can’t imagine leaving the organization unless she did. My manager has been my boss for over five years, and every upward-feedback review cycle I shout out that my boss has never explicitly asked me to do something. This is because I have been preemptive in knowing what my boss may ask of me. By anticipating any ask, I know that I have the agency to do it my own way, but also have the room to fail or be wrong. The most successful people on the teams I’ve led have all had the same mentality that competency for your position can and should be determined by you.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be assertive</h2>

In software development, there’s no shortage of soapboxes to stand on or arbitrary hills to die on (tabs vs. spaces, anyone?), but an important characteristic of being a team player is being assertive and knowing how to sell why you feel that way. Sometimes you’re going to be wrong, but it’s more impactful to make a decision and run with it than to have repeat conversations with the team over and over again because no one really wants to commit. We used to have the “scale of f*cks given,” which was helpful to even allow the space to be assertive. From there, leading the charge and advocating for an approach allows work to actually get done, not just talked about.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be open to feedback</h2>

I hated constructive feedback when I started at Sprout. I had the mindset of “Who are you to be giving me feedback? I’m great at my job.” The older I get, the funnier that hubris is to me. I see it a lot with more junior or associate-level software engineers. It’s important to feel confident (read: not arrogant), but the best growth happens when you start soliciting feedback. Feedback is an important value at most tech companies, and for good reason. When we talk about self-led growth or having a growth mindset, it all depends on a person’s willingness to ask for feedback and really put it into action, even following back up. Recently, I was working with a teammate who received some corrective feedback from a peer. They took it seriously, changed their behaviors and working style with their peers, and then got heralded in a casual stand-up by the person initially giving the feedback. It’s amazing to see that work and how productive they are now collaborating, and it’s entirely because that person wasn’t just open to the feedback, they knew the impact putting it to action would have.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be stoked</h2>

I’m a glass-half-full person almost always, which isn’t very Virgo of me. In nine years, I’ve seen many of the same types of projects, new folks bringing in older approaches, and instead of discrediting or being negative, I love to find the opportunity in trying it again. A big thing I get called out for at work is my energy and passion for what we do. If you’re not stoked on it, then why are you doing it? Again, a job is a job, but it’s almost entirely what you make of it. Why wouldn’t you want to be stoked doing it? The more fulfillment you have in your role, the better work you’re going to do. This isn’t rocket science. Get excited! When you’re frustrated by a project or workload, really take inventory of what is important to you in your career. Paycheck? Sure, but you don’t stay at a company for as long as I have without finding the joy and energy in getting to do awesome work.
</li>
</ol>

<p class="mt-8">So that’s it. Nine whole years. The company I work for is an entirely different operation than when I started, and that’s a great thing. I’ve seen so many stages of the company, and I wouldn’t have had it any other way. The relationships I’ve built and the projects I’ve been fortunate to collaborate on have been an absolute joy. Here’s to nine more years! 😂</p>

9 years


If you haven't watched it in a while, 1998's "Armageddon" is an incredible work of art. It's part of the Criterion collection for a reason. Michael Bay is doing full-on Michael Bay, and enough Aerosmith on the soundtrack to last a lifetime. Armageddon is the story of a rag-tag oil "roughnecks" team recruited by NASA to save the world from an impending asteroid collision. If you haven't watched it, this should be the sign to stop reading and immediately fire that bad boy up on Amazon Prime. When rewatching this movie all I could think of was how good of a boss Harry Stamper, played by Bruce Willis, is. Harry is a determined leader and exhibits many leadership lessons throughout the movie. From his unwavering commitment to his team's well-being to his ability to make tough decisions under pressure, Harry's character provides valuable insights into effective leadership.

<h2 class="font-sans text-3xl">Resilience and Determination</h2>

Harry is an ideal example of resilience and determination in the face of impossible odds. Despite the overwhelming magnitude of the task, Harry never succumbs to despair or doubt. Instead, he remains resolute, constantly motivating his team members and inspiring them to push beyond their limits. Harry's unwavering determination serves as a reminder that leaders must possess a steadfast resolve, even in the most challenging circumstances, to instill confidence and inspire their teams to achieve the impossible. He exhibits the very definition of "keeping his cool."

<h2 class="font-sans text-3xl">Putting the Team First</h2>

One of Harry's most notable leadership characteristics is his unwavering commitment to the well-being of his team. Harry consistently places his crew's safety and success above his interests throughout the movie. He ensures everyone has the necessary skills and knowledge to fulfill their roles effectively. Harry also fosters an environment of trust and camaraderie, emphasizing the importance of teamwork and collaboration. His selfless approach to leadership serves as a critical reminder that a leader's primary responsibility is to empower and support their team members.

<h2 class="font-sans text-3xl">Making Tough Decisions</h2>

Harry is forced to make several tough decisions with life-or-death consequences in a dire situation. These moments highlight his ability to remain calm under pressure and make swift choices for the greater good. Harry understands that effective leadership sometimes requires making unpopular decisions, but he does so with a clear focus on the mission's success. His willingness to take calculated risks and shoulder the responsibility of difficult choices demonstrates the importance of decisive leadership, even in the most challenging situations.

Harry's leadership in Armageddon provides valuable lessons for leaders in any industry. His resilience, determination, unwavering commitment to the team's well-being, and ability to make tough decisions under pressure set him apart as an exceptional leader. Harry's character inspires his team and the audience, reminding us of strong leadership's critical role in overcoming seemingly impossible challenges. By emulating Harry's leadership traits, individuals can aspire to become influential leaders who inspire and guide their teams to achieve extraordinary results. Software engineering leadership is by no means life-saving missions to life-threatening asteroids, but there are some tidbits I'll be putting into place for my team, and I hope you do as well.

👋 Howdy! My name is Justin

Recent Writing

Modern engineering leadership

9 years

Leadership lessons from 1998’s blockbuster hit “Armageddon”