I recently wrote an internal Management 101 guide for new RevenueCat managers. It is not meant to be a universal management guide. Most universal management advice is either too vague to be useful or too generic to survive contact with a real company.

My goal was simpler: explain what we expect from managers, why the role matters, what tends to feel weird at first, and where to start when things get messy.

One of the sections I think matters most is the dopamine problem, because it is one of the most immediate changes. The weirdest part of becoming a manager is that your old scoreboard disappears.

As an IC, you can point to things you shipped. Code merged. Bugs fixed. Systems improved. Customers helped. Even hard weeks usually have visible artifacts.

Management work is slower and less satisfying in the short term. You can have a great week and nothing obvious happened. A project got slightly clearer. A candidate stayed warm. A conflict did not become a fire. A direct report heard feedback early enough to fix something. A team avoided a bad architectural decision. A future manager took one more step toward readiness.

That is real work. It just does not always feel like it.

This is one of the hardest parts of the transition from IC to manager, especially for Engineering Managers. You are used to being useful in a very concrete way. You know how to debug the issue, review the design, write the code, fix the incident, and unblock the team. Then suddenly a lot of your work becomes indirect. You need to stop trying to solve the problem in front of you. You need to make the team better at solving that type of problem in the future.

It is also getting harder in the age of AI. Agentic coding is even more addictive. You can describe what you want, watch the agent work, review the diff, and get a working prototype or bug fix in minutes. The loop is fast and incredibly satisfying.

This is why many new managers cling to coding, technical details, or direct execution. It gives them the old dopamine. It also feels useful when there is urgency: a project is at risk, a technical issue is blocking the team, or execution is moving slower than you think it should. Sometimes stepping in directly is the right call. If production is broken, do not sit there having a philosophical debate about leverage. Help.

But most of the time, direct execution is a patch around the real problem.

If the project only moves when you personally drive it, something else is broken. Maybe ownership is unclear. Maybe the team does not have enough context. Maybe the technical plan is too complex. Maybe the bar is too low. Maybe someone needs feedback. Maybe you have the wrong people on the problem. Maybe you are still acting like the tech lead because that is more comfortable than acting like the manager.

Your job is to make the team capable of executing without you, either by hiring the right people, training people up, clarifying ownership, or raising the bar. If you keep solving the work yourself, you prevent yourself from learning the new job and prevent the team from growing into it.

You need to rewire your satisfaction from “I shipped the thing” to “the team is stronger and shipping better because of the work I did.” That takes time.

Some practical advice:

  • Set weekly goals for yourself. Not vague goals like “be a good manager.” Concrete goals: write the 30/60/90 plan, give feedback to X, unblock Y, clarify ownership for Z, source X candidates, review hiring funnel metrics, talk to another manager about a problem.

  • Create accountability. I use weekly emails. Use whatever works, but do not let weeks disappear into meetings. A full calendar is not evidence of impact.

  • Write things down. Writing forces clarity and creates artifacts when the work itself is abstract. If you cannot write the decision clearly, you probably have not made the decision. If you cannot write the feedback clearly, you probably do not understand the behavior well enough yet.

  • Look for compounding work. Better onboarding, better interview calibration, clearer team ownership, stronger tech leads, training people up, and improved decision-making pay off repeatedly. They may not feel as satisfying today, but they make the company more capable.

Management is not a promotion from building. It is a different way of building. You are building the system around the work: the team, the standards, the ownership model, the feedback loops, the hiring bar, the culture, the decision-making.

The hard part is that the system does not always give you a green checkmark at the end of the day. Do it anyway.

Originally published as an X article on July 10, 2026 and archived here.