This article was originally published on .cult from Neil Green. .cult is a Berlin-based community platform for developers. We write about all things career-related, make original documentaries, and share loads of other untold stories for developers around the world.

Becoming a technology leader is a huge achievement and you should be proud that you have been given this responsibility. Technology leadership is a step towards management or architecture, so your career development is on the right track. As you are ambitious, you need to think about your next career move, as this will help you guide your daily priorities over the next few years.

When you become a technology leader, you should always ask yourself three questions:

  1. What are the upcoming features?
  2. How ready is the code base for the upcoming functions?
  3. Is my team able to handle the upcoming features?

Get acquainted with the upcoming features

Knowing what features are coming is essential for a technology leader to know, and the only way to find out is to develop a close partnership with business stakeholders. Whatever your team does in a few months is already being discussed, although it may not be officially defined. The more you know what features a business may want, the better you can prepare both the code base and your team.

Creating a smooth, informal, effective working relationship with stakeholders will make your job as a technology leader much easier. This partnership will pay dividends when you need to agree on delivery dates and requirements to be met by that date. If you don’t have a good relationship with your stakeholders, you will be constantly caught between them and your team and it will be a nightmare. However, with good working relationships with stakeholders in your business, you will be able to negotiate with your team from bad situations before they arise.

Let’s say you’re told you have a week to get a job done in a month. Instead of getting angry, you can invite your good friends from the business part of the house to lunch. Once there, you talk about weather, sports and what’s going on in the news. In the last few minutes of lunch, you can carefully move on to talk about the difference between what the business wants and what your team is able to provide.

Business people are used to negotiating at lunch, so it’s natural for them. However, for a new technology leader, this type of conversation can be daunting. However, you need to persevere in building these relationships and accept that you will be clumsy at first as your communication skills become more polished. For years, negotiations with business on how best to fulfill a product opportunity will come naturally and will most likely be the main reason you get your next promotion.

Find out the status of the code base

Understanding the state of the code base is the primary responsibility of the technical leader. The only way to gain this knowledge is to study each line of code that makes up the application. It is shocking that few technical leaders do this and instead complain to their team when the system does not work the way they thought it did. This is a very bad guide. Now that you are a technology leader, you can no longer complain, because now this is your code base – no matter who originally wrote it.

The sense of ownership of the code base is a key aspect of being a technical leader. You are now both the custodian and the custodian of the code base. You are the first and last line of quality protection and code design. No matter what condition the code was in when you inherited it, it is now your responsibility to prepare it for everything the business may need to do in the near future. Also keep in mind that this is the main difference between a technology leader and a leading architect – the architect is concerned about what the business may need in the distant future.

Depending on the code base you inherit, you may feel like you have won the lottery or been cursed by misfortune. Unfortunately, because proper system architecture and code quality are no longer emphasized in the software industry, you may feel more than the latter. This can be expected, but your fear will fade when you learn more about the entire code base and how much it works. It may be a mess, but it will be your mess, and as a wounded animal, your job will be to breastfeed it back to health.

As a technical guide, you will be considered to be the most capable software developer on the team as you should be. Being the best software developer on the team is a responsibility that carries with it the obligation to take on the most difficult tasks. Perhaps there is no more difficult task than restructuring an inherited code base to use new paradigms, frameworks and technologies.

You should never ask your team to do something you don’t want to do, so when it comes to a big pile of refactoring, you should be the one to take it. Code-based refactoring is a thankless exercise for everyone outside of your team, but your team will appreciate and respect your efforts – especially if you’re good at refactoring.

Make sure your team can handle the upcoming features

In terms of your team’s capabilities, this is where things can become a big challenge for a new technical leader. There are two situations you will encounter, both of which can be problematic:

  • You are promoted above your peers, which inevitably causes interpersonal problems.
  • You have been hired as a technology leader and inherit a team you don’t know.

Most technology leaders are beginning to be senior engineers and promoted to their current company. Assuming you were liked by everyone, then people may be happy to take guidance from you. After all, you were your peers yesterday, but today you are in the lead. Everyone likes to be reminded on a daily basis that he was not good enough to be promoted to technology leader, but you are.

I’m joking, of course. It is the dark secret of being a new technology leader you are often in charge of your friends now. It is difficult to give direction to the people you have interacted with, and when you do, feelings of resentment are common. However, the good news about promotion above your peers is that you at least know their potential. Not so if you inherit a new team.

Inheriting a team means you have no idea of ​​their capabilities, but you need to know what they can do to be an effective leader. Unfortunately, the only way to really understand this is through trial and error in a real project, because you only learn what people can’t do when they fail. If software developers are self-aware and honest about their own capabilities, they might tell you, but most often they are neither.

Being a new technology leader with a new team will push you to the limits of your leadership skills.. The problems you will face can be so widespread that even after reading a hundred books on leadership, you may still not have all the knowledge you need. This is a real challenge and there is no way around this fact. The best advice I can give is a few principles that you should always do your best to follow:

  1. Always try to do the right thing.
  2. Always act honestly.
  3. Always treat people fairly.
  4. Always be honest.
  5. Always be respectful.
  6. Never ask your team to do something you don’t want to do.
  7. Never take credit for your team’s achievements.
  8. Never blame anyone but yourself for the failure of your team.
  9. Never miss an opportunity to learn from failure.
  10. Never allow your team to stop at their failures.


Your first few years as a technology leader will be your most difficult, but that time will pass. The more mistakes you make, the more you will learn and this will form the basis of your experience. From experience will come wisdom, and then expertise. It can take many years before you consider yourself a wise and expert technical leader. However, you start from the only place you can: in the beginning.

Previous article10 Best Fitness Trackers You Can Buy In Singapore In 2022
Next articleThe best VPN for Windows – CNET