5 phrases you shouldn’t tell your tech lead, even when you really want to

Have you ever had to lead a team? The one where things don’t go according to plan? When this happens, one of the places we, as leaders, go is to our own team. Are we screwed up? Are we missing something? This is a fair question and it is always important to acknowledge the internal problems first. Blaming external factors for problems makes it difficult to become more successful.

And if the answer is yes, two things should happen, and ideally in the following order:

  1. Finding a way to solve the problem with the team.
  2. First of all we need to understand why it happened so that it doesn’t happen again.

Over 18 years of my career, I have had to manage hundreds of projects, some of them are small, others are huge. And during my work, I heard a lot of excuses – either for being late or for not working code – that in the end made a rating out of them.

And on that list, I think there are five excuses that no leader wants to hear and that no one should even think about, no matter how true.

Sorry I was late, I went to a party last night

Yes, I’ve heard this excuse and variations on it several times. And, believe me, I was told this because I trusted the person very much. The excuse was not at all a joke or a compelling reason I needed to understand and showed me that he basically lacked a sense of responsibility.

Life can get in the way of work. I not only accept this fact, but also encourage it. If you have a personal situation, I will be the first to tell you: “Forget about work; pay attention to your life. “

But going for a walk, getting drunk, or just going to bed very late to be four hours late the next day is not an emergency.

It doesn’t matter who your boss is to you: a childhood friend, brother, or a complete stranger. This person has a whole project (if not more) that needs to meet deadlines, and you just made it difficult for him to work for no good reason.

You can say any words, but the essence that you convey remains the same: I do not care about the project and your responsibilities. I just wanted to have a little fun and I did it.

But we’ve always done this!

True? I tell you that we found a problem with the algorithm, and you tell me that you always wrote it this way? Honestly, I uttered this phrase at some point in my career.

So, don’t tell your leader this. At least not with a justification as to why you have done this so far, and it justifies the actual error message. You are clearly being told about the error, and yes, this error could have arisen from an incorrectly written request. But then again, this has already been identified as a bug, so your comment doesn’t help much, does it?

It is much better to accept the fact that the bug report is not false and agree to see it. Through this check, you may be able to come to a consensus that this is not actually a bug. Perhaps the code has been incorrectly tested, and then you can go back to your leader, metaphorically throw a bug report in his face and shout: “See, I told you this was not a mistake!”

And now you have proof, so your answer, no matter how loud it is, is more constructive than “but we always did that!”

It’s not my fault!

Look, unless you are being harassed and reprimanded for something you didn’t do, “It’s not my fault” or “I didn’t do it,” when a problem with a project is discovered, it really doesn’t help anyone.

Even if it’s a front-end problem and you’re a back-end developer, you can probably do something to help test or debug your code. But instead, quickly getting into a defensive stance, you shout: “I don’t care about my team, I just want to get home on time!”

I’m bored

Look, it’s okay not to love what you have to do. We can’t always count on our daily tasks to be enjoyable and sometimes boring, but there’s nothing we can do about it.

But to say that you are bored means: a) you have nothing to do, so you just sit and stare at the ceiling, or b) you don’t do what you were asked to do because you just don’t like it.
And before you start wondering, both are mistakes.

If you sit around and say that you are bored, that is definitely the wrong attitude towards work. There is always something you can do, and if you find yourself in a situation where you really don’t have tasks to close, you can do the following:

  1. Go straight to your supervisor and report it. Preferably, not saying that you are bored, but rather stating that you have completed your tasks and now you have time to do something else.
  2. If you can, find an old error that has been bothering the team for a while and try to fix it. Analyze your code, find the section of your codebase that has accumulated technical debt for a while, and suggest refactoring it. There are many things you can do when you have nothing else to do.

In any case, you demonstrate your initiative – which is a big plus in the eyes of the leader – and you also help your team.

On the other hand, if you are simply claiming that you are bored because you do not like what you are doing, then find a way to solve your problem. Find a way to make your tasks more interesting. When I started out, whenever I had a boring task, I tried to make it more interesting. I’ll find a way to automate it or use what I didn’t know before to learn something new in the process.

Learn to turn a boring task into an interesting one.

Otherwise, if you just say, “I’m bored,” you are creating another problem whose solutions are out of sight. But if you say, “I was bored, so I did …”, it means that you cared enough to make the problems interesting, and this shows the qualities that we want to see in developers:

  • productivity;
  • initiative;
  • passion for learning new things.

The next time you get bored, consider turning the boredom into a rewarding experience.

This is a random bug

I left my favorite for dessert because it is very good.

Do you have any idea how computers work? Nothing happens just like that; there is a reason for everything. And bugs are no exception.

Of course, I spent a few days debugging looking for the elusive error, but if you look closely enough, you will find it. It’s all about patience and attention to detail.

Calling something a “random mistake” doesn’t make any sense, except for one thing: get on my nerves. You do two things:

  1. Declare that you do not care enough about the product.
  2. Admit that your users will have to deal with this error from time to time.

However, you need to remember that every time you find a bug, your leader expects:

  1. Solutions to this problem, so that it no longer occurs.
  2. Root Cause Analysis (RCA), which is a fancy way of saying “I understand why this happened.”
  3. Insurance so that the problem never recurs. It is a combination of RCA, a well-documented fix and, in some cases, an appropriate test to ensure that this error does not occur again in the future. (This could be a unit test, an integration test, or even an e2e test.)

Think about this: to say, “This is an accidental mistake” is like sitting there from the beginning and doing nothing.

When shit hits the fan, any normal tech executive expects their team to do whatever they can to fix the problem. This does not mean working overtime or canceling vacations, it just means taking enough care of the project to:

  1. Solve the problem of.
  2. Understand why it arose.
  3. Make sure it doesn’t happen again.

Try to remember that by uttering any of the five phrases above, you are not only going against these three main points, but also not respecting your team. Every time you say, “I don’t care what I’m doing,” a teammate appears and needs to do something to cover you. Therefore, even if you do not care about the “person” or the company, take care of the people who work with you.

Have you heard this or have said it in the past? Share your experience in the comments.

Find out the detailshow to get a Level Up in skills and salary or an in-demand profession from scratch by taking SkillFactory online courses with a 40% discount and a promotional code HABR, which will give another + 10% discount on training:

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *