What you should do as an employee and as a manager to love your career

During my career, I’ve always tried to gather and “consume” as much information as I could regarding management and leadership. I didn’t want to become a manager (yet), I just didn’t like what I saw around, and to win a fight with someone and that fight to be fair, you both need to fight with the same weapons.

In this article, you won’t find the silver bullet for becoming the best manager or employee, but you’ll find some tips on what you should expect in different situations, and what I think you should do as a manager and employee (Here I include the TLs also because, in the end, they are middle management). In both places, you might want to say something, but you don’t know how to express yourself, 100% transparent, without giving the wrong impression of what you want to say to the person in front of you. I hope this article will clarify a few of these situations.

As a manager

1. 121 meetings are a key thing in keeping your employees around you. Make human connections; talk freely with them and get some feedback on everything: project, product, management, company, team..etc. If you don’t have them and you consider your employees as resources, they will leave you for sure. You can’t financially motivate them forever. Keep in mind a very important thing: 121 meetings are about the connection between the employee, manager and company. It is not a status update of the project or task!
2. Offer constructive feedback. A good manager is not afraid of saying something when someone is doing something wrong and helps him fix the thing. A good manager is not afraid of conflicts, and difficult situations. In scrum teams in retrospective meetings, everyone is saying what went well and what didn’t during a sprint, but if someone has a bad habit of doing something, you as a manager should talk with him in private. If he did something really good, that thing should be said in front of everyone involved in that thing; so, good things in public, constructive things in private (as long as it’s not something sprint related).
3. Everyone wants to grow. You should be able to help them find the best training and workshops that will help them achieve their goal.
4. Do not micromanage and delegate as much as possible. Do not try to control everything.
5. Do not forget that you are a manager as long as you have people around you. If your teams do not respect you or accept you, you’re doing something wrong. And by the way, respect must be earned and it’s very easy to lose.
6. Communicate well your expectation. Do not think everyone understands what you want.
7. Do not think you know a person or what he did in a specific situation from a report.
8. If a person is underperforming, don’t wait for a review. Talk to him directly and see what’s the problem. When you find out the cause, help him to solve it.
9. Stay near the code of the project, so you’ll understand better the bottlenecks. You don’t need to be a guru to understand what a database is or a backend and a frontend.
10. Do not run away from conflicts and do not try to make them. (I post this second time because I really think it’s important)
11. Do not hire people only because they are superstars in what they do. They first need to fit into the team. Any framework can be taught.
12. Do not forget that you are responsible to grow up new leaders in your organization.
13. If a team is not delivering because they are constantly having their goals changed, it’s your job to help everyone to refocus on what’s important
14. If a team is in a constant fire-fighting mode, again, it’s your job to make a plan with the stakeholders to get them on a “flat normal line”, before they burndown. You might need to hire more people or change the expectations from the stakeholders, but don’t forget: with a good team you can build anything, with unhappy stakeholders you lose a project but you can build the next one; with unhappy team members, you can’t build anything. You are accountable for the productivity, health and happiness of the team.
15. When one of your teams has a problem, “debug the issue”. Don’t get your boots on and go in there and take control. Try to help them from distance; if you have an idea what’s the reason for the issue, try to test it first. Observe the team. It might be even the case of a false positive and your KPIs are wrong. Ask questions before even thinking to act. Check the team dynamic. They might even be bored and in need of other challenges.
16. Use the Pareto principle and always give the team enough space for refactoring, improvements and growing their creativity.

As a developer

1. Be a mentor. This way you will discover what you don’t know, and you’ll help others to grow. Expect people to be a lot slower than you. It’s pretty normal.
2. Do not try to find mistakes in other’s doing.
3. Listen carefully to what the people around you are saying. If something is not clear, as questions. DO NOT think what someone meant by saying something; again, if it’s not clear ask a question!
4. Pay attention to what the people around you are saying with their physical behaviour. When a hand is raised, that might be a sign that can mean more than half an hour of talking.
5. Be prepared to make mistakes and for others to correct you.
6. Try to communicate clearly and calibrate your responses and way of talking to the person in front of you. To your manager, you might talk in a different way than to an intern, but the message should be the same.
7. Become a leader by example for the people around you.
8. Be curious and open-minded. When someone asked a hard question, ask them, why did they ask that question. They might want something totally different to find out, but don’t know what the right question should be.

As a tech lead

1. You should talk to everyone from your team. Have more one-to-one meetings than your manager have with the people you are leading. You are the first person that should find out if something is going in the wrong direction.
2. Ask and give feedback
3. You will get into the PM area one way or another. You are responsible for the delivery of the product, so you need to understand the PM’s “language” and needs.
4. You need to find the balance between the team’s needs and the product's needs. Do not push your team only to deliver without breathing. They might not have the same speed as you or the management of the project wants. At that moment you need to identify the problems: the expectations are too high, the lack of tech/business knowledge of the people you are leading, etc.
5. You’ll often be put in the position between doing what you like and doing other things. As a leader, you shouldn’t be doing all the “complex stuff”. You should remember how excited you were when your lead gave you something nice to work on. Do that also, and grow your team.
6. Help your team to have a good and clear schedule. Do not accept random meetings with the entire team at random hours. They need to focus on developing because, in the end, this is why they are developers.
7. Help your stakeholders to get in the right direction and understand the team’s needs and way of working. Everything can be done in 100 ways, but some are simpler than others, but all 100 have the same result from the business perspective.
8. Help your team and PO break down things that can be done in parallel.
9. Do not be afraid of delegating. You won’t and can’t have control over everything. Now you need to do other things also, not just code.
10. Overwork make people unhappy! If you need something done fast or you have a critical situation, order dinner, tell your people how proud you are that they stay and help you to get to the wanted result, make them feel that you are part of the team and show them you understand them. Offer breaks, try to make it fun, even if it’s stressful for everyone and DO NOT put any more pressure on their shoulders.
11. You will miss writing code all day long. For sure you won’t do that anymore, but you should try out new technologies, try to find solutions for improvements, from codebase to infrastructure and so on, you should try to read as much as you can from the tech world, go to conferences, find out everything that’s new. You won’t know how to implement a solution using something that just appeared on the market, but you should know if it’s a good improvement for your project, or if you shouldn’t use it (and of course, if the benefits bring more value than the resources spent to change your old solution).

I wrote about one-to-one meetings on all leadership levels, but I never “defined” how you should find out about such a meeting. Here are a few key point questions that might help:

• What is the best and the worst thing from the project you are working on (if you are leading a team)
• What do you like best and what is what you totally hate about the project you are coordinating (if you are a manager talking to a TL)
• Who performed really well in the team from our past discussion?
• What changes do you think we should do on the project level and on the team level?
• What do you think we are missing at the company/organization level? What could we do more/less?
• How happy you are with your team? (if you are a manager talking to a TL)
• How are your teams performing and why? (if you are a manager talking to another manager or to a TL if he coordinates more teams)
• What could we do more, to make working for the company, more fun?

In conclusion, these things are important to me. This doesn’t mean that if you do all of them you will be a perfect employee or manager and have a glorious career; the things from this article are just the first things that you need to master to get into a good place (from my point of view).