flávia bastos

Do you see yourself as a fixer or a flagger?

Here’s a test for you:

It’s your first week on a new job. You’ve done all the HR required training and now you can finally start ramping up on the codebase and setting your laptop up with the tools you will need to do your job. Thankfully this team has onboarding documentation. Yay!

As you go through the docs you notice that there are some gaps: some things are outdated and there are broken links, for example. You spend time chasing the correct information and by the end of the week you have everything in place to start working.

Question: what do you do with the documentation?

a - I update the docs

b - I bring this up with a colleague or mention in a team meeting

c - Nothing

If you answered “a”, congratulations, you are a fixer. You don’t wait for people to ask you for stuff or get tickets assigned to you. You are biased toward action. Go ahead and call yourself a trailblazer!

If you answered “b”, well, you my friend are a flagger. Let’s call you a ‘watcher’.

Now, if you chose ‘c,’ you might be missing an opportunity to stand out and contribute more effectively.

So why does this small choice matter?

This is, of course, a trivial example but it’s one simple, low-hanging fruit to immediately add value to your team and company right out of the gate. Documentation may be a debated topic, but most developers have encountered this exact scenario. Other similar examples include fixing typos in the codebase or removing commented-out code (that’s what source control is for!).

While this might seem like a small example, these everyday choices shape your reputation and impact over time. If you reflect on your daily actions, you’ll likely see a pattern—do you lean more toward ‘fixer’ or ‘flagger’? What’s the tally at the end of the day or the week?

My point here is: don’t wait for permission or an assigned ticket. Take action first — ask for forgiveness later if needed! Most (good) managers are more than happy when team members show initiative: it shows that you don’t need hand-holding and can self-manage. You can be entrusted to not only do your job well but also look out for the benefit and improvement of your team and the product you develop. It puts you in a position to be first-of-mind when opportunities arise. For a leadership level, it’s a lot easier to justify a raise or a promotion for a person who is always adding value and looking for ways to help reach the company’s business goals.

If the points above didn’t convince you, consider this: in an age where LLMs can generate code in seconds, being proactive and showing initiative is one of the most valuable skills a developer can have.

So, other than the trivial examples above, here are some questions to help you start thinking about other areas where you can help:

• Are there processes that could be implemented or improved?
• Are there manual tasks that could be automated?
• Is there documentation for the processes and information that your team needs to do the job well? Is the documentation up to date and easily accessible? Could the documentation be simplified, condensed or even removed or replaced by a script?

Sometimes we fear doing something wrong or getting in trouble so we choose inaction. It seems the “safest” option. Is it though?

And just in case you’re curious, the story at the beginning of the post really happened. The person flagged the issue in stand-up — but what if they had just fixed it? Which approach do you think makes a bigger impact?

Thank you for reading!

I'd love to hear your thoughts — let's keep the conversation going on X: @Flavia_SBastos