I've been working at a very bureaucratic F500 for 3 months in an SRE position. I don't really code a lot in this role and I want to switch to a dev position but I'll be honest I'm a complete noob at navigating this because this is my first job
The place I'm working at is super slow -- it took me 1 whole week just to get access to the code in my own team and it took 2-3 weeks to get access to all the other tools.
I've heard advice of "just go and ask an engineer on the team and code" but the issue is to even get access to the codebase + tools in my own team its such a long drawn out complicated process, let alone a completely different team. I'm also a bit worried about doing things behind my managers back as I'm worried it'll look really bad.
The other thing is idk how to just "contribute" because to understand the tickets + context and actually code you need the tribal knowledge from your team
Would love advice, I'm pretty lost and I'm not sure how to navigate this -- especially the big don'ts because I don't wanna shoot myself in the foot and do something that's gonna hurt my reputation if done badly
I'm also a bit worried about doing things behind my managers back as I'm worried it'll look really bad.
The key will be framing how your code contributions can help your team and any other teams. Since you are an SRE, one of your goals is to improve the stability of your products. If you get get your manager and the manager of the other team to agree that your suggested code changes will help with the stability of your product, you can create a win-win-win situation.
As a first step, you can add more logging into the code to improve observability, especially if there have been recent incidents related to that code. You can set up a meeting with someone who works more directly with the code to get a walkthrough of where the relevant code is, what are some pressing issues with the code, and how the code gets deployed.
You'll be able to build relationships with the team that is more development heavy. This'll make it easier to potentially switch to that team in the future.
The place I'm working at is super slow -- it took me 1 whole week just to get access to the code in my own team and it took 2-3 weeks to get access to all the other tools.
This is something that is hard to fix especially if it's ingrained in the company culture. That team really needs to have an SLA process in place to make it easier to grant tool access to employees. That is a really high turnaround time because a lot of progress could have been made in those few weeks.
Assuming you aren't looking to switch companies (the market's terrible for junior engineers right now), the "playbook" for team switching is straightforward to understand:
As you can see, the dominant thread is your relationship with your manager. I understand that things are slow (this is common with the F500, especially with non-tech companies), but it's critical to learn how to make the most of a bad situation as an engineer. Junior engineers rarely start off on a good team (I sure didn't), but you generally need to spend 1+ years in that role because the short stint will otherwise look very bad on your resume.
That being said, I recommend building up that relationship with your manager and asking them for more work. Make sure to frame it from mutual interests:
It's on our backlog to make a course about effective 1 on 1s, but in the meantime, we have this: [Masterclass] How To Have Impactful 1 on 1 Meetings