First month in a new company - How to go about improving things?

In one of the tutorials and also in my discussion with Rahul, the advice was to not rush towards suggesting improvements right away.

I understand the overall mentality there, but I feel like that's more around suggesting sweeping changes. To make things clearer, here's an example:

• Bad: "Our CI/CD pipeline is really janky - We need to rewrite the entire thing."
• Good: "We don't have a wiki on how to set up our Visual Studio linter, so I had a really hard time with it. Should I write one so future employees can onboard more smoothly?"

A common way to make the "bad" even worse is to say, "At my previous company...". This will make your team believe that you are blindly copy-pasting old practices from your prior job, because it's the easy thing for you to do.

The "good" one is effective for the following reasons:

• It's small - Writing a wiki is pretty harmless and won't take more than a few hours. Even if it ends up not helping, the loss wasn't that large.
• You put yourself on the line - This makes your feedback constructive as actions speak louder than words. Anybody can complain and try to foist some new giant effort on the team. Fewer can show that they're legitimately acting in good faith. When you do this, you will earn trust way faster on the team, which will pave the way for you suggesting larger improvements in the future.

For more resources around onboarding, I recommend these as well:

• "How does technical onboarding differ as you go up the ladder?"
• "What questions should I be asking my onboarding buddy?"
• "E5: How to participate in discussions effectively without context?"

One mistake I made starting at a new job was not looking at the company's past design docs and learning how they implemented solutions. For example, in the first month or so, I went about trying to write a 10+ page design document for a very general re-rendering performance problem when most of the company's design docs were only 1-2 pages long tackling very specific issues. The lesson is: do not rush trying to prove yourself. Gain a lot of context on the problem first—then your solutions will be much more refined. Honestly, give yourself 3-6 months before proposing anything... This will save you time in the long run.

I also heavily recommend this: [Masterclass] How To Build Deep Relationships Quickly In Tech

Senior engineers are generally expected to be "influencers" on the team and level up the overall engineering culture. You already have the first step done by seeing many areas for improvement - The next step is to earn trust of the people around you, so you have enough social capital to push through those improvements.

On a final note, I just want to say that all this will take time. It's a process building up relationships and getting others truly "on your side". A good senior engineer is one who understands that they will need to plant seeds that take a while to grow. 🌱