One thing that I've consistently noticed effective software engineers do is this: they keep the ball rolling.

But what does that mean, exactly?

It means that they don't just point out problems - they take the first step towards solving them. Mind you, this doesn't mean they solve the problem on their own. In reality, people often won't have the time or bandwidth to do that.

What this does mean is that they kickstart the process by which problems get solved. And they always make sure that momentum builds, and doesn't stall.

Let me share two examples to illustrate this:

Scenario 1: Spotting Issues, Then Dropping the Ball

Imagine an engineer notices a problem - maybe a subtle bug, an API design flaw, or an architectural inconsistency - and posts about it in a Slack channel or comments on a ticket:

Hey, this doesn't seem right. Looks like there's an issue here.

Technically, they're not wrong. And it's good that the engineer spoke up and pointed out the issue. But guess what usually happens next: Nothing.

Others will probably read that message and think, "Yeah, good point. Hopefully someone will take care of that." But no one does, because no one feels responsible. The issue remains.

More effective engineers carry the thought a few steps further:

If it's not your team's service:

1. Find out which team owns it.
2. Bring the issue to their attention.
3. Ask for confirmation: Is it actually a bug? If so, will they fix it? If not, why does it behave this way?

Boom - just like that, you've passed the ball to the right team, and they're now in motion.

If it is your team's service:

1. Determine whether this really is a bug or just a misunderstanding (there's no need to spend much time on this - just ask others if you're not sure).
2. If it's a legitimate issue, create a ticket with the necessary context and reproduction steps (bonus points if you include logs or screenshots!).
3. Share it with your manager or whoever manages team planning, so the work can be prioritized.

In both cases, you're not just pointing at a problem - you're kicking off the process to resolve it. You're keeping the ball rolling.

Scenario 2: Pushing Back Without Pushing Forward

Here's another situation. An engineer reviews a ticket or pull request and responds:

This doesn't make sense. I don't agree with this approach because A, B, C. <end of message>

Fair enough. Once again: it's good that issues are being pointed out. This opens up an opportunity for both parties to discuss the problems with the proposed solution, and to work together to come up with the best solution that both engineers can think of...

...if the engineer pushing back actually takes this opportunity.

In this scenario, the conversation stalls. The critique doesn't open a path forward - it just creates a block.

A more productive response would be:

I don't think this approach works because of A, B, C. What if we tried X instead?

Now we're moving again. Instead of stopping the flow of progress, you've helped steer it in a better direction. Even if X isn't the perfect solution, at least you've shifted the focus from a dead-end critique to a collaborative conversation about trade-offs and alternatives. You ensure sure that momentum builds, and doesn't stall.

---

What ties these examples together is ownership - not in the sense of doing everything yourself, but in starting the process that gets things done.

Effective engineers know that momentum matters. They look for the next actionable step and make sure it happens - whether that means routing an issue to the right team, creating a ticket, or suggesting an alternative solution in a disagreement.

Long story short: They keep the ball rolling.