In a rare two-parter, I'm going to continue to ramble about burnout, feature leading and the mysterious buddy program.
To get us back on track, the crux of Part 1, was the hypothesis that feature leading for engineers is a meaningful contributor to burnout. I also explained what burnout and feature leading meant in this context, so if you want some background, go and give that post a read.
But what to do about it?
The good news is that we didn't just identify the problem and then move on with our lives. A group of motivated people aligned themselves to the perceived issue and started thinking about how to solve it.
Use the power of friendship.
Talking Here About Department Heads
Facetiousness aside for a moment, the group theorised that feature leading for engineers contributed to burnout because of the stress incurred from a lack of experience and skill. Not in engineering, but in all of the responsibilities that are expected of a feature lead.
- Problem exploration and clarification
- Project contribution
- Work breakdown and delegation
- Project communication and progress evaluation
- Project administration
The solution to that?
Establish a buddy program, where people who are experienced in those things are paired up with engineers that are feature leading. No specific topics or curriculum, just getting together regularly to chat about whatever was happening to the feature lead at that time.
For example, if the feature lead was struggling with doing project updates, the buddy would explain how they've done updates themselves, and maybe even help the feature lead to craft a few, to give them the confidence and experience that they need to move past the issue.
Beyond that, the buddy would also just listen. There is something to be said for having someone to talk to if you're stressed. Someone who understands and doesn't judge. In order for this to happen though, the buddy needed to be somewhat disconnected from the engineer who was feature leading, from a management point of view.
Atlassian has a great blameless culture, but it's still filled with high performing people who want to do well, and a direct manager acting as a buddy could be a conflict of interest.
From the buddy's point of view, they got a chance to share their skills, get more experience acting as a mentor, meet new people and learn more about other areas of the business
The group chose to run a pilot program in order to test the feasibility of the buddy system. A limited number of participants for a single quarter. At the end, evaluate whether or not any value was generated from the pilot and then go from there.
That sounded pretty good to me, so I signed up as a buddy.
And Their Names And Stuff
I was paired with an engineer in a nearby team, but one that I had very little context about. They worked in Encryption and were responsible for a couple of projects that were directly contributing to a major company initiative to help migrate Server customers of Jira and Confluence to our Cloud equivalents.
We met pretty much every two weeks for an hour, with a couple of missed sessions due to conflicts and holidays.
Over the course of the quarter, we covered off a wide variety of things that I consider to be good feature leading practices, like:
- Project focus (i.e. minimising parallel work)
- Success metrics
- Project retrospectives
- Work breakdown
- Intervention (i.e. knowing when to intervene and how)
- Dealing with project delays
- Project grooming
- Clearly communicating project status
All of these topics came up organically. I wasn't working through a list or anything, I was just talking to the feature lead, asking them how it was going and offering my own thoughts and experiences as a result.
I spent a little bit of time outside of those sessions doing some reading and trying to understand the context of the projects, but I'd say the total investment from my point of view was maybe ten hours over the entire quarter.
But was that investment worth it?
Then There's These Other Files And Numbers
Emotionally, I enjoyed myself.
It felt good to learn more about a different area of the business, to get to know someone new and to listen to their problems. Interestingly enough, while I was fully engaged in what was going on in the professional life of the feature lead I was buddying, I wasn't responsible for solving their problems.
As a manager, I'm always responsible for solving problems. If something is happening within my own team, it's literally my job to investigate what is going on and figure out how to mitigate it.
It can be really exhausting.
So, it was nice to be able to just offer advice with no expectations that it would be taken, to listen without that nagging feeling in the back of my head reminding me that if this problem doesn't go away, I'm going to have to deal with it.
As you might also be able to tell from the amount of words that I vomit forth on this blog, I also really enjoy sharing my experiences and thoughts, so another opportunity to do that is always appreciated.
I'm pretty sure the feature lead that I was buddying enjoyed the experience as well. Mostly because I asked them to their face, but also because they kept making time to meet up and talk, which is usually a good sign that at least some value is being generated.
Outside of our pair, the buddy pilot program was generally a success.
We did a survey at the end, sent to everyone who participated (i.e. feature leads and buddies). All told there were five pairs, so ten people. Of that ten, we got seven responses, which is a solid 70% response rate.
The results were pretty good.
~70% of the cohort found at least some value in the buddy program, with comments indicating that buddies liked learning about other areas and feature leads really just liked having someone to talk to who was disconnected from their day to day.
~58% of the cohort met only a few times (once or twice) in the quarter, with the remaining ~42% meeting more than that. The biggest complication to meeting more often was not necessarily that they didn't see value in the sessions, more that everyone was always really busy, and scheduling is hard.
Finally, ~86% of the cohort were in favour of either rolling out the program to a wider audience as is, or were happy rolling it out with a few tweaks. The desired improvements were focused around setting clearer expectations, establishing the buddy relationship for the entire duration of the project (not just a quarter, because the two don't always line up) and for all of the buddies to have a consistent view of what good feature leading looks like.
At the end of the day, we've only run a pilot program so far, so we don't know if the buddy program will actually reduce the burnout that comes from feature leading.
That's not unexpected because I wouldn't expect a pilot program to solve the root problem, it's more about testing the process. You can't know if it's going to make a difference until you roll it out.
And we'll probably do exactly that, because most people agreed that the buddy program provided some value.
We're just not sure if it was the value we were aiming for.
In order to be sure, our next steps are to establish some better measurements for burnout.
First this will help us prove the initial hypothesis, that feature leading for engineers contributes meaningfully to burnout. We're pretty sure it does, but it pays to check anyway.
Second, if we get a good measure or metric going that enables us to see burnout trends, we can probably do some A/B testing, giving group A access to the buddy program and leaving group B alone to see if it makes the difference we want it to.
We might not be scientists, but that's no reason not to use a scientific approach whenever we try to change something for the better.