Break the Rules to Boost Your Dev Career

Results come from action. Today, let's talk about taking on a bit of extra risk to gain more. I want to convince you that it's worth taking the initiative in a project, even secretly, without the higher-ups knowing.

In the IT industry, we follow plans and hierarchy. There are those who are higher up, and they decide what those below them should focus on. The goal is organization. Nothing extraordinary. Leaders are responsible for setting the direction of actions. And it makes sense.

However, I propose that it's sometimes worth reversing the flow and taking controlled initiative on your own.

Selfish individualists

Let's be clear. Going rogue in a project is generally not a good thing. No one at the top wants lone wolves, because uncontrolled actions can ruin the atmosphere or even derail a project. I want to stress that I'm referring to those lone wolves who take actions thoughtlessly, based solely on their own opinion (and perhaps their ego) and against everyone and everything.

This kind of rogue behavior is bad, period.

But what if it's done responsibly?

The typical path means we must have consent to do something (product owner/ team lead approval). The problem arises when something important and urgent, something that could potentially add significant value to the project, team, or even the client, is pushed to the back burner.

This is where an opportunity arises for us. And this concept of importance has a relative value—relative to the person who decides.

There’s an improvement on the horizon...

Imagine a situation where you see that previously mentioned glaring problem. It’s burning you up inside to fix it. You see solid benefits for the project. If only you could solve it...

But obstacles arise:

• No approval from the leaders because "there's no time for it."
• There's time, but the issue is still being postponed.

Or, from a more positive and manageable angle...

Imagine that people on the team are complaining about some concern. Maybe it’s a ridiculously designed service in the code, a CI/CD issue, slow builds, lack of documentation, poor performance, or even bad coffee in the office kitchen. Anything important! But at the same time, the work on this issue doesn’t look fancy, so no one wants to handle it, but everyone complains.

So go ahead and just do it!

Simply put — take the risk. Step in like a knight in shining armour. Don’t ask for permission from the leader. You have a lot to gain (if the issue is truly worth addressing). The fact is, if you approach this responsibly, you stand to gain a lot. We’ll talk about the consequences of failure another time.

What can you gain? What will your reward be?

Let’s start with the surprise factor—for the team, your boss, or the client. The effect? Something unplanned but valuable gets done without visible delays in planned activities (that’s the point). You build greater trust.

Increased self-confidence. Wouldn’t you feel more confident in the team if you managed to deliver something extra that no one asked for, but everyone needed? Glory and recognition await. Just scoop it up with a spoon.

Valuable experience. Even if you fail to deliver the intended result or mess up the regular tasks, you’ll still gain experience. Getting a reprimand can be just as valuable as success. There will be lessons to learn for the future. You’ll realize: maybe this wasn’t the right thing to do? Maybe the decision was made at the wrong time?

Don’t expect applause

That’s not the point. It’s nice if someone thanks you for your contribution, but this isn’t about quick gratification. What should matter to you are the long-term benefits:

• Increased trust in you within the team.
• Experience.
• Boosted confidence (but exclude the ego from it).
• Potentially you’ll become the go-to person for special tasks?

Every bit of additional value you deliver to the project will contribute to your premium card when negotiating a raise.

Money is one thing. Remember that your activity will, over time, give you access to under-the-table project information, as leaders start to trust you more, making it easier to influence the project’s direction.

When is it worth it?

The surplus activity must have a purpose and foundation. In my opinion, it’s worth investing in this type of effort when working on a product. I mean long-term projects—those where it makes sense to look for optimizations and where there’s room for conducting R&D (research and development).

I think it makes less sense for short-term projects, where the schedule is usually tight, and mistakes can have unnecessary consequences.

One small note: if project leaders are incapable of appreciating the work of their subordinates, then it’s probably a waste of time for extra activities. Unless you approach it as a personal development opportunity. But be cautious.

You know, don’t do this in a project where it’s just not worth it...

Thanks,
~KB