Improvement Is a Skill, Not an Opinion

Here is the lie that almost every engineer believes at some point in their career, usually early. The lie is that being right about the technology is the hard part of the job. That if you can just see clearly what is broken, understand deeply what should replace it, and back it up with enough technical reasoning, the rest will take care of itself. The rest being: the team accepting it, the manager approving it, the organization absorbing it, and the thing actually getting built.

It took me years to realize that being right about the technology is the easy half of engineering. The hard half is everything that happens between the moment you see the problem and the moment something actually changes because of you. That second half is not a soft skill, it is not a bonus, it is not something you pick up on the side. It is a completely separate craft, and it is the craft that determines which engineers spend their careers being frustrated that nobody listens, and which ones spend their careers quietly fixing things that everyone thanks them for later.

I want to write about that second half, because nobody talks about it until you have been burned by ignoring it. And the cleanest place to see it is in that very specific moment every engineer knows: your first weeks at a new job.

The first week at a new job is always the same. You get your laptop. You wait three days for the access rights that were supposed to be ready on day one. Someone finally shows you the repo, and within another three days you start seeing things that look wrong. A deployment process with a manual approval step that nobody can explain. A naming convention that is almost consistent but not quite. A shared library that is vendored into five different repos at five different versions. A production database that is accessed by a script nobody wants to touch.

If you are any good at your job, you notice these things immediately. You were hired because you notice these things. And your first instinct is to say something, because saying something is what competent engineers do when they see something that could be better.

That instinct is the whole problem. Not because it is wrong. It is correct. The instinct is pointing at real issues. The problem is that the instinct is the easy half, and acting on it without the hard half is how good engineers turn into the person nobody wants in their meetings.

The First Week Is the Worst Time to Propose Changes

The trap of that first week is that you have maximum visibility and minimum context. You can see the surface of every system because it is all new to you, but you know nothing about why any of it is shaped the way it is. That asymmetry is dangerous, because it makes you feel like you are noticing things that the existing team has missed. Sometimes that is true. Most of the time it is not.

The engineers who have been there for years have stopped seeing the weird parts because they know why those parts exist. That looks like blindness to you, and occasionally it really is. But more often it is the exact opposite. They are not seeing it because they already processed it, weighed it, and moved on. You are seeing it fresh because you have not done any of that work yet.

Before you say anything, you owe it to yourself and to the team to do that work. Otherwise you are not proposing a change, you are leaking an impression.

Three Things You Are Probably Missing

The first thing is history. Almost every system that looks weird has a story behind it. The manual approval step in the deployment pipeline is there because two years ago an automated script took down production during a silent schema migration. The naming convention is almost consistent because the first three services were written before the convention existed, and the cost of renaming them would break every downstream dashboard and alert. The vendored library is vendored because the upstream maintainer abandoned it, and the team forked it to keep shipping. None of this is documented anywhere. It lives in the heads of people who were there when it happened, and you will only hear it if you ask. This is one of the hidden benefits of working at a small company where everything is your problem: you are forced to absorb the history because there is nobody else to absorb it for you.

The second thing is maintainability in the context of this specific team. A better architecture is not automatically better if nobody on the team knows how to run it. Kubernetes is more elegant than a set of VMs with manual deploys, but if the team has never operated a cluster, you are not upgrading the infrastructure, you are introducing a new class of operational risk that nobody knows how to respond to when it breaks at three in the morning. The question is not what the best system looks like in the abstract. The question is what the best system looks like given who has to live with it.

The third thing is business value. Stable and boring is a feature, not a bug. Systems that work do not always need to be optimized, because the hours you spend optimizing them could be going into something customers actually feel. That is not conservatism, that is prioritization. Engineers who have not internalized this confuse “I could make this better” with “I should make this better”, and they end up rewriting infrastructure nobody was complaining about while the actual product rots.

This Is Not a Defense of Doing Nothing

I want to be clear about what this post is not. This is not an argument for sitting still, keeping quiet, or deferring to whoever has been there longest. Organizations that wave off every new engineer with “you do not understand our context” are exactly the organizations where good people leave within a year. A fresh perspective is valuable precisely because it has not been conditioned by the history. You should protect that perspective, not suppress it. You just need to learn when to voice it and how.

There is a real difference between an organization that has made thoughtful trade-offs and an organization that is just dragging its feet. Both look the same from the outside on day one. The skill is learning to tell them apart.

Trade-off or Inertia

The difference is not invisible. There are signals. When you ask about the history of a system and people can tell you the story, with specific incidents and data and the trade-offs they weighed at the time, you are probably looking at a trade-off that you did not yet understand. When you ask and you get “that is just how we do it”, “someone decided that years ago and nobody wants to touch it”, or a shrug, you are probably looking at inertia.

Inertia is your target. Trade-offs require more homework before you open your mouth. The mistake new engineers make is not that they propose changes. It is that they do not distinguish between the two and fire all their arrows into the same bucket regardless. When your first three proposals turn out to be trade-offs you had not noticed, nobody takes the fourth one seriously even if it is genuinely inertia. You spend your credibility on the wrong targets.

Complaints Are Free, Proposals Are Work

If you want to call something bad, bring a solution. If you do not have a solution, you have an observation, and observations alone do not build anything. Anyone on the team can see that something is off. What is missing is the thinking about what should replace it.

That thinking has three parts. Understanding why the thing is the way it is. Figuring out how it could be different in the context of this specific team and this specific workload. And being honest about what the transition would cost and who would pay for it. Do those three steps and still have a proposal, and it deserves to be heard. Stop after step one and you shared your frustration, not a proposal. Frustration is for the couch on a Wednesday evening, not a retro.

Non-Judgmental Questions Are a Real Move, Not a Caveat

Asking questions the right way is one of the most powerful things a new engineer can do, and it is consistently undersold. People who ask questions are engaged. Most engineers love being asked to explain why something is the way it is, because it lets them show their work. A good question turns the conversation into a collaboration instead of a confrontation.

The framing is where it goes wrong. “Why is this set up so badly” and “can you walk me through the decisions that led to this shape” are aimed at the same information. They land in completely different places. The first is a complaint dressed as a question and every senior engineer in the room will hear it that way. The second is an actual question and it will get an actual answer.

The difference is whether the question carries a verdict inside it. A non-judgmental question leaves room for the response to be “we thought about it this way and here is what we decided”, and it also leaves room for “honestly, nobody has looked at that in three years, you might be onto something”. You get neither of those if your question already assumes the conclusion.

The rule is not “come with the answer”. It is “come with more than your frustration”. A question asked in real curiosity is one of the most productive things a new engineer brings to a team. A question with the answer already tucked inside it is one of the least.

There Are People on Both Sides of This

There is one more thing I want to say, and it is the part that took me the longest to understand because it is not really about engineering at all.

Everything I just described happens between people. Real people, who are tired, who are attached to the work they have built, who have had a bad week, who might feel defensive when someone walks in and says their deployment pipeline is a mess. The trade-off you are evaluating as a technical artifact is, for someone else in the room, the thing they built four years ago that got them promoted. The deployment process you find clumsy is, for someone else, the reason the team did not have a major outage in two years. That does not mean the work should be preserved, and it does not mean you should stay quiet. It means that how you say what you say determines whether it gets heard at all.

This is why bringing things well and bringing them grounded matters so much more than bringing them sharp. There is a decent chance that the person who built the thing you want to change is sitting in the same meeting where you are about to propose changing it. That person did their best with the information and constraints they had at the time. They did not ship something bad on purpose. They shipped the best version of it they could given everything that was true two or four or six years ago. A well-founded proposal respects that. A casual dismissal does not. And the difference between those two is almost entirely in the framing, not in the technical content.

This runs in both directions. If you are the new one, the person you are about to challenge is a human being who built that thing with the information they had at the time. If you are the senior one, the person who just showed up with a proposal is a human being who was probably more nervous to bring it up than you realize, and braver than you give them credit for. The meeting where these two people talk about the thing is going to go a lot better if both of them remember who they are talking to.

The strongest engineer I worked with in my first real infrastructure job was not the one with the sharpest opinions. She was the one who, when she wanted to change something, would spend a morning talking to the person who originally built it before opening a single pull request. Not to ask permission. To understand what the original constraints were, so her proposal could account for them instead of stepping on them. By the time the actual meeting happened, she had already won half the argument, because the person whose work she was changing felt included in the reasoning rather than cornered by it. I watched her do that a dozen times in two years, and every single one of her proposals landed, because she had done the relational work before the technical work.

That is not a soft skill. It is not a course you can take. It is the thing you only pick up by working with people long enough to realize that the code is the easy part, and the hard part has always been the meeting afterward. It belongs in the same bucket as the other things nobody teaches you on the path into this field: lessons that arrive through experience or do not arrive at all.

Look back at everything we just went through. Holding your reflex until you understand the context. Telling a trade-off from inertia. Bringing a proposal instead of a complaint. Asking a real question instead of a loaded one. Remembering that the person on the other side of the table is a human being who did their best with the information they had. Not one of those things is about the technology. Every single one of them is about what you do with being right.

That is the hard half. It is why two engineers can see the same problem, come to the same conclusion, and only one of them actually gets it fixed. The other one was right too. Being right was not the bottleneck. The bottleneck was everything that came after being right, and they never treated that part as work that deserved their full attention.

This is why the title of this post is what it is. Improvement is not an opinion, because opinions are free and everyone has one. Improvement is a skill, because skill is what you call the difference between someone who sees the problem and someone who actually moves the thing. You can be the smartest engineer in the room and never move anything, and the industry is full of exactly those people. You can also be a quiet engineer with middling technical opinions who somehow always ends up making things better around them, and when you finally figure out how they do it, you realize it was never about being smarter. It was about treating the second half of the job as seriously as the first.

That is the part I wish someone had told me on my first day. Being right is the easy half. Everything after that is where the work actually lives. I am telling you now, because the sooner you know it, the sooner you can start getting good at the half that matters most.