One of the best things about being a Principal Engineer at Mailchimp is the time I get to spend chatting with other engineers who are earlier on in their professional journey. After two years, I’ve talked to quite a few, and at one point or another, almost all of them ask me how they can develop their career.
It’s clear that deepening your craft, being diligent about tests, and writing documentation are good things to work on. But there’s one thing I mention whose importance people often haven’t considered. It’s not especially revelatory, nor particularly glamorous, and it’s not even engineering-specific, but it is vitally important:
When you’re a junior engineer, you probably have one or two tasks at any given time, and usually they’re on just one project. But as you take on more leadership, you tend to take on more scope — bigger problems, larger projects, more moving parts. Pretty soon you’re largely delivering your outcomes through other people, and you might be trying to coordinate multiple teams, groups, or projects simultaneously. You have more to worry about, and less direct control.
Your own leaders want milestones and deadlines from you, because they have to provide milestones and deadlines to their own leadership. (And not even the C-suite is immune, because fundamentally we’re in the business of providing software as a service to our customers, and they — and our competitors — exert a pressure of their own.)
So, most leaders — at whatever level — are in the business of packaging up uncertainty from the folks they depend on, and giving some certainty to the folks who are counting on them.
The absolute best way you can help your leaders do that is by being dependable. And by that I mean making commitments, and keeping them.
Leadership is often like keeping a dozen plates spinning simultaneously. There’s more than you can handle, and you constantly need to keep switching your attention to prevent things from falling. On a team where your leader is trying to coordinate the output of a bunch of different people, the greatest gift you can give them is the relief of knowing that you’ve got your part covered.
As well as the positives for your colleagues, proving yourself dependable offers two concrete benefits (assuming competent management). First, you’re far less likely to be micromanaged. More importantly, you’re likely to be considered for more interesting, complex, or business critical projects, all of which will help other areas of your growth.
Understanding this need for dependability makes it clear why leaders emphasise certain routines as best practices. Writing a spec before writing code might seem like a waste of time, but it helps us think through what we’re doing, how long it might take, and what might be tricky. Retros help us look back at how a project went, so we can take things into account next time. Giving a good amount of notice for vacation time helps us understand how much time we actually have to deliver something. Bringing in cross-functional stakeholders early on means we’re all on the same page and avoids surprises.
Even when we do all that, we’re sometimes off in our estimations. Software is a collaborative, creative, problem-solving endeavour, and sometimes the problems are new (or new to us) and things take longer than we expect. We’ve all had that moment where we’ve realised “ugh, this is going to be late”.
I want to strongly encourage you to tell your leaders as soon as you feel that awkward pit of the stomach feeling. It’s never too early. Really.
It can be embarrassing to admit we got our estimates wrong, or that we’re finding something hard. But, it is far, far better to know on Monday that something might not get delivered this week than it is on Friday. With that early knowledge, leaders have options: cut scope, give you more support, delay a launch, or whatever. The longer you wait to tell them, the fewer options they’ll have, the later they’ll have to tell their own leaders, and the more stressed they’ll be.
As engineers, we’re here first and foremost to build valuable things for our customers. We can do that far better as a team than as individuals — but only if we’re well coordinated. Being dependable is a really important way you can help with that coordination, no matter what level you’re at!
So, the next time you’re thinking about how you can improve as an engineer, ask yourself: how might you increase your dependability?