As a Software Engineer, I'm looking for ways to grow with the hope to get promoted to Senior. After years of battling with my imposter syndrome and overcoming negative experiences in a previous role, I was a Junior for longer than what I feel I should have been (isn't hindsight a wonderful thing?) but I felt somewhat safe within that comfort zone. Now I'm ready to break out of it.
In December 2019, I was promoted from Junior to Software Engineer after 2 years at the BBC, and I have a few years of experience prior. It's taken some time but now I feel confident with my new title and I'm ready to take the next step to become a Senior and even Engineering Team Lead. Why the hell not?!
I'm tired of either talking myself out of something or down. So what evidence can I collate to show that I'm ready? One is taking lead on a piece of work or project, but what does or could that look like for you and what does it entail?
The piece of work that I'm leading on at the moment is to upgrade from a service that is being decommissioned in the next few months to another without any hiccups. Just for further context, this product is currently in maintenance mode. We aren't actively working on it and the majority of our team's engineers haven't worked on this or its platform before.
So what did I do?
Understanding
Firstly, I spoke to my line manager who gave me the work/brief and I had to do some research and get back to them within a week or so with what our options are.
"Right… I've got this… Crap… What do I do?" I thought.
So one of the first things I did was let what my line manager said sink in, I had asked them questions so I had an idea of what to do next. This was to search for what documentation we had on the current service that we use.
Read, read and re-read some more.
I want to acknowledge (and I think it's important to say) that when you've read some documentation and it doesn't fully make sense it's ok to ask someone for clarification. The number of times I've sat there and thought "I have no clue what I need to do" or "that doesn't quite make sense". Sometimes it's not your fault that you didn't understand something, maybe it wasn't communicated clearly.
The documentation that I found was OK, but it lacked a lot of depth and detail. I asked some questions to a colleague whose team had worked on this, wasn't too sure on the subject. They referred me to someone else, who was currently working on this for other products (including my team) and writing up documentation, they were happy to take questions and to hopefully provide answers. I had a couple of meetings where we went through the project architecture and how the work required us to do both X and Y otherwise, Z wouldn't work.
Once I fully understood what work was involved for either two solutions, which were to turn the entire service off or to upgrade. Turning off required more risk, such as we'd have to upgrade and deploy more modules - and even then we couldn't 100% guarantee that we'd get it right. Upgrading always seemed the right option, this way we have the same expected behaviour on the page, fewer modules to update and less engineering work required. Sounds like a winner right?
Communicating
Secondly, I wrote all this down on a Dropbox Paper. For me, it's good to write it out, when typing I talk it out loud, it's great for others to give it a quick proofread and to give constructive feedback or ask questions that you hadn't thought of. I always think about the reader when I write my work up and to not to use jargon.
Can everyone on my team understand what work is required and why? If the answer is yes then you're on the right track. Also, am I excluding anyone from some of the terminologies that I have used? It's important to remember that not everyone is going to understand this right away, it certainly took me a while to understand it. It's not a straightforward piece of work, so it's important not to underestimate it or yourself.
Planning
How can you prepare and break down the work required? I find that writing out my thoughts and understanding on a Dropbox Paper. I prefer to have a certain structure - introduction, the problem, the solution. I also drew out diagrams of the work required, this allowed me to visually map out which modules will get updated first and work our way to the final modules etc.
It allowed me to understand the amount of work that was required and how I could effectively communicate this to my team and others (some modules are shared across different products). For example, I spoke with my Project Manager, who was new to this work and it was important to get them to understand the work involved. As I understood what was required, mapped it out and was confident in how to communicate this to others, I was able to relay this and to give an estimated timescale of how long the work would take.
Communicating some more
Finally, I had to communicate the work via writing up JIRA tickets of the work that's required.
As this was a slightly different tech stack to what we're currently working, it involved me putting together a slide deck, it was important for me to take the engineers through the work that's required and what tools they'd need to install to get started etc.
On each ticket I made a task list of the work required, it's easy for the work and deployment process to get complicated when multiple people are working on it all at once.
I feel that as a team we can deliver the work required in a good timescale that won't affect any of our current work. I believe that through effective communication and creating a safe working environment they understand how to work on this in a pair and to feel comfortable to ask a question if they are unsure at any point. I don't have any unrealistic expectations of my team, I'm not expecting them to fully get it straight away and that it's ok. I remember being new to it when I first started in 2017, so I can put myself in their shoes.
Conclusion
I've learned a lot from this experience. It's instilled a belief and confidence that I need to listen to and trust more. I have learnt that I have great communication skills and I make sure that I don't exclude anyone because we're all in this together as a team.
I had initial doubts about my ability to deliver this work, but I have enjoyed doing it. I look forward to more opportunities to deliver work as a team.
Remember that it is important that you:
- fully understand the work that you are required to deliver
- communicating either/both written and verbal effectively - it is a great habit to share and log this knowledge
- planning through the work that's required, it's important to be consistent and for everyone to be on the same page communicate some more - your team should feel comfortable and confident to either start the work or to ask you any questions if they are unsure
Thank you for reading, I hope that this helps you in the future.
Top comments (0)