In this blog post I want to write about something that has been on my mind for quite a while now: the job of a software consultant is changing, and I think we have to start leading teams.

To be honest, during my last projects, the hardest problems were rarely technical. They were not about the architecture, the state management or the build pipeline. They were about people and how they work together. And I realized that my technical knowledge did not help me much there.

For many years, I was hired for what I know about technology. Angular, ASP.NET Core, Nx, NgRx, testing, you name it. Clients called me when they needed someone to set up the architecture, find the strange bug or decide which library to use. That is changing, and it is changing fast. The technical part of our job is not disappearing, but it is getting smaller. What grows instead is the human part: the people in our teams.

Of course this post is opinionated. I will try to be as objective as I can, but in the end these are my personal thoughts after quite some years in this business.

Is the Technical Work Moving Away From Us?

I think it is, at least partly. A few years ago, a big part of my day was writing code, reading documentation and debugging. Today, AI coding assistants write a large part of that code for us. They generate the tests, explain libraries I have never seen before and suggest fixes in seconds. Add the cloud platforms and managed services to that, and a lot of the infrastructure work we did by hand is gone as well.

The knowledge I collected over the years is now available to everybody who can ask a good question. Being the person who knows the most about a framework is not a strong reason anymore for a client to hire me. The tools know more than I do, and they are available 24/7.

And to be clear: this is not a complaint. I really love these tools and use them every day. It is simply a shift in where our value lies.

From Digging Deep to Judging Well

Technical skills still matter, but their role changes. We do not have to be the one who digs the deepest into every solution anymore. We have to be the one who can judge it.

In a nutshell, judging means asking the right questions:

  • Does this solution fit the real problem, or only the ticket?
  • What will it cost to run and maintain this in two years?
  • Where are the risks the generated code does not tell us about?
  • Is this good enough, or are we polishing something nobody needs?

This kind of judgment comes from experience, and it stays valuable. But it takes a lot less of our time than building everything ourselves. And the time we save now belongs to the people around us.

The Real Work Is Now the People

When the technology gets easier, the problems that are left are human ones. Honestly, I have rarely seen a project fail because nobody was able to write the code. Projects fail because people misunderstand each other, avoid the hard conversations or simply lose their motivation.

And to be fair: this is not new. The human and psychological part was always there. Teams always had conflicts, people always lost motivation, and communication was always the hardest part of every project. But for a long time, it was hidden behind all the technical work. When half of your day is spent on debugging and configuring build pipelines, it is easy to overlook that a colleague is struggling. Now that the tools take over more and more of the technical work, there is nothing left to hide behind. The human part was always present, but it was never as obvious as it is today.

Over the years, I have seen the same kinds of problems again and again:

  • People who feel unsure about their role now that AI tools take over more and more of their work.
  • Disagreements that are not spoken out loud in meetings and slowly grow over time.
  • Different expectations about what "done" actually means.
  • People who are afraid to ask questions and get stuck on their own.

No framework in the world solves any of these. What helps is someone who notices it, listens and does something about it.

Which Skills Do We Have to Build?

Most of us became developers and consultants because we love technology, not because we wanted to deal with feelings. I can totally relate to that. But human skills can be learned, just like a new framework. Here are the ones I think matter the most:

  • Listening: Not just waiting until it is our turn to speak, but really understanding what somebody means. Including the things they do not say.
  • Giving and receiving feedback: Clear, honest and kind. Most teams have way too little of it, and when it comes, it comes too late.
  • Handling conflicts: Bringing disagreements to the table early, before they turn into silence or frustration.
  • Creating psychological safety: Making it normal to ask questions, to admit mistakes and to say "I don't know".
  • Coaching instead of solving: Helping a colleague to find the answer, even if we could give it to them faster ourselves.
  • Reading the room: Noticing stress, low energy or tension before it shows up in the sprint review.

None of these are in a job description for a senior developer. But all of them decide if a project is successful or not.

But Don't We Still Need Technical Depth?

Yes, absolutely. And I think this is important, so let me be very clear here: I am not saying we should stop being technical. The best consultants I know combine both: solid technical judgment and strong human skills.

There are three reasons why depth still matters:

  • Judgment comes from experience: We can only judge a solution well if we have built enough of them ourselves. If you never dug deep, you will have a hard time seeing the risks in a generated design.
  • Credibility earns you the right to lead: Developers follow people they respect. Technical credibility opens the door, the human skills make people want to walk through it.
  • Some problems are still hard: Legacy systems, security, performance or regulated domains still need people who go really deep.

So the shift is not from technical to human. It is from technical only to technical and human. We go deep less often, but on purpose, when it really matters. And the time we save goes to our people.

Having said that, not everybody has to become a team leader. Some of us will stay specialists, and that is totally fine and valuable. But even the deepest specialist works in a team, and has to listen, give feedback and handle conflicts.

How Can We Start?

The good news is: you do not need a management title to lead a team. You can start next Monday. Here is what I would recommend:

  1. Have regular one-on-ones: Fifteen minutes every two weeks with every team member. Ask how they are doing, not only what they are working on.
  2. Spend your learning time differently: The next time you want to learn a new framework, read a book about communication or feedback instead. The framework will still be there afterwards :-)
  3. Ask for feedback on how you lead: Ask your team what you could do better. And then really act on at least one thing they tell you.
  4. Make room for the human topics in retrospectives: Talk about collaboration and the mood in the team, not only about tools and processes.
  5. Find a mentor or a coach: Somebody who has led teams before can save you years of learning by doing.
  6. Use the time the AI gives back to you: Every hour you save on code is an hour you can invest in your people.

Closing Words

We will still judge architectures, review solutions and make technical decisions. That part of our craft stays, and it is what makes us credible. But the center of our job has moved. The tools get better at technology every month. What they do not get better at is taking care of a colleague who is struggling.

That is our job now. And I think we should get really good at it.

It is time to lead, people. It is time to lead people.

Fabian