I've been inspired by a recent article that I saw on LinkedIn written by a Senior Engineering Manager over at GitHub ( view Wissam's profile here ). In his post, Wissam focussed on his best advice for those who are new to a company.
I don't want to repeat what was in this post (which can be found here ), so I just wanted to add some of my own thoughts into the mix.
Contributing doesn't just mean writing code
For new starters that join my team, or even those that I mentor external to my team and even Moonpig, one of the key things I stress is that contributing towards a team doesn't just mean writing code.
As engineers we have an innate desire to get tapping on a keyboard and seeing things happening on a screen or data flowing through that shiny new API you just created. However, web/software engineering is a whole lot more than that.
As a new starter within a team you might feel like you're being a drain on the time of your peers by asking the who, what, why and when of pretty much every new thing you come across.
However, contrary to what you might think asking questions is still contributing to the team. Questions promote:
- Challenging of ideas
- Bringing in ideas of new people
Everybody (and I mean everybody) has their own unique perception of things. Questioning helps bring a greater consensus across the entire team as well as allowing new ideas to flow, especially from those who haven't been engrossed in the same product for the last 'x' number of years.
In short, don't be afraid or ashamed to ask questions. You might not realise it yet, but you're still contributing.
Get involved in discussions
In much the same thread as asking questions, participating in team discussions is another way to contribute towards the team without actually doing any coding.
A high performance team will communicate openly and allow input from everybody, regardless of time served or job title. By throwing your thoughts into mix, you're contributing to the thought process and allowing people to see things from different angles.
Lean on your strengths
You've been hired into the company of your dreams because they decided during the hiring process that you will be great in their team. However, do you feel like you don't know anything? You might be suffering from simple anxiety of changing jobs, or the deeper-rooted Imposter Syndrome.
See my blog post on methods for overcoming Imposter Syndrome here
Although you might not fully understand the business domain, all the tooling and processes that your team use, you still have experience of your own to lean on.
When the situation arises, seek to share your own wisdoms or experiences that might help your new team. This could be a simple process change (i.e. the template for a ticket in your backlog) or even a technology choice for doing a particular task (e.g. suggesting using Python over C# to do some CSV parsing/manipulation).
Go easy on yourself
When companies hire, they do so in the expectation that individuals will take some time to get up to speed with everything that's happening in the team and wider business. It would be extremely naïve of them to assume you could land into the role without any kind of learning.
In some cases changing jobs can feel like starting your career all over again. The differences between companies (or even internal teams) can be surprising. One company's commit strategy or pipeline configuration can be so polar-opposite to the next. This takes time to learn, so cut yourself some slack on don't feel pressured to understand it all from day one.
Make the most of interactions with your manager
One of the staple ingredients for a happy and successful career is good line management. This is even more so during your initial period of a new role, where you will need the support and guidance to be onboarded successfully.
If your manager hasn't already mentioned 1-1s with you, get some recurring sessions booked in the calendar with your line manager. Typically these will be once a week or once every two weeks depending on how fast you want the cadence to be.
These sessions are simple, relatively short blocks in the calendar where you get some dedicated time with your manager. These present a great opportunity to discuss (but not limited to):
- Personal growth
- Career progression
- Issues you might be facing in the team/business and need support
- Development objectives
If your company doesn't use 1-1s (everybody should be having them), you're in a great position to push for them. Without them you can often feel isolated, unsupported and left with no real channel to vent any issues or sing praise.
Pair and/or mob with your team
It's pretty natural to want to feel like you're contributing at 100% from day one in your role, but realistically this won't happen for several weeks to even a couple of months. However, as mentioned earlier in this post contributions don't have to come in the shape of smashing out code.
However, there is a great opportunity to learn more about the business domain and product(s) you're working on through pair programming or mobbing session.
Pairing is a great way to work with another engineer on your team on a particular problem or ticket. This way you will build up a rapport with your colleague and even have an opportunity to get more intimate with the codebases, ask questions and maybe even have a go at driving the development yourself with the guidance of your colleague.
Mobbing is similar to pairing in that more than 2 individuals are involved, often an entire team focussing around a larger problem where knowledge is best shared. Again, these sessions promote good teamwork and discussion amongst your peers.
If I was to summarise my message from this post it would be "go easy on yourself, don't put too much pressure on from day one and don't be afraid to ask questions".