I’m currently a “staff software architect” at a 3rd party cloud consulting company.

What not to do:

1. Disrespect current processes. What you call “legacy code” was done for a reason, is generating revenue, solving real world problems, and the reason you have a job

2. Make any suggestions about improving processes before you have been their at least 90 days and understand why the current system is like it is.

3. Suggest rewriting something or introducing new to the company technology until you have worked there 90 days. Especially don’t start doing resume driven development.

What to do:

1. Set up a meeting with sales and ask them to “sale you the value proposition of the product as if you are the customer”. Ask questions as if you were a potential customs and raise objections to the product as if you were customer. Sales is usually very good at answering those questions.

2. Talk to your manager and ask what are their 90 day and 1 year plans for your team and make sure your work is aligned with the goals.

3. Get to know the pecking order. The org chart will not show you who has the most influence in your department.

4. Setup “getting to know you” 1-1’s. What are people working on? What do they want to be working on? What are their biggest pain points? What would they improve if they had a magic wand?

5. Pick up small stories, bugs to get familiar with the development process.

6. Learn about pre-wiring a meeting when you are trying to suggest changes. Do a POC, talk to the person who might have the biggest objection or has the most influence and work collaboratively to address their objectives. Keep doing that for more people on your team. It helps get more people on your side.

ADKAR change management model

https://www.prosci.com/methodology/adkar

When I onboarded at a larger (10k people) company, I asked my manager for people who did a similar role to me across the company and asked for a fifteen minute time slot on their calendar to ask about how they work, what they thought was vital for me to learn or would be an accelerant to my onboarding, any tips or tricks for working with the company or our tools, and other people they thought would have good answers for those questions, and then rinse and repeat for that new list of people. I ended up doing ten interviews in my first two weeks, published a little internal blog post about common themes and what I learned, and that helped shape a lot about how I worked. Not to mention that type of proactivity in and of itself impressed a lot of people; doing things for clout is dumb but making things you learn public and synthesizing them into a form that's accessible to others is an important hallmark of a senior in my opinion.

Ask SO many questions. Got opaque docs that are important? Ask for a quick meeting with the person who wrote them to make sure your understanding is crystal clear. Abandoning ego and being a knowledge sponge makes such a huge difference.

Almost every time I join a company/project, they don't have even remotely accurate docs about how to set up a development environment (configure workstation with prerequisites, check out the code, run the code).

If they already have a wiki page you can start editing, great. If they have a wiki without such a page, great. If they're open to having this info in the README.md of the repo, great.

Document everything you have to do, which the next hire probably will have to. (Example: Don't have some credential or authorization to access the repo? Ask around for how to get it, someone tells you that you go ask person X? Document who someone should ask if they don't have that thing.)

If you're not sure whether you'll be stepping on toes, make the notes in a file in your home dir, as you're going through it, and later ask someone about whether it'd be helpful to new hires to put it in the wiki/repo/etc.

My point is that I rarely don't regret (for my careers sake) jumping in and delivering (obvious to me heh heh) value right away because I see the code I see where it ought to be and the new boss is really eager to see somethin, but I'm steamrolling toes and throwing elbows in eyes that I was entirely unaware of. I guarantee the people you will work with do not see you as a senior for some time, any misstep is a case against your status, its better to move slowly and thoughtfully with regard to politics than try to lightning strike some progress in the hopes it gets noticed 3 levels above you (they don't give one shit you already shot your wad can you do it again? and again? and again?)

In virtually all cases the suggestion was extremely naive and coming from a lack of understanding of all the requirements. This did not come from a curious angle “wondering if we could do X?”, it was always based on some ground truth they knew better.

Very calmly, you start explaining to them all the key requirements that they just missed in their grand vision. Upon hearing those, some will decide to double down and come up, on the spot, with increasingly complex and arcane evolutions of their initial proposal (this is always very comical, and painful to witness), while others will quickly get the message and basically say “oh sorry, seems like I lack a lot of context, please ignore”.

And let’s not even talk about their first code reviews.

I truly don’t know what goes in someone’s head when they decide, shortly after joining, to dismiss years of work of a competent team who has objectively solved problems for the business.