4 Steps for Making Immediate Impact as an Engineering Leader

As a leader, onboarding with a new company is hard. The stakes are high–you and your new employer have invested a lot of time and energy into choosing each other–and the objective is complex–quickly go from an unknown outsider to a trusted leader. Oh, and make a positive impact on your team’s trajectory or output while you’re at it.

In any function, this can be a daunting task. For software engineering leaders, there is often an extra complication: the status quo of their new architecture.

Unfortunately, understanding a new architecture–and its TODOs, problems, or deficiencies–is often not straightforward. Questions like:

 
• What (and how many) services and systems exist in production?
 
• Which services are most important?
 
• Are we building with a consistent tech stack?
 
• What initiatives or migrations are in-flight?
 
• Which services cause an outsized proportion of our incidents?

…are typically not easily answered in a few hours. The relevant data might be stored in multiple places, be of dubious quality, or only be in the heads of a few longtime engineers or architects.

In even more challenging situations, the data might not exist at all. Or morale in the organization might be at a level where people are hesitant to answer “hard” questions about past performance - leaving you in the dark.

Either way, as a new engineering leader, you’re accountable for making improvements. And you can’t do that confidently without some data and context on your new architecture. Here are three strategies that will help you stop flying blind.

Observe & Listen

When tasked with a new set of responsibilities or problems to solve, it can be tempting to dive headfirst into doing stuff. Resist that temptation!

You need to make an impact, but you don’t need to make it all in the first month. Instead of acting right away, let yourself be a sponge - soak up all the context and nuance that you can.

How? Meet as much of your new team as possible. Be a good listener. Ask open-ended questions. If at all possible, don’t ask narrow or leading questions that force engineers into complaining, criticizing, or placing blame.

You can also just be a fly on the wall. If you’re observant and (relatively) patient, the important issues and knowledgeable people will make themselves known.

Relationships, Hypotheses, Questions

Once your sponge is full, you’re in a much better position to take decisive action. Start by collaborating with those in your new org who hold the important knowledge. Maybe it’s only in their heads or maybe it’s in a system (or process) they own or support.

Whatever the case, work with them to scope and outline, in broad strokes, what information you need to make high-quality decisions for the organization.

Ideally, make the project a collaborative one that benefits everyone involved and the wider organization–not just you and your next set of decisions.

One way to do this: instead of dictating your requirements “I need XYZ very specific data points”, share your hypotheses and the questions you’re trying to answer.

This should encourage productive dialogue and help return solutions that are generalizable to future use cases.

Implement and Scale What Works

If your process so far has been sound (and not selfish) you should now be well-positioned to operationalize:

Depending on the size and complexity of your engineering organization, this could mean many different things:

 
• Documenting your architecture and key service metadata in a shared spreadsheet or internal wiki
 
• Committing to a regular cadence of review meetings to maintain this repository of information
 
• Assigning one person per engineering team to support and contribute to the new catalog
 
• Assigning one central engineering team the responsibility for updating the new catalog
 
• Implementing a microservice catalog that integrates into your existing toolchain to automate all the tasks above.

Get a Clear Picture with OpsLevel

Especially in complex or rapidly growing organizations, getting complete visibility is hard. OpsLevel can help. Request your demo today to learn how our microservice catalog and service ownership platform combat microservice sprawl and provide clarity to engineering leadership.