All Aboard: Optimizing the Onboarding Process

The first day at a new job is incredibly exciting. New opportunities, new colleagues to meet, and innumerable acronyms to memorize. Especially for an entry-level engineer, the initial few days in a new role can be an overwhelming mix of HR tasks, attending meetings, reading documentation, and drinking from the firehose. But once the honeymoon period ends and the new company-purchased laptop with its fresh development environment is all set up and ready to go, the paths to success begin to diverge.

While engineering chops and technical proficiency will get you far, soft skills make the difference between a great engineer and an indispensable team member. The following few tips heavily influenced my career trajectory and have provided me opportunities in the world of software engineering that I could never have predicted. Pick and choose and combine with other career advice until you get where you want to go.

Caveat: your mileage may vary. These tips helped me and others with whom I've worked, but they are by no means a panacea, nor do they apply to every company and situation. Use your best judgement.

Documentation#

If you've joined a company with a well-established onboarding process, there will probably be documentation that you are supposed to follow to get set up and bootstrap your development environment. This may be in a series of Confluence documents, something like readme.com, some Google Docs, or Notion, and probably contains a large repository of aggregate documentation from the course of the company's existence.

After you've followed the directions you need to follow so that you can start contributing, keep reading. Read through your team's docs first, and bookmark anything that looks like it could possibly be relevant in the future. Being the resource of forgotten knowledge makes you an important resource. Make sure you read as much as possible, even if it doesn't directly relate to the work that you'll be doing--you never know when it might come in handy.

Keep reading when the technical content ends.#

For a lot of engineers, reading documentation has become a bit of a joke; especially in a new position, don't fall for this. Reading code can provide current technical context, but diving into written documentation is the best place to learn about the business and product background of your new company (see the Involvement section below). The more of that documentation you read now, the faster you'll be able to start working in and designing for more complex parts of the stack. It will also allow you to start contributing in business-oriented or high-level meetings with product managers, where the topics of conversation tend to be less technical and more domain-oriented. Understanding the business implications of technical decisions is a key characteristic of engineering leaders.

Documentation is also a really good way to invest in technical debt. Chances are, if there is historically a lot of tribal or domain-specific knowledge at your company, the key to unlocking it is hidden in a README or piece of code commentary that no one has ever bothered to put in formal documentation. Frequently, you won't know you need this until you need it. If the company ECS expert was let go when the company finished its migration to Lambda but one piece of containerized infrastructure still exists and starts to fail, the on-call engineer will be indebted to whomever wrote down the proper debugging steps. Set yourself apart by being the person to record that information for posterity.

Make yourself a subject matter expert.#

Contributing to docs is a really good way to set yourself apart as an engineer. The same way most engineers eschew reading documentation in favor of code, even more don't write documentation themselves. Even if you've just started at a company, write down the weird things you find in code--someone might thank you for this later, when they have to debug an issue with an odd or undocumented bit of implementation (that someone may even be you!).

If there's part of your teams's stack that you find particularly interesting, document it as much as possible. Create docs in your personal space or locally (or even in your team's space, if your company allows it), then when anyone has questions you can send them your accumulated domain knowledge. Pretty quickly, you'll become the subject matter expert for whatever you've documented, even if you didn't write the initial implementation. Ownership, more than authorship, is key to making a name for yourself.

Mentorship#

Unless you're a very high-level engineer you'll be reporting to someone when you start in a new position. If that person tends to be less accessible, you'll probably be assigned an onboarding buddy who is intended to help acclimate you to your new role. Treat this person as your mentor. Ask them questions and learn from them. If you want to be a principal engineer, take notes on how they interact with the other engineers to guide technical direction and priorities. If you want to move towards leadership, watch how they interact with product management and stakeholders to create a buffer in front of the engineering team. Have a regular one-on-one meeting with them where you can bring up any concerns you have, and ask them about how you can make an impact and improve in your position.

There's no such thing as a stupid question.#

Especially during your onboarding weeks, no one will look at you funny for asking questions of a very basic nature (if they do, that's probably a sign of questionable company culture, but I'll save that topic for another article). Take advantage of your first few weeks or months at a company to ask as many of these questions as possible. Get to know the ins and outs of your business, but also figure out who knows what. Being the resource of resources can be almost as powerful as being a resource yourself; delegation is also a quality of good leaders.

Make yourself a resource.#

Once you've established yourself a little more, try to help others. If your team has an internship program, take opportunities to help them with their tasks or provide mentorship. Volunteer to be the onboarding buddy for new hires. Give tech talks or lunch and learns on subjects about which you are passionate, and make sure that your talks are recorded and documented. Jump in on Slack or in meetings when questions are shouted to the void. This piece of advice is very much synonymous with some of the advice on documentation above, but within the context of meetings and relationships with colleagues.

Involvement#

Finding ways to participate in high-visibility projects can result in vast upwards momentum. This could mean volunteering for new initiatives, becoming the domain expert for a part of the stack that no one else wants to touch, or suggesting and owning improvements to existing processes.

Put yourself in uncomfortable situations.#

Very few engineers will ever love being on call. Most probably hate it. Handling incidents, however, is an excellent way to become indispensable. As soon as possible, find a way onto the on-call rotation and start handling pressing issues. Not only are they usually high visibility, but they'll also provide valuable insight into what parts of the stack need better scalability, resilience, or investment into technical debt. Use incidents to hone your project management chops. Take notes on issues discovered during mitigation and follow up with action items. Find ways to triage and prioritize these issues in order to make life easier for the next on-call engineer.

If your organization uses operational intelligence tooling (and for your sake, I hope it does) figure out how they connect to business-critical systems. Bring anomalies up in team conversations. Know where the incident response documentation lives and have a rough idea of how different types of incidents can be mitigated Jump in on incident response and help connect engineering priorities to site reliability by creating new runbooks, shoring up weak systems, or improving alerting. Make operational excellence a priority; especially if the software your team creates is known for downtime and errors, increasing uptime--or at the very least, visibility into ongoing problems--is a high-profile achievement.

Of all of the advice here, this one is possibly the most dangerous. Being the person to whom everyone goes when something is on fire can quickly cause burnout, so make sure good processes for on-call rotations and escalations are in place.

Put yourself in the spotlight.#

In most software engineering jobs, the work is consistent but the visibility is not. This is especially team-dependent. If you're on a devops team where most of your work is routine maintenance, your achievements may be far less visible than those of someone on a feature team consistently shipping high-value code. Finding ways to work on projects that have high visibility within your organization can help you stand out and will most likely open up additional opportunities in the future. Volunteer for the moonshot teams or the SPIKE teams targeting ambitious infrastructure improvements. If you have the time, prototype improvements and demo them to your org. Take things that annoy product managers and find ways to improve them. This could be tooling, reporting, procedural improvements--anything that may let non-engineers know that you're willing to play ball. Upwards visibility isn't constrained to an engineering hierarchy. And the best part: even if you fail, even if the SPIKE team can't improve a target metric, you get to say that you took part in it and learned from your mistakes. That's almost more valuable than achieving something miraculous.

Setting Sail#

Boat puns aside, the contents of this article are only the tip of the iceberg of software engineering success and they are very opinionated. Not every organization is the same, just as not every engineer is the same. If I could summarize the most important parts: find ways to be involved beyond your job description, to contribute beyond your title, and to make an impact beyond just writing code.

Above all, learn something new. That's what it's all about.