My experience getting hired at Lob at the Staff level made me realize I may have some learnings to share. I've been at the Staff level previously, but that was at a company where I had been promoted up to those levels; I was already very familiar with my team, my company, our business, and our platform, so it was just a natural progression of responsibility for me. But getting my current job was the first time I'd started at a new company at such a level of seniority. And while at least for me, every new job is a major invitation for an Imposter Syndrome attack, this had the potential to be an even greater one. But I fought it, and I was really intentional about how I approached getting up to speed and be effective more quickly and smoothly than I have in previous new job experiences.
So you've landed the job, now what?
You worked hard to get through that interview cycle, you got the job offer, you accepted it, —you won! But then the insidious thoughts can start. "But what if they got it wrong and I'm actually not good enough? What if people there are smarter than me? What if they don't like me? What if their expectations of Staff are different than where I was before and I don't meet them?" The stories can go on and on if you let them.
This is where I stop the stories and I tell myself, "Hi, Imposter Syndrome. I see you. But I'm not going to let you control my life. Even though I'm feeling really nervous right now, here are some facts I can tell myself:”
I got the job. They liked me enough, they saw enough of something in me to offer me the job.
I have a proven track record for performing, getting positive feedback and reviews, and getting promoted. All of those people saw something in me and they can't all be wrong.
All I can ever do is my best. I can work hard, I can try my best, and if that's not good enough, then that's outside of my control.
Worrying about what might be before I have any information to act on isn't going to change or help anything.
There will be a number of people that are smarter than me or have more experience than I do in a number of things, and that's okay. If I'm the smartest person someplace, then who will I learn from? How will I grow?
No one is a know-it-all
Let’s address that last point. Starting at a new company, at a level of some seniority, it can feel like you should be expected to be the expert in all the things. Well, there's this concept that I constantly remind myself of called being T-shaped; inspired by this article in Forbes: Why T-shaped teams are the future of work.
While generalists know a little about a lot of subjects, and I-shaped employees are experts in a single area, a T-shaped person is a subject-matter expert in at least one area and knowledgeable or skilled in several others.
If we lined up several t-shaped engineers in an organization we would have plenty of overlap in general knowledge but bring a different mix of experience and specialization to the table. So, I don’t have to be the expert in everything; we can share the load.
One of the most powerful blog posts I've read, and it really helped me personally with this concept was written by a well-known engineer I respect, Dan Abramov, titled The Things I Don't Know. He very openly and publicly shared with thousands of followers that while he may be an expert in a number of things, there are plenty of things that he doesn't know very well or at all. What was really empowering about that list is there were some things that he didn't know that I did. So if Dan Abramov can be brilliant at some things and struggle with others, I can too.
Behaviors to Avoid
You’re really going to want to show everyone as soon as possible that you know what you’re doing and deserve the title you’ve been given. But, here are some things to watch out for so you don’t end up starting off on the wrong foot and acting like a jerk.
1. Don’t assert things just to show off what you know
It's fine and absolutely appropriate for you to be sharing knowledge and helping to educate others, but just make sure the context is right. **If you find yourself constantly feeling the urge to talk about the things you've done before or point out something you know that doesn't actually add value to the conversation, try to hold back. **This can make you either sound arrogant or desperate if you do it too much. You will have plenty of opportunities to demonstrate your skills and knowledge.
2. Don’t try to change too much too soon—take some time to observe and learn first
Maybe something isn't exactly the way you would've done it or have done it in the past, but that doesn't necessarily mean it's wrong. Make note of these things that seem to go against what you would've done in the past, but resist the urge to jump in immediately and call it wrong. Part of your role is to improve things, and teach others how to do things in a better way, but until you've had time to really get your surroundings, you may not have enough context yet.
Take some time to get the full picture. Gather data, ask questions, but withhold judgment until you've had a little more time to get to know people, processes, and history. Ask questions humbly and from a place of curiosity.
Along that note, pick your battles. When you have that instinct to assert that something should be done differently, continue to ask yourself, “How important is this right now?” Make a note, and you can revisit it later with more context.
3. Resist perfectionism
During this time of high insecurity, you're going to want to project nothing but perfection. But perfectionism is a myth and thinking that you have to be perfect is toxic, not just for you but for the others around you. Part of being a leader is mentoring others, and a portion of that is done by what behavior we are modeling to them. If we show others that we never make mistakes, there's nothing we don't know, we work however many hours it takes to get the job done, we're always available, we're never stressed or tired—I could go on and on—we send that message to others that in order for them to be successful, they have to be that way, too.
It encourages them to set unhealthy, unfair, and unrealistic expectations of themselves. So as much as it goes against that urge to prove yourself to everyone right now, you are doing a greater service to others if you can model some vulnerability. More junior folks need to see that everyone makes mistakes, no matter how much experience you have.
What_ is_ important is demonstrating how you handle yourself when you make a mistake. Calmly own your mistake openly and early. "Here's what happened and here's my game plan for what I'm going to do about it." Take responsibility without being embarrassed or overly apologetic. Just be transparent about it and then get it fixed.
We should foster an environment of continual learning. There were many times when I'd have to say, I don't know how to do that yet, but I'll get back to you. Then I'd use that as an opportunity to go figure that thing out. Don't act like you're just so smart that nothing is hard for you, but rather show others it doesn't have to be scary to do something you don't know how to do.
As software engineers, we need to be comfortable with being uncomfortable and able to figure things out. I see a lot more junior folks trying to stay in the areas they're already familiar with and avoid branching out. They're hanging out in the shallow end of the pool. Show them by example that swimming into the deep end doesn’t have to be intimidating.
Behaviors to Adopt
Now let’s address what you should do to get up to speed quickly and start providing value ASAP.
1. Start taking notes early
Your role as a Staff + Software Engineer is to be a sharpened tool. You bring with you a lot of experience and skills and you can be deployed to accomplish tasks for your team, your manager, or even the engineering organization level. You may be given the responsibility and freedom to work on special projects or tasks that cross team boundaries. You may be given a level of autonomy to decide or at least propose what you think you should be working on.
That said, you can only do so many things at a time. So you have to be very thoughtful about how you prioritize your time and what you choose to spend that time on (more on that in a moment). But as you're learning your way around, start taking notes. You should be keeping your eyes out for opportunities to improve, optimize, and make systems, processes, and people better, but early on, just make notes on all of those things you notice for reference later.
2. Prioritize what you're spending that time on
As you're finding yourself getting caught up on the learning curve, and you're starting to feel more comfortable with your surroundings, that's a good time to start reviewing that list of items you've been building. Is everything on it still something worth spending time on? Can/should any of those things be delegated to others? Whatever's left will need prioritizing.
In the book _Staff Engineer _by Will Larson (which I highly recommend) he references a quadrant of impact versus effort.
“Work on What Matters” is worth a read to understand where you might go astray, but, in short, the goal is to aim for the top half of the quadrant at the “high impact” tasks. Keep checking in with yourself, both before you prioritize your work, and after you’ve started a task, to make sure it’s the right thing at that time for you to be doing.
3. Start meeting people
If you're an introvert or you have some social anxiety this could be really difficult. But I've learned how to push through that anxiety when it's important. Inside, I may be wanting to curl up in a ball and hide, but outside I try to project comfort and confidence; I think that's a crucial skill for being successful as a software engineer.
I can't take credit for this next idea, but now that I've done it, I think it's a must-do when starting a new job. At Lob, every new hire is given a list of people by their manager whom in their first two or three weeks, they have to set up one-on-one meetings with. These are people that are going to be important for the new hire to get to know in their role, or who can provide context or history about the company and business. These can be in-person or occur remotely. (If remote, I would really encourage you to turn your camera on. I think that it is so important to see people's faces and to really feel like they're in that room with you to build that familiarity and rapport).
This was an invaluable exercise for me; it provided me with context on the decisions and directions that had been made before me, and helped me quickly develop relationships and build my network of peers and go-to people for the various things I would need in my job.
Try to distill from others that you talk to what are the biggest problems, pain points, and challenges that they think the organization is facing today? These are good things to take note of so that as you settle into your role, you could try to find ways to improve on these things.
4. Learn in public
While you're getting up to speed on so many things, it's a perfect time to start a “learn in public” culture at your company if it doesn't already have one. Learning in public is where you share what you've learned as you're learning it.
We don't have to hide while spending all night trying to cram on some framework we don't know just so we can log on tomorrow and act like we've been an expert all along. We can be open about where we're at today, and at the same time, we can share the learnings so that others can benefit from what we've discovered. Ask questions in public channels and keep knowledge sharing out of DMs. Show others that they don't have to be embarrassed to ask questions.
In turn, when you learn something new, share it publicly and share often. At Lob, we have a Today-I-Learned channel in Slack, where anyone can share anything in there and the whole engineering organization can see it.
Another great way to share learnings is to demonstrate them. If you've learned how to do something or if someone asks you to show them how to do something, instead of just showing them privately, consider recording a video. Now you can share that video and more people can benefit from that demonstration.
With all of this, try to keep the barrier low. Don't spend a ton of time putting together a perfect dissertation or a superbly polished video. Just hit the record button and start talking. The more you do this, the more others will catch on and not feel intimidated to do it themselves too.
5. Know your learning styles; use them to get to know the landscape more quickly
If you aren’t familiar with learning styles and what yours are, a simple Google search can educate you as well as lead you to a number of quizzes to pinpoint what works best for you for learning and retaining knowledge. Once you know what styles work well for you and which really don't, you should lean on that awareness to really focus your plan for how to get up to speed.
That being said, you should probably do at least a little of each approach, because we shouldn't limit ourselves to just our preferred methods. We need to be flexible and perhaps with practice, styles that haven't been working well for us can be improved.
Visual or Spatial learners do best when looking at visual or spatial representations of information. This could include things such as charts, diagrams, images, and anything that shows ideas in an illustrated way. You may want to lean on using UML diagrams to help you learn more about the platform, interactions between applications, and even within applications. Build your own integration and activity diagrams, or even just flow charts as you trace through things.
Auditory learners do best when hearing information presented to them. Reach out to those people you've been meeting in that network or peer group you've been building and ask them to walk you through some things. Ask people to pair program with you, either on your coding tasks or theirs. (This can be a gift to more junior folks because it gives them an opportunity to teach and explain something that they know to someone else!)
Verbal learners do better when reading and can retain that information better when they write or speak about it. So read the docs! As you learn more, start writing and contributing to those docs. Read code, especially PRs, even if you're not the requested reviewer. This can help you see firsthand where things are being done and how. This can be a great way for verbal learners to quickly pick up languages, frameworks, and libraries they're not familiar with yet by seeing exactly how those technologies are being used.
The kinesthetic learning style is learning by doing, and I've lumped this together with the logical learning style, which involves the use of logical reasoning when processing data and solving problems. In software engineering, I think these two often go together. It may seem like the chicken or the egg situation. If you're trying to learn and get up to speed, but the best way you learn is by doing and solving problems, how can you do things if you still don't know enough? Sometimes you just have to jump into the deep end and be over your head for a little bit. So find projects or tickets to work on that force you to learn your way around.
Last but not least
Try to have fun! Hopefully through all of this, you can keep that Imposter Syndrome monster at bay and really believe that you are exactly where you're supposed to be—and deserve to be, and you can just enjoy the process. Enjoy meeting your new teammates and forging new relationships. Get to know your manager and let them be an ally for you. Build that peer group so you have other people you can confide in and share with if you're feeling stressed, frustrated, or overwhelmed. And celebrate and be proud of your accomplishments—you worked hard to get here and you should feel good about it!
Content adapted from Lob Staff Engineer, Erin Doyle’s, presentation at REFACTR.TECH: How to Hit the Ground Running Starting as a Staff Software Engineer at a New Company.
Oldest comments (0)