We think giving new starters a great mentor is the best way of helping them hit the ground running.
We think giving new starters a great mentor is the best way of helping them hit the ground running.
This is a guide for how we think about mentoring at Gearset. We wrote it to give mentors a rough outline of what they should be doing and what they should be thinking about when they're helping a new teammate settle in. It applies across all divisions and job roles, and we make sure every mentor reads it before their new starter arrives.
In the name of transparency, and inspired by Monzo's fantastic Tone of voice guide we've opened it up to the world — we believe in everything we've written, and we want to be held accountable to our own standards. Hopefully it also gives you some insight into what it's like to start a job at Gearset.
Starting a new job can be pretty intimidating! There are always all sorts of unwritten rules, conventions and group habits in any workplace — we often call this “culture”. Although we try our best to broadcast our values throughout our hiring process, any new starter is probably only going to have scratched the surface. On top of that, there's a whole new product, customer base and way of working to get to grips with! It might even be their first experience in the job role that they're starting, in which case there's even more to think about.
Your role as a mentor is to help your new starter settle in as smoothly as possible, and to be someone other than their line manager who they can go to with any questions they have as they settle in. You're there to make sure they aren't left to fend for themselves. It's not your job to have all the answers(!) — but it is your job to make sure they get an answer from someone else if you're not sure.
It's worth pointing out that you shouldn't be their only point of contact - if they ask something you think someone else would be better at answering, encourage them to speak to the right person so that they get to know everyone. They shouldn't be lost as soon as you're out of the office or unavailable for half an hour. We're one big team, and we need to be comfortable with talking to anyone across the company.
You're also there to help introduce them to the Gearset culture in its many forms — how we work, how we give (and take) feedback, what we value and how to get better. Their line manager, and every single person at Gearset, shares responsibility for all this, but you'll be a big part of their experience of Gearset for the first few weeks/months so it's important that you're thinking about this stuff. Lots more later.
This document is intended as a rough guide to:
It should be a living document — if something is missing that you think should be here, or that you wish you knew when you started mentoring, make sure it gets added!
A little bit of prep can go a long way! Make sure you know roughly what you want the new starter to achieve in their first week, before they arrive. Mostly, this is set out in our internal wiki (see below). Obviously, the specifics will depend on lots of things, including what previous experience the new starter has, what role they're coming into and how quickly they get up to speed, so there's no need to plan every day out in advance — broad strokes.
The internal wiki contains an onboarding section which constitutes the new starter manual for the first week or so, and one of the first things you send across to your new starter is a link to it. There's also a Welcome to Gearset document. We have a rough template that we use and that evolves over time, but it'll be your job to tweak the details (make sure the right name is in all the right places!) and review it to make sure it makes sense. You should also add a bit about yourself at the start, and if you want to add any other personal touches, you absolutely should — the more personal it is the better! Get it printed before they start, if they're not remote.
The welcome document should tell the new starter who their line manager is. They'll start out spending most of their time working directly with you, but they'll have 1-1s with their line manager.
It goes without saying, but your new starter will need a desk, a computer, and all the software they'll need to get up and running for their role. If you're both in the office, ideally they'll be sitting next to you, or at least very nearby, to make working together easier and so that they feel more comfortable incessantly asking you questions (which you should absolutely encourage!). If you're working together remotely, make sure you've both got decent headsets and webcams: it makes a big difference.
The computer setup will probably have been handled but you should check with plenty of time whether anything needs doing. The details will depend on the job role, but at a minimum they should have a user account on the PC with a username and password, and a company email account set up.
Check what time your new starter is starting for their first day, and make sure you're around to say hello. Most of the time we ask them to start around 10am on their first day.
It's probably a good idea to meet them at the door, along with their line manager. Show them their desk, and the rest of the office, and introduce them to whoever is around. Make sure they have an access card for the building and grab a cup of tea with them. If they're remote, set up a call with them and send them a link in advance.
Most of what they should be doing will be in the onboarding docs, but broadly:
#general, and invite them into some channels they might find it useful to be in.
Again, the mechanics of this should be outlined in the welcome docs. Broadly, you'll need to find something small that you can work on together.
Ideally, this chunk of work will be:
At some point they'll have their photo taken for the website. If possible, you should get them to put themselves up on the About page — as another opportunity to see how our feedback and review process works, a bit more exposure to the technical details of how we work, and to help them feel included as a proper member of the team.
At some point, you should try to introduce them to how we talk to customers — how we do it, how we try to come across, and how we handle different types of request. It's important to make clear that everyone can pick up support requests, and that it's okay to say you don't know the answer (as long as you then try to find out!). Talking to customers is one of the best ways of getting to grips with the product, the Salesforce ecosystem, and our customer base.
As time goes on you'll be able to pick up bigger chunks of work and introduce them to more and more of what their role entails. It's hard to prescribe this — it depends on lots of things, including what work actually needs doing! For engineers, Intercom, Uservoice and
#engineering-weekly are often good source of ideas for what to work on. Your line manager and your team should be able to help, too. In any case, you'll need to play it by ear to some extent.
At the end of each day for the first week, make sure they go home/stop working at 5PM. Don't throw them out of the office at all costs, but try to be fairly insistent about it for the first week. People are often a bit reluctant but make it clear it's not a test — we really do want them to go home! (and no, that doesn't mean they need to get in at 8am sharp to do more hours).
We want to make it clear that we mean it when we say it's about the contributions you make, and that nobody is breathing down your neck counting your hours. Actions speak louder than words. It's easy to feel a lot of pressure when you first start to try to look like you're working really hard and we want to take as much of that pressure off as possible — stress doesn't help people settle into the team, build relationships and get up to speed!
Make sure to check in at the end of the week and make sure everything's still going OK.
Again, this will vary massively by job role, but broadly, they should know:
As time goes on, your new starter should get more and more independent and should need less and less time pairing with you to get going on a problem. How quickly that happens varies a lot. You should be looking out for them, and trying to make sure they get a nudge in the right direction if you think there's something they could be doing better, or something they don't know that would make their life easier.
There isn't really a defined end to being a mentor — eventually, your new starter won't be a new starter any more, they'll just be another member of the team. They grow up so fast 😢. At that point, your job is pretty much done (nice one!), but it's hard to draw an exact line.
When you get to the point that you trust them to pick up a piece of work, run with it, do what they can by themselves, and ask appropriate people in the company for input where they should, then you probably aren't their mentor anymore. Roughly, and perhaps not very helpfully, you stop being a mentor when they stop needing you to mentor them!
The remaining sections in this guide are an outline of the habits, values and practical knowledge that you should be trying to impart. Most of them will be covered naturally as part of working together, but you should keep an eye out to make sure that's happening. If you think your new starter still needs help with some of these things, then your job as a mentor probably isn't quite finished yet.
You should direct your new starter to the learning resources that are available. These might include written materials, videos, Trailhead trails — and, of course, colleagues. They will probably have a few more structured training sessions early on for specific things like talking to customers and information security.
Make sure they know that ultimately their learning and development is on them, but that there are tons of resources available. They just need to be proactive in asking for them or finding them themselves.
Be prepared to answer both at a high level and in various levels of detail how Gearset works — your new starter will struggle to get up to speed without enough context. Mostly, this should arise naturally during the course of working and responding to customer requests together, but it may make sense occasionally to put aside time together to go through something fundamental (for example, how our deployments work, or how change monitoring helps customers).
A big part of this will be explaining how Salesforce works, since many new starters will be unfamiliar with it. Again, the best way of learning this is doing — making changes in an environment and using Gearset to move them around. Talking to customers is another fantastic way to get to grips with it. Trailhead can be really useful, too!
Silos suck. When knowledge is stuck in the heads of one or two people it has all sorts of knock-on effects. Obviously, it's impossible for everyone to know everything, but the more cross-pollination we can get for ideas and information, and the more comfortable we are talking to others across the company, the better we'll be doing.
The biggest thing you can do as a mentor here is to encourage your new starter to talk to people directly when it makes sense. If they're working on a feature that Catherine worked on last, get them to ask her any questions they have about it. If they're not sure how to deal with a customer request, maybe some Valerio 🤩 magic is required.
On the engineering side, Pull Requests (PRs) are another way to give this a boost. Get them to assign their PRs to lots of different people so that they're interacting with lots of people, and giving and receiving feedback in lots of contexts. Help them to get comfortable doing that.
Speaking of feedback, it's important — it's the best way by far of knowing if you're doing a good job or not. If you don't know that, you can't improve. Stuck forever. Sad!
Feedback is best delivered in the moment. It's at its most actionable, and it avoids making things into a Big Deal. Waiting to give the feedback until someone's next 1-1 means it's easy to forget the context or lose something in translation. Something that might be intended as a tiny course correction can be received as a big intervention and it can become harder to see the feedback as constructive. That's not to say there's no room for feedback in 1-1s — just that sometimes there's a better alternative!
Giving good feedback is a skill, but so is receiving feedback in a constructive way. In engineering this mostly applies to code review, but it comes up in all sorts of contexts and everyone will have feedback on their work from time to time — ideally, all the time!
Receiving feedback is most useful when we can remove ego and ownership from the equation. You should feel like you're both standing on the same side of the table, looking at a problem, and trying to come up with the best possible solution. It's collaborative, not combative. Constructive, not clashing. Collectivist, not— you get the idea.
It should go without saying that not all feedback is constructive. We take time to cheerlead each others' successes, and new starters need that more than anyone else! There are a lot of smart people at Gearset, and it's easy to convince yourself you're out of your depth when you're doing great. Take time to acknowledge your new starter's achievements.
This is more about leading by example than anything else. The way you (and everyone else) give and receive feedback demonstrates our feedback culture, and helps to propagate it.
A simple one to finish — make sure they know how to do all the basic company admin, or who to ask about it. Most of this should be covered in their orientation, but it's easy to forget! Some possible examples: