5 min read

Burn After Leading, Part 1

Burn After Leading, Part 1
I really have to start watching more of the movies that I reference. Like this one. All credit to the Coen Brothers and StudioCanal

It isn't easy being responsible for delivering something.

First you have to understand what it is and what difference it's going to make, then you have to put some sort of plan together, then you have to track progress against that plan, you need to intervene if things aren't on track and finally you have to close it all out once the thing is finished.

That's a lot of stuff to have bouncing around inside your head.

For small pieces of work, it's not so bad. You're mostly reliant on yourself or maybe another person and the total duration is short, so the cognitive load remains fairly low.

For bigger pieces of work, like projects or initiatives, the cognitive load is much higher. There are typically more people involved, the scope is larger, the duration is longer and the problems are more frequent and varied.

And that elevated cognitive load can take a serious toll on the people involved.

This Is Some Heavy Stuff

I've written about burnout before, but I'll summarise the concept here anyway.

Burnout, otherwise known as occupational burnout, is a general decline in caring about what you're doing professionally, primarily as a result of constant and persistent stress.

I'd say it's not as much of a hot topic at Atlassian as it once was. We don't seem to talk about it as much as we did at the height of the pandemic, though the various initiatives that were put in place to try and mitigate it are still happening in the background.

That's not to say that it isn't an issue anymore though.

I don't think we've solved the perceived burnout problem by giving people a few extra days off here and there. Fundamentally, I think burnout comes about as a result of a combination of high expectations and high load, and if we don't meaningfully change either of those things, all the days off in the world aren't going to help.

There are still plenty of ways we could change how we operate to make burnout less likely to occur. In order to do that though, we need to understand more about it's causes.

And that means hypotheses!

One such hypothesis is that, for engineers, feature leading is a meaningful contributor to burnout.

Like Intelligence Stuff

What's feature leading you might ask?

At its core, it's all about being responsible for the delivery of a project that is of a meaningful size. A piece of work that is bigger than a few weeks worth of effort, but probably smaller than a couple of quarters.

It's a hat that engineers frequently wear at Atlassian, because while we do have product managers and program managers and engineering managers and manager managers, the responsibility for feature leading is seen as a good way for engineers to exhibit leadership and drive outcomes.

But feature leading comes with quite a few responsibilities.

The first responsibility of a feature lead is to clarify the problem being solved by the project. They don't necessarily have to come up with a problem from thin air, but they do need to take a rough problem/solution space and define it more clearly.

The second responsibility of a feature lead is to actually contribute to the project directly. For most of the projects that engineers feature lead, this means engineering a software solution. You know, delivering incremental functionality according to some sort of plan.

Not all of the work should be done directly by the feature lead though, that is a one person project and is widely regarded as a terrible idea.

This adds another responsibility to the mix, which is to organise work for others to deliver, such that said work is aligned with the desired outcomes of the project.

This isn't a trivial task.

Breaking down a large piece of work such that you can do it personally is one thing, but breaking it down such that others can contribute is vastly more complicated.

But wait, there's more!

On top of the things I've already mentioned, a feature lead has to keep stakeholders updated as to the current progress of the project. This means that they must have a good handle on milestones or success criteria and be able to critically evaluate their current state. The corollary here is that they also need to keep across any developments outside of the project, not only emitting meaningful information, but ingesting it as well.

Finally, there is an administration aspect to feature leading a project. Things like keeping documentation up to date, writing summarisation blog posts, doing project retrospectives and tying everything up in a neat little bow when all is said and done.

That's a lot of responsibilities for a single person, and honestly, I've probably forgotten a few.

I'm Not Comfortable With This

Which brings me to the crux of this blog post, which is the hypothesis that feature leading for engineers is a meaningful contributor to burnout.

It makes sense when you think about.

Engineering is already hard enough. Technology changes quickly, there are a billion different ways to accomplish everything, there isn't always clear guidance about what the right way is, it can be hard to tell if you've actually delivered something valuable, and sometimes you start doing one thing and then end up shaving a yak wondering what went wrong in your life.

Even without adding feature leading into the mix, general engineering pressures can easily cause burnout if they aren't managed correctly. Add feature leading on top of that and surely it must be worse?

Well, maybe.

I don't have any quantitative data that confirms the hypothesis yet. It's all anecdotal evidence driven by manager observation and individual sentiment.

It's a hard hypothesis to prove objectively, because burnout itself is difficult to identify. People who are burnt out, or on the path to burning out, aren't always aware of that fact. Still, qualitative data is better than no data, so asking everyone how they are feeling and whether or not they are feature leading is a good start.

That probably means a sequence of surveys, which is always a difficult thing to do well, but I think it's worth the effort, because proving the hypothesis with measurable data is important.

Once you start thinking about and enacting improvements, you want a clear way of identifying if you're making a difference.

I Want This Out Of Here!

Speaking of making a difference...

None of what I've written above is my work, I'm really just paraphrasing.

A group of people interested in burnout within Atlassian established the hypothesis above sometime last year and has been working on mitigating it's effects for a while now.

Their theory was that the reason feature leading is contributing to burnout for engineers is that most engineers don't have the skills or experience necessary to feature lead with confidence.

In other words, it's primarily an education issue.

Most engineers have some exposure to feature leading in general, but the majority of their knowledge lies in engineering things. Doing something new and different and challenging without the skills to back it up is a great way to generate stress and eventually, the sort of mental exhaustion that leads to burnout.

The resulting program was all about establishing a buddy system.

And I was one of those buddies.

But that's a story for next time.