Last updated on 2021/10/01
Do you remember Jurassic Park? The classic movie that re-launched dinosaurs into our social consciousness.
If so, do you recall that scene from the original Jurassic Park where the programmer, Dennis Nedry, is at a table with Dodgson planning some fun cryogenic corporate espionage and Dodgson wants Dennis to keep his voice down? This scene has spawned countless memes all across the internet with the infamous catchphrase at the end:
“See? Nobody Cares”.
On the surface Dennis is trying to prove a point to Dodgson that while sitting at an outdoor restaurant full of locals and tourists nobody else is interested in their conversation even though they are discussing some nefarious actions. Did you know that Dennis actually does this because he is recording the conversation to cover his rear end in case the corporate espionage goes south? Anyways, This meme popped into my head while thinking about onboarding new people onto an existing Engineering team. After the whole ordeal of interviews and offer letters and paperwork we get to the end result and all of a sudden there is a new person hanging out around the office. There is now a fresh newbie on the team. Or, if using correct geek parlance, a noob. And guess what? Nobody cares.
This is not 100% accurate for all aspects of the new-team-member experience. Hopefully you are part of a team where any new member is socially welcomed to the group and the culture is welcoming. The learning curve on a friendly culture is typically much easier to ascend. But from a functional perspective everyone knows that no matter the skill level, skill set, or amount of driving ambition, that newbie won’t be productive for quite some time. This isn’t a knock against that person. Most organizations and teams have a pretty steep learning curve into the technology, codebases, tools, and processes that exist. It takes time to understand and adsorb these methods to the point where anyone new is a serviceable member of the team. The first thing that any new person in a role should do is to step back and try and understand the expectations for the role. This can be very hard to do because these expectations are usually not clearly defined or written down anywhere.
Therefore, as an Engineering Manager, the following seven things are all part of what I want any newbie on my team to know, embrace, and understand at a deep level. Anyone who has made it through the hiring process and who can embrace these ideas should end up being a great teammate. Or – if unable to get through the learning curve that these ideas imply – at least we will find out sooner rather than later that we might have whiffed on this person as a valuable member of this team. So here are the seven things that I want any new Engineer on my team to know.
THINGS TO KNOW #1
YOU DON’T NEED TO MEMORIZE A LOT OF RANDOM
STUFF TO BE AN EFFECTIVE DEVELOPER OR ENGINEER
One question I have heard asked many, many times after extending an offer to someone: “What can I go read or study up on to be ready to go when I start working there?” Uh, stuff? While the team usually comes up with a list of technical topics as a response to this question I usually don’t have anything as a manager ready to hand off in response. The main reason is that we are changing technology all the time. I can throw out a list of buzzwords that we are using today but it will change for tomorrow. There are some general items. We code in C#. Fine, go learn all of that in the next two weeks. Good luck?
My fear is that this question stems from the myriad articles targeted at newbies in general. “Memorize These 12 Sorting Algorithms If You Want To Be Successful At Development!” screams one headline, or “If you Don’t Know How To Do This in Java You Won’t Be A Successful Programmer“. Seriously, no. I feel like these types of articles are promoting some sort of mystic Engineering dogma that if we forget one of the Cursor Commandments then we are all going to burn in the fires of hell where everyone has to use a PS2 mouse with no scroll wheel and code in a VIM editor all day. Now please create 2 bubble sorts and a merge sort on a doubly linked list to wash away your sins.
The point is – your ability to memorize sorting algorithms might have helped you pass a test in school, but things are different now. As an Engineering Manager I need someone that has an ability to go read about, understand, and implement a binary insertion sort, but I could care less if you have it memorized. I actually value much higher your ability to research and provide a thoughtful explanation for why you chose that specific algorithm as a sorting solution to a problem than I do your ability to go program something you have memorized without the need to hit up Stack Exchange for some help.
Sure – if you find yourself implementing similar functions over and over you might start to memorize some of it – but I would be willing to bet a rather large amount that a year from now you will have worked on a dozen other projects and tasks and forgotten all about the bubble sort that you just wrote. After two years I would even hazard that you would have as much re-learning curve with you own work as you would for someone else’s code. And as your manager I am totally fine with that. What I need is smart, creative people who have the ability to find solid solutions to problems and who can be efficient in getting to those solutions.
THINGS TO KNOW #2
TAKE TIME TO UNDERSTAND THE CULTURE
AND WORK TO FIND YOUR VOICE WITHIN THAT CULTURE
As you step foot into the territory occupied by a talented and efficient team know that in this moment you are an outsider. There are processes and ways of doing things that you will need to learn. There are inside jokes spawned from countless hours of problem solving and a few late nights where we all went past the point of no return and got a little slap-happy in the process. We all play our own roles within the team. There might be a joker, the quiet one, the one whose voice echos down the hallway whenever they speak.
You are joining a team and a family. We spend nearly as many waking hours with each other as we do with our people and pets outside the office most days. I expect every member of the team to contribute their voice to the team. That includes you. Speaking up in meetings. Giving ideas when we are brainstorming. I expect you to build your own relationships with others on the team. We are all people with different viewpoints and experiences so you don’t have to be friendly enough to go out to lunch with every person every day, but we will be working together on projects. You need to form a professional relationship with everyone that enhances what we do as a team.
So what do you need to do to join this team? A little self-reflection doesn’t hurt. Know who you are and try and recognize the value you bring. You wouldn’t have been hired if you didn’t have at least the potential to fit in with the culture here. Don’t try and fake us out. Just be yourself. While you might be here to fill a technical need, you definitely weren’t brought on to fill a specific cultural role. Just have a little patience and this role in our culture will become clear over time.
THINGS TO KNOW #3
ASK ME FOR FORGIVENESS
NOT FOR PERMISSION
We are not a big team. I don’t have time to micromanage. If you see a need, fill a need. If you try and fall, get up and try again. Don’t be afraid to fail. On this team we all carry our own weight and then some. We help each other out because everyone knows that a rising tide raises all ships. How many other pithy sayings do I need to add in here?
Aphorisms aside, we are a small team at a small company. We all have to wear many hats in order to get the job done. I get mentally exhausted having to come up with solutions for every issue and roadblock that arises every day. Also, please don’t point out that something isn’t in your job description. It isn’t in mine either, but that doesn’t stop me from working on fixing the problem. Other people need to step up and come up with solutions sometimes as well and it is even better when initiative is shown and solutions are achieved before I have to get involved. So if you see something that you can take care of without needing direction, go for it! It doesn’t matter if it is a little bit out of our scope, taking care of a problem helps out the overall organization, so the sooner we get something knocked out the sooner we can all move on.
However, communication is key. Please understand the expectations that I set for myself so that you can better understand the expectations that I set for the team. I refuse to play hot potato and toss issues down the line to the next person. Therefore, it may not be our fault, but it is our responsibility to find a resolution. I also don’t ever want my boss to be surprised by an issue, event, or other piece of news so I see it as my responsibility to disseminate that information to them before someone else brings it up. Therefore, you will hear me loudly advocate for communication as being a major goal for this team. Communicate, over-communicate, then go back and communicate some more. During and after the solution implementation please make sure to keep both me and the overall team informed.
THINGS TO KNOW #4
YOU NEED TO FIND WAYS TO STAND ON YOUR OWN TWO FEET
BECAUSE I WILL NEVER HAVE ENOUGH TIME TO MENTOR YOU
IN THE WAY THAT I WANT TO AND IN THE WAY THAT YOU NEED
This one hurts to write. I will drop the ball as your mentor and manager occasionally, probably more than I want to admit. I wish there were more hours in the day so that I could get around and check on you more often. Heck, I would even settle for a few free days to work on a more comprehensive onboarding plan and more documentation around our processes and my expectations for the team that could be helping you right now. But every time I check something off my list two more things get added on. You aren’t the only one with a learning curve here. We both have new responsibilities and things to learn and obstacles to overcome with you coming on board.
You will need to find ways to grow and people to learn from that aren’t me. There are lots of ways to do this. Your teammates are a great source of information and will be one of the best ways to get up to speed quickly on a lot of things. However, please don’t expect them to drop everything all the time as they have their own work to do. You need to take ownership over things and balance out time spent researching, learning, and trying to find solutions against struggling and spinning your wheels while not moving forward. Do your own reading, research, and try and solve the problem for a time before going to ask for help. Don’t be afraid to read a lot initially or to branch something and work on your own copy. Pull the whole codebase down and see if you can just get it to compile. That can be a challenge in itself, and if you succeed, go ahead and see if you can make a small but meaningful change somewhere. Don’t forget that you are as responsible for your learning and growth as much as I am for creating an environment that provides room and patience for you to learn and grow.
Please also know that I am asking you to hold me accountable. We are a team, you and I. While I have expectations for you, this is a two way street. It is my responsibility to help you fit in and succeed here but reminders are occasionally needed. That is good and we should immediately work on building up our relationship so that trust can be established and so that we can each give each other honest feedback. This is the bedrock that we will build upon to help you grow and flourish professionally in this role and I am excited to be a part of it!
THINGS TO KNOW #5
I DON’T EXPECT YOU TO IMMEDIATELY CONTRIBUTE TO A PROJECT IN A MEANINGFUL WAY
This is another topic that I hear a lot in the first few weeks. A lot of people seem to think that I expect them to be slinging code with the best of the team on a project in the first sprint out of the gate. Please don’t come apologize to me because you feel like you are doing something wrong since you aren’t contributing to a project. It is expected that you will not only be a neutral resource for a while, but that you might even fall into the negative resource category. When getting you up to speed means that you aren’t contributing and when someone else has to take time away from their assigned tasks to help you understand what is going on we will get fewer things done this sprint than we might have if you weren’t here.
That doesn’t mean that you shouldn’t be here! How else do you think that we will get someone familiar enough with the technology and solution to contribute to it in a meaningful way? While it is a pain point now, it has the potential for a huge payoff later. Do you think that taking someone away from assigned tasks is effort that wasn’t thought through and considered when the decision to add another teammate was made? Your job right now in the beginning is not to add to the solution. It is to scramble up that learning curve as fast as you possibly can so that you are at a point where you are contributing. I don’t see anything in that statement about advancing the solution, so why apologize for a lack of results that you aren’t being asked to provide?
This doesn’t mean that you will be in cruise control during this chunk of time before settling in as a regular developer. I need you to take this time to learn the product alongside the technology learning curve that you are climbing. This may involve some QA work or sitting in on a training class. It may involve discussion with customers or the product owners. While this may seem like busy work and possibly boring and repetitive QA grunt work, there is a purpose here. Don’t focus all of your efforts on the technology – we also have business logic that needs to be learned. Using and testing the product will build your base of knowledge very quickly. It should also spawn dozens of questions about who, why, and how. Who are the customers for this product and hat are their use cases? Why does this workflow work this way and how does it tie into the customer use case? How are we delivering these specific features to the customer?
I am not concerned that you are not writing code that is meant to be part of the released product right now, so why should you be? I am not telling you to not write code. I am setting broad expectations for you in regards to learning the product and the technology and observing what you are doing to meet those expectations. I will try and step in and help out along the way but if you want to impress me very quickly after starting on this team you will focus on personal mastery of all aspects of the product instead of trying to show how many lines of code you can churn out.
THINGS TO KNOW #6
READ THE F**KING MANUAL
Nothing frustrates me more than having to answer a question that someone could take a minute or two of their own time to go look up and answer themselves. This happens among the current members of the team more than I would like to admit. Yes, it is my fault for being the easy button in some situations, but I want you to know that this aggravates me each and every time it occurs.
So right now in this time where you are focused on learning please make sure to take some time to RTFM. You should not only read the manual for the product that you are learning but you should also read and absorb the documentation for the team and the organization at this point in time as well. This is not reading to memorize. What the goal is for this effort is to know where to get answers. How do you get to the current Employee Handbook? Where is all of your benefits information if/when you need it? How is our team’s automated build server setup? Where is the process flow documentation for our release process? How do you access any knowledgebases or repositories that have been setup?
The goal here is not to try and have every answer. It is to build your knowledge regarding where to find all of the answers. That way you know where to go read up on how much vacation time you get each year. You know where all releases are posted. You have the ability to find all of the product user manuals. This is fantastic, now you know how to find the information that you need. Now I don’t have to go pull out the Employee Handbook and copy and paste the section on dress code into a Slack message for you. That is a win in my book.
However, should you have any follow-up questions that the material doesn’t cover then please come see me. I am happy to help connect the dots and get answers to questions outside of my area of expertise. If you find areas of our internal documentation that have gaps then please raise the flag. We are always looking for ways to improve. If you have ideas that would help us to be better or more efficient then by all means speak up. You just found a great way to contribute to the organization right off the bat, and all without writing a single line of code. Nice!
THING #7
YOUR FIRST PULL REQUEST/CHECK IN/PROJECT SUBMISSION MAY CRASH AND BURN – AND THAT IS OK
So we finally made it. You are attempting to contribute to your first project here. Congratulations. Now go clean up the mess you made because your first contribution just crashed and burned. Maybe you were nervous. Maybe your code broke some big feature of the product. The first thing to do is to step back and take a deep breath. It is ok. I am not mad at you because I expected something like this. Your teammates feel the same way. We have all been the newbie at some point and we have all screwed things up in ways that we probably should have avoided. Relax, nobody expects you to be perfect and you aren’t going to lose your job over a bad software commit.
Mistakes will be made. In my interview here I said as much. I will screw up. And I want you to know the same latitude in your own work but you also need to be aware of what was said next: I will learn from this and work to not repeat these mistakes again in the future. Please take this to heart. We practice continuous improvement here. We can always find ways to do things better, faster, and be more efficient. If we ever make it to the top of the mountain that is great because some new project or challenge or even a slip-up will come along and knock us part of the way back down. Or there might just end up being a bigger mounting right alongside that we didn’t see until we made it to the top of this one.
So let’s get you back on your feet, let me help you dust yourself off. Now let’s get back in there for round two, while taking a moment to understand what we learned from this failure. You might not get it exactly right the second time either, but hopefully it is not because of the same issue as before. I don’t know if you realize what is going on right now in this instant – but you should take a step back to realize and remember this moment. You have made it. There is momentum building here. There is an actual, tangible contribution that you are working on. This is the start of a wonderful new relationship and you are now an active contributor on a live project. Congratulations!
So you made it through and didn’t jump ship and we didn’t need to resort to fisticuffs to solve any problems along the way. Welcome to a new dawn. We have projects and challenges, fun times and crunch times ahead of us. There will be good days and bad, but we will face them together. My door is always open and I am glad that you are here. You are a full fledged member of this team at this point and we should go ahead and drop the newbie moniker. Now the real fun begins. Why are you still here? Get back to work!
Welcome to the team.
Comments are closed, but trackbacks and pingbacks are open.