Changing things when you're new

When you arrive at a new company, you have that new starter energy. You want to get your hands dirty, and start making change. You are sure your knowledge and experience along with your fresh perspective can bring something to the team. You are not wrong, but I urge you to keep it simple.

Keeping it simple at the start is a powerful tool. It won’t stop you from bringing in change later, and it gives you time to focus on what is truly important: listening.

Each company is different, shaped by its people and the business context. When you listen you give yourself a chance to learn. Maybe they have tried your idea before, maybe you have to follow specific processes, maybe your process is there slightly hidden.

I did not keep it simple when I started, and I did not pay attention to the processes in place. Because of that, I made two mistakes. One where I added complexity, and one where I could not complete a small project, so I added noise. Both could have been avoided.

On the complexity side, when I onboarded I looked at our coding environment and realized we were using Rye to manage our Python dependencies. Well, the first thing you see when you try to get Rye is that you should use UV. So, I made the change to UV, updated some onboarding docs, and tried to push the change through for the projects we were working on - it should have been trivial. It was not, and it has not happened yet. In my company, change requires a few steps, very much a different approach to my “startup-y” jobs. We had a new joiner come in, and now his developer experience is less than ideal. There are multiple ways to set up your environment - this needs fixing. Lesson learned.

Or at least I thought I had learned it. I noticed some other inefficiencies in our documentation and making requests to our microservices. I wanted to bring in some structure to our team, start a repository, host some HTTP requests collection, and then share that with the team. Again, because I didn’t understand the limitations of the process of “doing new work”, I got stuck with an empty created repository, and no way to commit my collection of requests until I have a ticket assigned. More noise, no benefit.

I could argue the system is broken, stopping me from innovating and iterating. But the reality is that I need to learn the system, and then perform change from within. Get the right allies, prove why this change is valuable, and then work on it. If I want to simplify the system, I also need to do it from within the existing system.

So yeah, note for future self, listen, learn, change. Keep it simple at the start, and iterate.

Comments