You have just begun working at the new tech startup. Congratulations! You must feel a basket of emotions, especially if you just graduated from school, or switched careers and this is your first tech company experience. Surely you have a capable manager who will give you a mixture of day-to-day tactical advice as well as drive your long-term growth plan, and a buddy assigned to you who will help with the “on the ground” type of questions you don’t want to bother (or are embarrassed to ask) your manager. There are countless playbooks, excellently indexed, that answer any logistic question you may have. And your team, all sitting around you, can proactively reach out to help with things you’re likely to be stuck with, easily pair with you and are always available if you ask a question from across the desk.

Except that in reality, new hires are on their own more than hiring managers like to admit to themselves (and others). Managers are busy (often solving their team’s technical challenges or, alternatively, dealing with something that has absolutely nothing to do with engineering) and often themselves lack training to give you the right support. Most employees never see any kind of structured development plan. And since the start of the pandemic, onboarding has become an order of magnitude tougher – mostly because of organizational inertia and implicit assumptions that teams have not yet had a chance to question or revisit. Most of the “spontaneous moments” – walking up to a new hire’s desk and doing a quick pair session – are gone out the window.

Now what?

Having spent time with over 150 new hires in the last seven years I’ve noticed themes that resonate with many new Engineering hires, no matter what industry or stage of company. Of course, not all may apply to everyone, and it’s likely that some are already capably handled by the manager, the support organizations (e.g. People/HR), or the team at large. Still, the following suggestions can help you, whether you’re a manager who cares about your new hires, or an engineer getting onboarded.

1. Focus on exposure

The first few months are, in my view, the most exciting time for many engineers. The “honeymoon period” is in full swing, you have excess energy, a ton of ideas, and haven’t been told “no” enough times to stop asking or suggesting things. I advise new hires to expose themselves to as much surface area of the product, the team, the technology, and the business, as they can realistically absorb. Even if you don’t retain all of the information, later you will likely be able to connect the dots more easily. By increasing the surface area of exposure, you are more likely to discover areas you’re drawn to or excited about more. You have more of a presence on the team, which can have a flywheel effect (more presence → more top of mind for people → more likely to be given opportunities to give you more presence). It also allows you to maximize your early value add, by finding areas you can make better – especially if you combine this principle with #2 below.

An uncomfortable secret is that in tech, context is king. Engineers who have been around for years and know every nook and cranny of the technology are immensely more valuable than those who only know a little, even if they have comparable technical abilities. Context will give you an “unfair edge” and the only way to build it is to be proactive about it.

2. Ask lots of questions – even dumb questions

New hires worry that they will look less smart or lazy if they ask questions. But early on is precisely the time when questions are most valuable – to you, because they accelerate your learning – and to the company, because they could lead to a revisiting of some long-held assumptions, or tech debt. My definite favorite are “dumb questions” – questions that seemingly you should have known the answers to by now, or where the answer is “obvious”. I’ve often been surprised how “dumb questions” lead to a realization that others don’t understand things they really should, or to a discovery of some deeply held assumptions that are wrong (or no longer right).

While I like to preface a “dumb question” by an expectation-setting “I have a dumb question…”, mostly to make myself feel less insecure about asking the question, it turns out that others don’t mind dumb questions for a number of reasons:

• The likelihood that the question will lead to a valuable insight, not for the asker but for the answerer
• The value that others attach to the initiative you take and engagement you show (which outweighs any downside of a question that may be obvious or may lead nowhere)
• The disconnect between your inner perspective (you know what you know and don’t know) and others’ perspective of you (they don’t know what you know or what you’re “supposed” to know)
• And when all else fails, a simple benefit of the doubt because you’re new

One question that many new engineers ask me is “If I’m stuck, should I ask for help?” I understand where they are coming from. On one hand, you don’t want to waste precious early time stuck in rabbit holes or paying the price of simply not having enough context yet. On the other hand, you don’t want to be “that person” who always asks others to bail them, and want to appear independent. You probably recall learning valuable skills by having to figure things out in the past. There is a balance to be struck here; my advice is usually to go for the low hanging fruit, and if stuck, talk to a teammate, being transparent about what’s going on. “I’m trying to do X. I’ve done the quick thing but haven’t gotten anywhere. I’m thinking of going down this path. I think it may give me good learnings but I wanted to check with you in case it’s one of these annoying rabbit holes.” You’re not letting yourself off the hook and you’re letting your teammate give you the relevant context – is this journey worth your while?

3. Understand your first project deeply

Don’t just launch into your first meaty project. Start with the basics.

• Why is this project valuable to the company?
• What does success look like?
• What pitfalls can others think of thinking of this project?
• What’s the context behind the project? Is it a lower priority feature or bugfix? A “pet project” given to you to get your feet wet? Code that needs to be cleaned up? Understanding the impetus behind the project helps you figure out what you should focus on

Don’t just focus on the surface area of your immediate work. Take a look at the periphery. Who calls your code? Who does your code call? Does anything not make sense? It’s a great opportunity to understand more of the product, give yourself more exposure, and perhaps find places that you can improve, which feels empowering and shows initiative and a sense of ownership. It sets up a good habit for you and others on the team who, frankly, should be doing the same.

4. Go for deep impact

When doing work or picking up new work, new engineers ask me if they should essentially do a depth-first search on whatever technology they work on (become a deep expert in a small surface area), or breadth-first search (work over as high as possible a surface area, even if superficially). In my experience the former is a superior approach. In-depth understanding, this increasingly more rare ability, allows you to focus, build expertise, and add more value (e.g. have deeper insights or insights in areas that others have skipped). Of course consistent with principle #1, you want to expose yourself to as much context as possible, but when it comes to where you devote your input, avoid jumping around too much at first.

5. Spend time with your manager

Most managers are very busy and their reports tend to avoid taking up their time. But the best thing you can do – for yourself, but also for the company and for your manager – is for you to spend time with your manager. Many failed or delayed projects can be traced to a lack of context or direction that a manager could have shared with their report. In addition to the context, managers can give you feedback which is immensely valuable early on as you learn to calibrate what the team values, and how to be most effective, and get to know you more which allows them to help you grow better (for example, by being on the lookout for the kinds of projects that may help you grow). Let your manager tell you when you’re taking too much of their time. That is not to say that you should be asking for a lot of help, waste their time or generally be a burden. Simply be intentional about what you’re trying to get out of every meeting with your manager, be it

• Explicit feedback sessions (generally, but also on specific work you’re done – for example, go through the code together, or have your manager double check your understanding of something)
• A discussion of your goals and development path
• Specific questions you may have about the team’s objectives or KPIs, or questions to contextualize specific company-wide communication/decisions

6. Take initiative

A generalization of #5 is probably the single most impactful principle you can adopt. Take initiative. Don’t just wait for projects, or conversations about your growth, or feedabck to come your way. Initiative-taking makes things happen, is always scarce in organizations, and it makes your manager (and the entire management chain) more effective. At least for me personally, it is one of the core competencies I look for when assessing someone’s leadership potential.

7. Pick out role models

You may be tempted to compare yourself to others (especially other new hires) as a way to validate your own value and impact, or to motivate you to work harder to be compared more favorably to them. Instead, my advice to everyone – not just new hires – is to pick out “role models” in the company with an express purpose of learning from them – maybe even explictily seek to “be like them” in the near future. Pick multiple role models that span various competencies or abilities, and look in unlikely places (someone could be pretty average but a role model in a very specific thing they do excellently). In the past, engineers who have learned the most from this approach came up with a “roadmap” of role models, picking people they want to “be like” in 6 months, then a year, then two years etc.

Once you have your role models, let them know! Not only does it give them valuable feedback about which characteristics are valued by others on the team, but more importantly, it allows them to help you grow. Not everyone who is good at something can teach you to be good at it, but this knowledge helps more often than it hurts you or the relationship.

8. It’s OK not to have personal goals

When talking about the growth path of engineers, I always make it clear that they don’t have to have a ready answer for their development goals. Many new engineers, especially more junior ones, feel that they need to have goals to show that they are self-aware and reflective. Some remember or were told the Lewis Carroll quote:

If you don’t know where you are going, any road will get you there.

The problem is that this idea is often taken literally as a requirement to have a master plan for life. Instead, I take a much more expansive view: be intentional, but not necessarily about your specific development goals. If you don’t have a goal, set a meta-goal: how can you figure out a goal for yourself? Or focus on the basic building blocks (become a better software engineer, or work on larger projects) without necessarily knowing what you’ll eventually build out of these blocks.

Finally, it is very much your manager’s responsibility to help you grow, and a part of this responsibility involves surfacing insights, suggestions and feedback that lets you establish your goals.

**

I wouldn’t turn these eight principles into a checklist. Instead, my suggestion is for you to first of all think about whether you agree with them. If you’re not sure, have a conversations with others who may have opinions that could help you decide, and experiment with them to see if following them gives you results which “feel” good. If you do agree, think about your current approach to them: do you have one? how would you grade yourself on these? For any principle that doesn’t seem to come naturally, come up with a plan that works for you.

Oh, and most importantly – don’t try to boil the ocean. One of the best parts about being a new hire is that you have plenty of time to figure everything out.