Lessons from a manager

A while back, on a team I worked on, I got to sit through a lot of one-on-ones with the team’s manager.

Every time we had an important conversation, I took notes. After he left the company, I decided to gather them. This is what came out of those hours of listening and learning from him.

This is not a manual. These are phrases said out loud —as they came— that got clearer with time.

1. Learn for real

At some point in the project, new requirements landed and we had to pick up technologies we didn’t know. He suggested the Feynman technique: study, teach, fill the gaps.

The idea is simple and demanding. Don’t study so you can say you read the docs. Study until you can explain it. Teach it to someone on the team, or say it out loud to yourself, in your own words, without hiding behind jargon. If you get stuck, that gap is the syllabus. You go back, fill it, and simplify again.

Group study helps, because the other person hears what you treat as obvious. Talking to yourself helps too: if you can’t say it out loud, you don’t understand it yet.

If Feynman doesn’t work for you, that’s fine. Find your own way to learn. A technique is not a religion. What matters is having a method of your own —and sticking to it— so you can keep up when the stack moves.

The practical sibling of Feynman is the POC loop: try and apply, review and reflect, improve and evaluate. Understanding is not enough. You try it small, apply it, look at what you learned, and only then decide whether it scales.

2. Don’t suffer in silence

Stop suffering in silence. Your manager should be the person who’s there for you when something isn’t clear, when you feel under pressure, or when you can’t find a path to a solution. When you’re frustrated, talk to the manager.

He may not solve the problem every time. He can listen, and help you think about what’s going on. Sometimes we would start talking about a “weird” ticket and I’d walk out realizing the situation wasn’t the code: it was a lack of clarity, a date nobody had questioned, or a path I still couldn’t see.

Talking is not just venting. It’s diagnosing. Find the reason for the frustration. We often hide it and keep it to ourselves. We don’t want anyone to know what’s happening to us. Putting it into words lets you dig into the why. It might be the ticket, the team, the PO, the world, politics. Until you give it a name, it will remain fog.

Most frustration comes from not being able to say that something came up, something is missing, or something was never considered. Speak up. Tell people. Comment. Let the team know what’s going on.

Remember: don’t suffer in silence.

3. Be professional. Be kind to yourself.

We are human, not machines. We feel and we think. When someone comments —in an MR/PR or in a 1:1— on something you may not like, don’t take it personally, even if it sounds that way. Be professional. All of this is so the work is good, so you grow as a professional, and hopefully as a person too.

Don’t punish yourself if the goal wasn’t met, or if something we should have finished got derailed by surprises. The sky doesn’t fall down for that! . Be as kind to yourself as you are to everyone else.

Taking it personally and punishing yourself are two sides of the same thing: turning work into identity. A comment on the code is not a verdict on you. A sprint that got away from us is not a sentence. Do the work well, and still be able to show up tomorrow.

4. Own your work: time, promises, and goals

We should be able to keep our promises. For that to be possible, you have to know —or at least see— the path you need to walk. If you can’t see that path, a “yes” is not a commitment. It’s hope. Saying “I don’t know how long this takes yet” is more professional than an optimistic yes nobody can stand behind later.

A lot of the pressure we put on ourselves comes from not managing time. Learn to manage it and you own the work, instead of living off whatever is left after feeds, news, and doomscrolling.

Always set goals you can actually hit at work. They keep you in shape, growing, and with a reason to chase the company’s objectives too. A small, concrete goal —close a knowledge gap, make a module clearer, finish something you’ve been putting off— organizes the week better than a vague intention to “get better.”

A longer north matters too. There’s a slightly ironic hypothesis about why Warren Buffett is still going: long-term goals that give you a reason to keep living. At work this isn’t self-help. It’s a craft five or ten years out —not necessarily a title— that helps you decide what’s worth learning, which fight to pick, and which noise to ignore. Short goals keep you moving. Long ones tell you where.

5. Think about the system, not just the ticket

Different parts of the team think at different levels. Product and the PO usually start from the problem and the outcome. Whoever implements starts from the detail. The manager, if they’re doing the job well, translates. Yours is not to get stuck at the bottom or speak only in abstractions. It’s to move up and down on purpose. Rough idea, design, detail — then back up so you don’t lose the why.

Companies like people who can think holistically, who see the big picture: beyond the project they’re on. People who ask what else this touches, whether there’s another way, whether some other piece of code already does this. Getting involved at that level is not “leaving the ticket.” It’s building a product, not an island.

Things are not always what they look like. If something feels off, look for a way to change it. If you need to, talk to someone and say what you’re thinking: a design that doesn’t quite convince you, a decision that smells wrong. Intuition is not a whim. It’s a hypothesis. Argue it. Don’t swallow it, and don’t impose it.

And when the work runs out, don’t get lost in social media. If you have nothing to do, become a thinker. Look at the horizon. Sit with it. Don’t talk about thinking: be a thinker. Not only about work. About life.

6. The craft, working smart, and difficult people

Writing good documentation is a challenge we all have. Docs are a guide for developers. With AI, writing them looks easier. Remember what they’re for: understanding the system, and the kind of decisions that were made in the past. AI speeds up the text. It does not guarantee the text is true, or that it captures the why. A guide for developers is not decoration and not a dump of the code. It’s the map someone will need when you’re gone.

Don’t let the code age. It’s one of the bad symptoms of software projects: we don’t keep libraries current, we leave obsolete patterns in place, and then every new feature costs more. This is not about rewriting everything. It’s continuous hygiene —dependencies, small debts, not waiting for the big redesign that never comes.

When we talked about working smart, AI was barely being adopted. Not many companies had jumped. ChatGPT had just shipped its second model. Today the lesson is not “use AI.” It’s not confusing the speed of generating text or code with having thought about the problem. Working smart is choosing what not to do, what to automate, and what still asks for judgment.

Convincing people is hard. For some people, the best argument, the best proof, or the best evidence will not move them. You will run into people like that, no question. It isn’t always that they don’t understand. Sometimes the disagreement isn’t technical: it’s ego, power, incentives, identity. Learn to tell when it’s worth pushing and when the right move is to document, escalate, or stop hitting that wall. Don’t spend all your energy there.

It’s been a long time since we last talked. Some of these lessons have mutated with the influence of AI —learning, documenting, working smart no longer feel the same. Others barely moved: don’t suffer in silence, don’t take it personally, keep your promises. The core holds.

Thank you, wherever you are, for those hours.