Have you ever had to lead a team? One where something’s not going according to plan? When that happens, one of the places we as leaders go to — is our own team. Did we screw up? Did we miss something? It’s a fair question, and it’s always important to acknowledge internal problems first. It's not about having an easy cop-out, or distrustring your team. As a leader you must be objective when it comes to identifying problems and treat them accordingly. Blaming an external entity by mistake is hard to come back from.

And if the answer is “yes”, two things need to happen, and ideally, in the following order:

1. We find a way to fix the problem with the team.
2. We need to understand WHY it happened in the first place, so we don’t allow for it to happen again.

In my 18 years of career, I’ve had to lead hundreds of projects, some of them small, some of them huge. And during those experiences, I got to hear so many excuses — either for lateness or for non-working code — that eventually I started ranking them.

And from that list, I think there are five that no leader wants to hear, and that no one should consider saying, no matter how true they think they are.

Sorry I’m Late, I Went Out Partying Last Night

Yes, I’ve heard this one, and some variations around it a few times. And, trust me, they were said to me because the trust I had with that person was big. That being said, far from being funny or a perfect reason that I had to understand, this showed me that this person basically lacked a sense of responsibility.

Life can get in the way of work; I not only accept it but promote it. If you have a personal emergency, I’ll be the first one to tell you: forget about work; pay attention to your life.

But going out, getting drunk, or just going to bed so late that you arrived four hours late — is not an emergency.

It doesn’t matter if your leader is your childhood friend, your brother, or a complete stranger. That person has a whole project (if not more) filled with deadlines to meet, and you just made their job a little bit more difficult, for the wrong reason.

You can use the words you want, but the message your transmitting is the same: I don’t care about the project, nor do I care about your responsibilities. I just wanted to have some fun, and I did.

But We’ve Always Done It Like This!

Really? I’m telling you we’ve found a problem with the algorithm, and you’re telling me that’s how we’ve always done it?

Honest to god phrase uttered by me at one point in my career.

So, yeah, don’t say that to your lead either. At least not with a justification of why you’ve been doing it like that until then, and that justification better counters the actual bug report. Otherwise, you’re clearly being handed a bug, and, yes, that bug might’ve come from an incorrectly gathered requirement. But then again, it’s already been identified as a bug, so your comment doesn’t really help, does it?

It’s a lot more constructive to accept the fact that the bug report doesn’t lie and agree to review it. Through that review, you can maybe reach the consensus that it’s not actually a bug. It was incorrectly tested (maybe), and then— and only then — you can go back to your lead, metaphorically throw the bug report at their face, and yell, “See I told you it wasn’t a bug!”

But now you have proof, so your reply, no matter how loud it might be, is more constructive than saying “but we’ve always done it like this!”

It’s Not My Fault!

Look, unless you’re directly being targeted and reprimanded somehow for something you didn’t do, saying — “It’s not my fault,” or its cousin, “I didn’t do it” — when a problem with the project is found, really helps no one.

Even if it’s a frontend issue and you’re a backend dev, you can probably do something to help test it or debug it.

By quickly jumping on a defensive stance, you’re yelling, “I don't care about my team; I just want to go home on time!”

I’m Bored

Look, it’s OK to not like what you have to do. We can’t always expect to enjoy our daily tasks, and sometimes they’ll be boring, but there is nothing we can do about it.

But saying that you’re bored, means you a) have nothing to do, so you’re just sitting there looking at the ceiling or b) you’re not doing what you were asked to do, because you just don’t enjoy it.

And before you start wondering — they’re both wrong.

If you’re sitting with nothing to do, saying that you’re bored is the definition of the wrong attitude. There is always something you can do, and if you find yourself in a situation where you have no more tasks to close, you can:

1. Directly go to your lead and let them know this. Mind you, not by saying that you’re bored, but rather by stating that you’ve completed your tasks and that you now have time to do something else.
2. If you can, find an old bug that’s been bothering the team for a while and try to fix it. Perform a code review, find that section of your codebase that’s been gaining technical debt for a while and propose a re-factor for it. There are tons of things you can do when you don’t have anything else to do.

Either way, you’re showing you’re proactive — which is a great plus in the eyes of a lead — and you’re also helping your team.

If, on the other hand, you’re just stating that you’re bored because you don’t like what you’re doing, then find a way to solve your problem. Find a way to make your tasks more interesting. Back when I started, whenever I had a boring task, I would try to make it more interesting. I’d find a way to automate it or forcefully use something I didn’t know before, so I could learn something new in the process.

Learn to turn a boring task into an interesting experience.

Otherwise, if you’re just stating “I’m bored,” you’re putting another problem in your lead’s plate with no solution in sight. But if you say, “I was bored, so I did…” it means you cared enough to make things interesting, and that shows qualities we want to see in devs, such as:

• Proactivity
• Self-starter
• A passion for learning new things

Next time you’re bored, consider turning your boredom into a learning experience.

It’s a Random Bug

I left my favorite for the end because it’s such a good one.

Do you have the slightest idea how computers work? Things don’t just happen; there is a reason for everything. And bugs are no exception.

Granted, I’ve spent days debugging searching for an elusive bug, but if you look close enough, you’ll find it. It’s all about patience and attention to detail.

Calling it a “random bug,” other than getting on my nerves, serves no purpose. You’re doing two things:

1. Stating that you don’t care enough about the product.
2. Accepting that your users will have to deal with it from time to time.

However, you need to remember that for every bug found, your lead is expecting:

1. A solution to it, so it stops happening.
2. A Root Cause Analysis (RCA), which is a fancy way of saying “understanding why it happened in the first place.”
3. The insurance that it will never happen again. This one is a combination of the RCA, plus a well-documented fix and, on some occasions, the corresponding test that makes sure no future deploy re-introduces the bug. (It may be a unit test, integration test, or even e2e test.)

Consider this: Saying, “It’s a random bug,” is the equivalent of sitting at the start of step 1 and calling it a day.

When sh*t hits the fan, what any normal technical lead would expect from their team, is that they do everything they can to solve the problem. This doesn’t mean working extra hours, or canceling vacations, it just means caring enough about the project to:

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

---

Try to remember that by saying any of the above five phrases, you’re not only going against these three basic points, but you’re also disrespecting the rest of your team. Every time you say “I don’t care” with your actions, there is a teammate who needs to care extra to cover for you. So even if you don’t care about “the man” or the company, care about the people working alongside you.

Have you heard a similar one — or have you uttered them in the past? Share your experience in the comments. I’d love to know more!