Two traveling men meet on a vast, endless beach.
Both men are traveling with carts full of useful items that they've collected throughout their lifetimes.
The first man, Saul, has built up his collection by finding things beneath the sand. Every day, he digs countless holes. Most of the holes lead nowhere, but every now and then he finds something.
Note: this post was published in 60 minutes.
I've used this analogy over the years with multiple people, both team members reporting to me as well as peers and friends. Since others have told me they found it helpful, I decided to write it down to share more broadly.
Early on in most of our careers, our responsibilities are limited. The people we work with don't depend on us for too much yet. But we may be capable of doing a lot, and many of us are eager to be given a chance to do more.
This is advice that I have given multiple times, to multiple managers. I figured it was time to write it down.
At many tech companies, there is a formal process for requesting a promotion. At Atlassian, the biggest part of this process is a collaboration between a promotion candidate and their manager on compiling documentation justifying the promotion. The main requirement for this documentation is that it provide strong evidence, based on a standard framework, demonstrating that the candidate is performing at the level they're targeting for promotion. Ultimately this document (the "packet") is reviewed by a panel comprising 7 senior staff members, and the panel ultimately decides by vote whether to approve it.
This is something I've observed countless times in both my personal and professional life.
Often, I will hear someone say that they sent someone else an email, or a Slack message, or a text, confident that they communicated important information to the other person.
It can be the same when a team member says, "I wrote a page about this." Or: "I published a blog post." Or: "I gave a demo of this."
I've been thinking about burnout.
It's a topic that comes up often, and the framing is almost always the same: The team is feeling burnt out. What can we do to help them recover? The proposed answers tend to fall into a few predictable categories: games or other social activities, encouraging team members to take time off from work, and gifts (like one of those "I survived <insert nightmarish project>" T-shirts).
About a year ago, a colleague reached out to me for some advice. He was a peer of mine and was receiving feedback from his manager that he wasn't meeting expectations. He suspected that I was faring a bit better within the organization and wanted my opinion on how he could improve.
Have you read The Zax, by Dr. Seuss? It's a powerful story. Ultimately it's about the dangers of stubbornness and pride. In the story, the north-going Zax and the south-going Zax both refuse to budge to the left or the right, neither wanting to concede anything to the other side. Each Zax wants the other Zax to be the one to step aside.
Budgets are useful when you have a limited amount of something and discipline is required to use it appropriately given your needs and priorities.
For example, if you have a limited amount of monthly income (i.e. you are a normal person), a typical monthly budget would allocate a certain amount to your housing expenses, another amount to food, perhaps some more necessities (e.g. medicine, commuting to work), and then the remainder would be divided according to your preferences. One person might have a budget for dining out, another for travel, another for classes, etc.
These past couple of weeks have been surreal. On the Bitbucket team, I have sensed ambient levels of sadness, frustration, and numbness as everyone makes an effort to be productive and contribute to their teams' projects, even while I’m sure many of us have had a voice in our heads asking how any of the work we’re doing matters in the shadow of the terrible systemic problems facing our society: police brutality, systemic racism, and a pandemic that is disproportionately killing the poor and underprivileged, just to name a few.
Many software teams use the term "spike" or "research spike" to refer to a particular type of task where the primary work involved is some sort of research or investigation.
You can find plenty of articles out there defining what a spike is and suggesting when it's useful. This post comes from my own experience and proposes a pretty simple definition that, at least for me, makes the value of a spike perfectly clear. It also helps to avoid a common pitfall I've seen some teams fall into (including some of my own!), saving time and improving outcomes.