Get the guide to build your first AI agent directly in your inbox with a newsletter signup:
There are two ways of working. And I’m sure that you will be able to identify which one you have and which one people around you have.
One of them is chasing people for answers and answering every question with another question.
For example, you know that you have a dependency, and you are just pushing the work into them. They are blocking me; they are pending this; they are pending that.
In the case of the second way of working, you’d do things differently. You know that you have a dependency, and rather than just pushing the ball to them and waiting for an answer, you make a proposal. You are making progress in the work, instead of moving the work around.
Think about working with this second type of person. Someone who is absorbing bureaucracy. Someone who is shielding you from having to deal with the complexities of the entire team or even the entire company. Someone who understands that as a software engineer, you have to focus on the technical details. So they protect your focus on development.
Which type of way of working would you prefer in your team? Which one do you think is better?
In this article, we will explore the two ways of working. We will also understand the drawbacks of this second way and how to make sure you have the good without having the bad. If it were perfect, everybody would be working like this.
👉 If this sounds interesting, subscribe now. 22,000+ engineers are already becoming more productive. Paid subscribers have access to premium resources
Taking ownership at work means helping resolve the problem
There is one keyword that all the leadership books like, which is ownership. For me, ownership is about having a skin in the game. It doesn’t mean that you do all the work yourself, but you are responsible for this work. So you are contributing where you can and connecting people where you can’t do it yourself.
Ownership is about you wanting to make progress on the problem. I’m helping anyone who is making progress on the problem. It’s about actually thinking about how you can make progress on the problem instead of delegating to an AI or pushing the problem to someone else.
For example, part of doing the thinking is never saying “This is not part of my task”. If someone asks you something that is out of the scope of your task, you at least have some thinking and propose some actions, even if you don’t take them.
You are going to change one test, and then suddenly someone says that you should take a look at all the other tests. Then you take a look and say: “Okay, I see that there are more changes needed. Let me create a separate ticket or let me take action in a new code review, as this one was for X purpose, and it’s still valid”
The bad way of working would be just not doing anything.
Unfinished thinking becomes someone else’s work
There’s an anti-pattern in the corporate world, which is threads. Be it in email or any other tool like Slack, it’s very tempting to just add someone else to a thread and push the problem to them.
My team uses Slack, and I’m constantly getting pinged on things where it’s true that I can contribute, but other people could have made progress, so when I arrive, I’m just… having less work to do.
At least if you are adding someone else to a conversation, you have to give them a brief context and also a clear action needed from them.
Coordination that removes work from an engineer’s plate
This way of working is especially important for software engineers. We are people who need time to think and focus. And now, with AI doing all the implementation, it’s more important than ever. We can get very fast down the wrong path if we don’t have the time to think.
Now imagine the opposite way someone is adding you to something where they have a clear proposal and they need five questions from you. It is very easy for you to answer those questions, refine the proposal with your information, and get alignment very quickly.
This is what at Amazon is called internally: asking questions the right way. You don’t ask something like “Hey, I don’t understand.” You do your investigation, you form an opinion, and you ask targeted questions, given the proper context.
Don’t be the engineer who only relays AI output
I already wrote about this anti-pattern, but I think it’s more important than ever.
The other day I saw this post on X about people working in the biggest AI labs. They still write their own text.
And it’s true that there is a benefit in writing because writing is thinking. I have been journaling for a while, and it’s almost therapeutic to write down your thoughts.
Everybody has AI tools nowadays, so I am not asking anyone to get an AI output. I will just ask the AI directly.
This website below is quite funny. It reminds me of the days of the other websites about no hello (don’t say hello and wait; say hello and send what you want directly)
https://dontpastetheai.com/angry/ (Yes, there are different versions and I share with you the angry version)
Now you should be convinced that the point where you are employed is to think. It wasn’t always about writing code; it was always about thinking.
So we need your actual thinking applied anywhere you are required.
Do the thinking that makes your next action useful
So now let’s make this article practical. Whenever you are involved, at least do the following:
Clarify the expected outcome (with people)
Check the relevant facts (You can use AI here; it’s pretty good at it)
Identify any assumption or any decision that is not yet resolved.
Resolve as many as you can based on your knowledge or your responsibilities.
For the ones that you can’t resolve, make a suggestion and find the relevant person, giving them the precise input that they need and the right expectations.
So now, going back to my example: you are changing one test, and someone asks to change something else in other tests.
At a minimum, what you should do is check it. At least you get an informed opinion to answer that person.
You will also identify what kind of improvements we can make, even if you didn’t dive too deep. And answer with an approach, even if you are not doing it at all. You should have clear next steps.
And you can still use AI in all of this, but you have to form an opinion yourself. Gather the evidence with AI. Review your opinion with AI to challenge it in an adversarial review. But you are still the one responsible for doing the thinking.
It’s like if a manager or a director or a vice president was not doing anything themselves because they just plainly relay what their reports tell them to the higher-ups, that person will be fired immediately.
This is not only about adding value to the rest of the company. This is helping yourself because you will have an understanding of things. You can check this article that I wrote about Automate the Work, Not Your Understanding —
Conclusion
Remember once again, your contribution is the thinking and the judgement.
One challenge that I give you is reviewing your last messages and emails that you sent. Are you actually moving the problem around, or are you actually making progress towards solving the problem?
Let me know in the comments any example that you want to share, from you or from someone else, that shows the patterns in these articles.
If you found value in this post:
❤️ Click the heart to help others find it.
✉️ Subscribe to get the next one in your inbox.
💬 Leave a comment with your biggest takeaway
♻️ Share it with your peers
This article helps with phase two: becoming proactive and regaining time. Clarifying problems and making useful requests can reduce unnecessary coordination and protect your focus.
I’m building this system below for paid subscribers. Thanks for your continued support!
Related Software Engineering Guides
Fran, creating a separate ticket for the other tests keeps the original code review from growing endlessly. You can acknowledge that more work is needed and give it a clear next step without holding up a change that’s already ready to go.