Getting up to speed on a new team

If you had seen my tales of fail blog or my career growth over time, you may notice I’ve started a new tech role on average once a year since I started in tech over 10 years ago. There’s been a series of 6 month contracts, redundancies and company misfits. The most I’ve stayed with a tech team has been 2 years.

So I’ve had a bit of practice getting up to speed on new projects and this blog is a reflection on tactics that now become common practice for getting up to speed as a tester on a new team.

Best onboarding experience

My best experience has been when a computer is already set up and within the first week I’m able to check out code and be productive. I’ve only had this happen in a handful of cases.

Often with larger corporations it can be weeks to months to be full onboarded. I’ve had cases where I couldn’t log into my work issues computer for 2 weeks. Good thing this company also had a BYOD device policy and I was able to use a personal machine to also get up to speed.

Meet the team

If you are starting a new role, don’t be afraid to book one on ones with all of the team members you’ll be working with directly. This should be a fairly social exercise but you can have some structure to the conversation, for example:

  • What’s your role on the team?
  • How long have you been on the team?
  • What does quality mean to you?
    • OR what does a high quality product look like to you?
  • What are your challenges with testing/quality?

Surveying a bunch of people on the state of quality will give you a good idea of common problems. If there is a common thread this could be a first project to work towards to help you demonstrate value within the team.

Test Environments and Data

A common pain point that has come up on every single team that I’ve wokred with has been around test environments and data. Unfortunatly there is no environment that is ever maintained like production, but it’s not always possible to test in. production.

Getting an overview/walk through of the current set up is essential for getting up to speed.

Can you run existing tests?

Most teams will have some existing test coverage, most people don’t get to join completely green field projects. There is always some sort of legacy coade floating around on most teams I’ve worked with. Figuring out how to check out the code and getting tests working locally is a great step towards being able to add value later on.

Sometimes setting up a local dev environment from scratch can take time. The best team I’ve worked with had a OS image with all of the dev tools installed that made onboarding a breeze. However I’ve also been stuck for days trying to debug which java version I’ve been trying to execute against and figuring out more than I wanted to know about java beans or network stacks.

Managing up

Unfortunatly I’ve been burnt a few teams by focusing too much on collaborating with engineers and testers. Sometimes this work doesn’t translate to visibility higher up in the business and looks like I haven’t been adding value or I’ve been focusing on the wrong things.

Having open communication with management, actively seeking feedback and deliverying small projects that add value is a great way to keep the visibility on your work. However it’s a pretty common story with other testers that I know that it can be a real challenge to transition from collaborating with engineers to management.

Document as you go

Every team has out of date documentation or non at all when you join. Just the act of documenting everything as you go will make it so much easier when you leave or onbaord new team members.

I often start with a confluence page of useful onboarding links that I’ve found in my first few weeks of getting up to speed.

Then sketching architecture diagrams if a senior/tech lead gives you an overview. Write everything down. You can always edit your notes and clean them up afterwards.

I find this useful for testing new features too. Creating a confluence page of testing notes, where I collect the APIs, data, screenshots and scripts (like useful database scripts) is really useful for when someone approaches you 6 months later and asks you to retest something.

Offer to run a meeting

If your team has regular meetings, like a retrospective, offer to run one. This will help you get to know the team and you will be seen as having a more active role. It also helps take the load off someone else.

Don’t be afraid of booking more meetings

I failed in a previous role because I wasn’t proactive enough in getting other people’s feedback for quality initiatives we could all work towards. I was too afraid to “waste” other people’s time when it seemed like they were always busy and complaining about having too many meetings. My imposter syndrome really help me back.

Ask the stupid questions

If someone uses an acronym you aren’t familiar with, ask what is it. Don’t just smile and nod or else you will be forever confused. Clarify everything. Also parrot back what some explained to you in your own words. This will help you establish your understanding and help clear up any misunderstandings along the way.

We all have a fundamentally different understanding of language. Don’t be afraid to ask what sound or feel like dumb questions. There’s probably someone else thinking exactly the same question but is too afraid to ask.

Be the change you want to see

On a final note, if you see common pain points or frustrations feel free to champion some change. Nothing will change if people just complain all the time. However if you take just a small step towards change it’s more than anyone else has done up to the point.

What else has helped you get up to speed with new teams?

Leave a Reply

%d bloggers like this: