Tech Leadership Without the Corporate Costume:

An Unfiltered Conversation with Nick Mullins

There is a certain image people have in mind when they think about technology leadership.

Perfectly polished LinkedIn posts.
Corporate buzzwords.
Endless meetings where people somehow talk for thirty minutes without actually saying anything.

Nick Mullins does not fit that mold. Intentionally.

After more than a decade in the software industry, moving from developer to leadership while building teams, mentoring engineers, and navigating the chaos that comes with modern tech, he has developed a reputation for being honest, practical, sarcastic when necessary, and unapologetically authentic.

No fake executive personality.
No motivational-speaker act.
No pretending the industry is perfect.

Just real conversations about software development, leadership, burnout, AI, and the reality of working in tech.

Ironically, this interview started with AI.

I asked AI to read through my blog posts, understand my tone and opinions, and then interview me about technology, leadership, burnout, authenticity, AI, and the modern software industry.

What came out of it felt less like a polished corporate interview and more like the kinds of conversations developers and leaders actually have behind closed doors.

Not the polished version of leadership people post online.

The real version.

The messy version.

The human version.

“I purposely chose not to fit the mold.”

Q: You’ve been in tech for over a decade now and worked your way into leadership, but you don’t really present yourself like the stereotypical tech executive. No blazer. No ‘synergy.’ No LinkedIn influencer energy. Was that intentional?

Absolutely.

I purposely chose not to fit the mold. I have had leaders who were balls of corporate fluff, and I did not like that. Speaking a lot of words, but saying very little.

It is not my style.

Once I developed my own style, I went with it. I embraced it.

I have had this personality and style for a long time, and I have been promoted numerous times, so something is clearly working.

There is this weird pressure in tech leadership where people feel like they need to transform into a completely different person the moment they become a manager or director. Suddenly, they start dressing differently, talking differently, acting differently. Every sentence becomes corporate jargon.

People notice that.

Teams notice when someone stops sounding human.

That does not mean professionalism is not important. It absolutely is. But professionalism and authenticity are not opposites.

You can be kind, honest, direct, supportive, and still sound like yourself.

Too many people think leadership means performing.

I think leadership works better when people trust that you are genuine.

“The industry tries to treat everyone the exact same.”

Q: What do you think the tech industry gets completely wrong about leadership?

The industry tries to treat everyone the exact same.

You need to treat people equally, but every individual is different, so you need to adjust your leadership style to fit their needs.

Some people need encouragement. Some need clearer direction. Some need autonomy. Some need help managing priorities. Some need confidence.

Leadership is not copy-and-paste.

I also think a lot of tech leaders drink the company Kool-Aid a little too hard.

No company is perfect.

None.

Every company has flaws, bad processes, communication problems, technical debt, and decisions that do not make sense. Pretending otherwise just destroys trust.

Some leaders treat criticism of the process as a personal attack on the company. Meanwhile, the engineering team is drowning in problems everybody can clearly see.

The best leaders I have worked with were honest about reality.

Not negative. Not cynical. Just honest.

There is a huge difference.

Burnout, Pressure, and the Myth of the 10x Developer

Q: Do you think the industry has gotten worse when it comes to burnout and unrealistic expectations?

I do.

Companies are always chasing the mythical 10x developer or whatever the buzzword is now.

There is constant pressure to deliver faster, faster, faster.

And now AI and vibe coding have entered the conversation, which adds even more pressure because executives start wondering why everything cannot happen instantly.

But you do not need 10x developers.

You need solid developers who consistently get things done.

The industry romanticizes rockstar engineers, but most successful teams are not built on superheroes. They are built on dependable people who communicate well, solve problems, support teammates, and deliver consistently.

That matters way more than people think.

A lot of burnout comes from companies constantly trying to squeeze more output from fewer people while pretending it is innovation.

There is a limit to how much context-switching, pressure, and unrealistic expectations people can handle before they mentally check out.

Developers are not machines.

Even the really good ones.

“AI is just another tool in the toolbox.”

Q: What’s your actual opinion on AI in software development?

I think AI will absolutely help developers get things done faster, but only if it is used the right way.

A lot of people think AI is a replacement for developers.

It is not.

It is another tool in the toolbox.

AI can help speed up research and documentation, handle repetitive tasks, and even help brainstorm solutions. That is valuable.

But developers still provide the context.

Developers understand use cases, business requirements, deadlines, edge cases, constraints, technical debt, stakeholder concerns, and the weird real-world problems that arise in software systems.

Software development is not just about generating code.

Real systems are messy.

Requirements change constantly. Businesses contradict themselves. Legacy systems exist. Deadlines shift. Priorities change.

AI does not walk into a meeting and realize:
“This feature request is going to break three downstream systems and make accounting furious.”

Experienced developers understand that context.

That matters more than people realize.

I think AI will make good developers faster.

I do not think it eliminates the need for developers.

The Problem With How Companies Promote Leaders

Q: What actually gets people promoted in tech leadership?

Honestly, it depends entirely on the company.

Some companies promote people who drink the company Kool-Aid.

Some promote based on tenure.

Some promote developers into leadership because they were strong individual contributors.

But far fewer companies promote someone because they are genuinely a great fit for leadership.

That is a huge issue in tech.

Being a great engineer and being a great leader are not the same skill set.

One role is heavily technical.

The other is heavily human.

You are suddenly dealing with communication, motivation, conflict resolution, prioritization, burnout, trust, expectations, business strategy, and team dynamics.

Some people love that transition.

Some hate it.

Some never should have been pushed into it in the first place.

Leadership should not be treated as just the next level of engineering progression.

It is a completely different job.

“Rarely do people need help with the tech.”

Q: Was there a moment where leadership really clicked for you?

I think it happened when the number of people reporting to me kept growing, and I stepped further outside the technology itself.

That is when I realized that people rarely actually need help with the tech.

They need help managing everything around the tech.

That changes your perspective.

Much of leadership is about removing chaos.

Helping people prioritize.

Helping communication.

Reducing unnecessary stress.

Creating an environment where people can actually focus and do good work.

Most engineers are capable of figuring things out technically.

The harder part is navigating everything surrounding the work.

There Is No Such Thing as Perfect Code

Q: What’s something you believed earlier in your career that you completely disagree with now?

At some point, I probably believed perfect code existed.

Or that bug-free software existed.

I do not believe that anymore.

There are many different ways to solve problems.

Some may be more efficient or optimized, sure, but optimization is not the only thing that matters.

Now I realize software development is about solving problems in the best way possible while considering all the variables:

• deadlines
• budget
• team capacity
• maintainability
• business needs
• technical debt

You can build the most elegant system imaginable and still fail because it missed the business need entirely.

Perfection is not the goal.

Solving the right problem effectively is.

That mindset changes how you approach development over time.

You stop trying to win architecture beauty contests and start focusing on outcomes.

“You do not need to become a fake version of yourself.”

Q: What would you say to people in tech who feel like they need to completely change their personality to be taken seriously?

If you change your personality, you are no longer you.

And honestly, people can usually tell when someone is faking it.

Embrace your personality.

Maybe tone it down slightly if needed in certain situations, sure, but you do not need to become a fake corporate version of yourself to lead effectively.

You need to:

• be kind
• be honest
• genuinely care
• communicate clearly
• treat people well

That matters far more than pretending to be some polished executive stereotype.

People trust authenticity.

Especially in tech.

Most teams are exhausted from fake positivity and performative culture.

They want honesty.

They want leaders who sound human.

What Younger Developers Should Actually Focus On

Q: What should younger developers focus on more?

Many younger developers already focus heavily on the technical side.

Sometimes too heavily.

There is this pressure online where people think they need to know every framework, every language, every trend.

That is impossible.

I think developers should spend more time improving the less technical skills:

• explaining technical concepts to non-technical people
• writing good documentation
• reading logs effectively
• understanding systems
• communicating clearly

Those skills matter enormously in real-world development.

Software engineering is not just writing code.

A huge part of the job is understanding problems, communicating solutions, and navigating complexity.

Honestly, learning how to read logs and documentation properly will probably put someone ahead of a surprising number of developers.

A lot of software development is basically detective work.

“Everyone has a little impostor syndrome.”

Q: What do you hope people take away from your writing on mullins.io and LeadDontCtrl.com?

I want people to know that there are leaders out there who genuinely care about both people and work.

Not everyone is a corporate shill.

There are leaders who want healthy teams, honest communication, sustainable workloads, and realistic expectations.

I also want people to realize that the stress and concerns they feel are not unique to them.

Everyone, if they are honest with themselves, has at least a little impostor syndrome.

Even experienced people.

Even leaders.

Most people are figuring things out as they go more than they admit publicly.

That is normal.

I think the industry would be healthier if people talked about that more honestly.

Final Thoughts

Technology changes constantly.

Frameworks come and go.
AI evolves.
Trends explode overnight.
Buzzwords cycle endlessly.

But the human side of the industry remains surprisingly consistent.

People still want:

• meaningful work
• supportive leadership
• realistic expectations
• growth opportunities
• trust
• honesty
• balance

Maybe that is why authenticity matters so much.

Because in an industry full of noise, people can still recognize when someone is real.

And maybe that is the entire point.

If this resonated with you, feel free to connect with me on LinkedIn or explore more writing at mullins.io and LeadDontCtrl.com.

The tech industry does not need more corporate noise.

It needs more honest conversations.