July 2017
Volume 32 Number 7
[Upstart]
The First Quarter
By Krishnan Rangachari | July 2017
I’ve noticed that if I do well in my first three months in a new engineering job, I can build an enduring reputation and foundation for success. Here are six strategies I use in those initial months that help win the trust of my coworkers and put me on the right track.
Delayed Start
I push back my official start date, and use the extra time to build connections. So, instead of starting in two weeks, I may start in six weeks. In that one extra month, I meet up with people on the new team, one-on-one. I introduce myself, and just learn more about them. My goal: Establish personal rapport.
I start with the people who interviewed me, because I already know that these people like me. I treat them to coffee or lunch. I ask them open-ended questions like, “What was your process of getting on-boarded onto the team?” and, “How is being an engineer here different from other places you’ve worked at?”
As I go through this process, I’ll discover some people will go out of their way to help me. They’ll share insider tips and tricks, and secret knowledge. I remember those people, and I go back to them for more advice once I’m at the job.
I also ask them, “Who else would you recommend I chat with, so I can learn more about the company?”
There are two major advantages to having these chats before I start the job. First, once I’m on the clock I won’t have this kind of free time. Second, engineers are more frank when I’m not yet on the job. They’ll give me the scoop on things like toxic projects to avoid and the company’s priorities in ways they can’t after I’m in my role.
Managed Intro
My new team will introduce me to everyone, either in person or via e-mail. During these introductions, developers artificially puff up their chests. They try to look more confident and secure than they feel. A side effect: The developers come off boastful.
It’s normal to feel insecure when starting any new job. Instead of trying to kill the insecurity with pride and boasting about my great credentials, I embrace it with humility. If I boast about my background, I convey that I think more highly of myself than my new team. It’s better to let my performance speak for itself.
Manager Maximization
I start to meet both engineering and non-engineering managers, one-on-one. This includes team leads for other dev teams. This also includes managers in product marketing, technical sales, IT, product support, operations and more. When I do this, I stand apart immediately.
Through these meetings, I get a more holistic perspective of the company. I’ll know what projects are actually most pressing to the whole company, allowing me to select more meaningful projects. I also can start to build a pipeline of project ideas of my own and, ultimately, accelerate my career growth.
Three Projects
I identify three projects—or, more realistically, parts of three projects—that I can get started on and finish within the first three months. These projects should allow me to learn the ropes of my new role without overwhelming me.
Instead of doing whatever projects land on my desk, I cultivate the courage to say no and exercise discrimination. In fact, as a new employee, I’m actually in the best position to say no. For example, I may say, “I don’t feel ready to take on that project,” “I’m a little overwhelmed at the moment,” or even, “I don’t think that project will work for me.”
Start Delivering
Once I select projects, I don’t wait until they’re done for some grand reveal. I am the grand reveal. The crucial part isn’t the project itself, it’s how I execute on the project.
For example, in stand-up meetings, instead of vaguely saying, “I’m working on this project,” I may instead state three or four actions I did for the project yesterday. This publicizes my effort without boastfulness, and promotes the hundred baby steps that take me to the end goal. The upside: Even if the end result isn’t as grand as I expected it to be, it’s OK. I’ve made the most of the journey there.
Cultivate Champions
As I execute on a project, I’ll often go to others for help. If someone was particularly helpful, I follow up later and tell them what I did. This way, I signal that not only do I ask for advice, but I also follow it. When I show this kind of gratitude, these people take me under their wing. They’re more likely to give me good advice in the future, too.
Some new developers make the mistake of asking others to be their mentors. In reality, mentorship is cultivated over time. Sometimes, asking someone to be a mentor is the surest way to not have it happen. It burdens them with an artificial, inflated title that they feel they must live up to. It’s more effective to have someone become my champion over time, without either of us realizing it.
Krishnan Rangachari helps brilliant developers have amazing careers. Visit RadicalShifts.com for his free courses.