The Best Ways to Crush It as a New Team Member
July 05, 2019
I’ve been a part of several different engineering teams in my career. I’ve been part of brand new ones and joined well established ones as well.
While I have many ways to grow, I’ve thought through some ways that have helped me when I’ve joined an existing team and I wanted to share them with you.
This isn’t an exhaustive list be any means and I’m sure others have even better ideas for how to join a team. These are just the ones I’ve used and have found useful. I hope they can benefit you too!
Ask Questions
The fastest way for you to become a contributor to a team is to understand the team you are on. How do they work? What are they building? What is expected of you? You need to figure all of that out, and the best way is to be upfront and ask.
Asking “Why do we do things like that?” or “How did this get this way?” will be sure to expose the shortcomings of your existing team, or expose how they have figured out a new paradigm you hadn’t considered.
Don’t be afraid to ask what seem like “silly” or “dumb” questions. Questions like these often reveal patterns or ideas that have been propogated for years without anyone knowing why. You might even be the first to ask.
And while asking questions is great, do your best to ask a question as few times as possible. Asking the same question each day to the same person is sure to annoying. To avoid this, keep a running list of the questions you’ve asked and their answers. Google docs, Slack, or even an old-school pen and paper. Before asking a question, check your list and see if you already have the answer.
The best thing about this approach is I have already set up others for success in the future. When another new team member joins, I will have already compiled an FAQ of sorts to give to them so they shouldn’t need to ask the same questions. And of course, I can document it all in a wiki, README, etc. Which leads to the next point 👇
Read the Docs. And Then Fix Them.
Documentation in software always seems broken. But that doesn’t mean it isn’t invaluable. I believe documentation is a tool that continues to refine and build a team’s understanding of what they do and why they do it. So read the docs. And I mean read them! — avoid skimming if you can.
As you do, ask questions (see above), compare what you read to what you are told, and then fix the docs when they are wrong or missing information. If you are on a software team, open a PR. You’ll likely get feedback and thus answers to more of your questions (see above).
Then read it all again. And again. Until it starts to make sense.
We had someone join our team at Bandwidth a few months ago and the first thing he did was read. He read every doc we had ever written about the solution we were building. He read code for hours. We even got nervous because he was sitting and silently reading every day for a little over a week. 😬
But then one day it knew it all. Like, really deeply understood the solution we were building.
He spoke up one day about a feature and how it fit within our system. He described it better than our architect at the time did. He had spent so much time reading, that when it came time for him to write something and make a new contribution, he knew exactly what it meant.
“Not all readers are leaders, but all leaders are readers.”
— Harry S. Truman
Serve.
Serve your new teammates. And I don’t mean bring them coffee and donuts (though a lot of people like those things, so maybe it isn’t a bad idea..).
Find the tasks that no one wants to do or no one has had the time for. Are there silly little tickets that you can clean up? Are there any big tickets that no one wants to take? Raise your hand to offer your help.
And as you work on these tasks, continue asking questions, reading and correcting everything you can. Look for ways to improve the process or automate steps entirely.
After a few months, you will have done some the hardest work you will do on that team. Everything else is downhill.
Admit When You Screwed Up.
At some point, you go from being the “new guy/girl” to having real responsibility. And you will, sooner or later, screw it up. You botched a customer call, setup something in a system wrong, wrote a bug that made it to production, etc.
When it happens, don’t make an excuse, blame a system, or claim you didn’t know something. If you’ve been doing the things above, you shouldn’t really have those excuses anyhow.
Own your mistake and learn from it.
By doing so, you practice humility. You learn to own your mistakes quickly. You show your team you are willing to fix whatever mayhem resulted. Most importantly, it shows that you are actually doing something! No one sitting on the sideline of the Superbowl makes the big mistake that cost the game if you lose; they also never contributed to the victory if you win.
Grab a Meal With Them.
Seriously, grab lunch together. Eating together helps you build relationships beyond work. You get to know your teammates outside of the things they “do”. Its time for brainstorming ideas in an informal way that you can’t do at a whiteboard in a stuffy conference room. It doesn’t have to be daily or even weekly either. Just be willing to ask a few co-workers every once and a while.
As a side, happy hours are great too, but be careful! No one wants to be known as the office gossip and it can be easy to fall into a trap after a few drinks. Even if you aren’t saying anything, what you hear can be equally as dangerous.
I hope this was a helpful quick snapshot of how to crush the game as a new team member. Many of them are good strategies to becoming a better team member of time as well. The core of all these things comes to down to that balance between staying humble and staying hungry.
I’d love to hear what you think is important too. What are some other ways in which you or others have had great impact when joining a new team team? Reach out to me via LinkedIn or shoot me an email
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.