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.
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
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>"
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.
My first job as a developer was at a company called MP Capital, an algorithmic
trading firm in Philadelphia. Our boss, an experienced trader, would present
models to us and we would do our best to code them. Sometimes he would question
why our models resulted in certain particularly risky trades. To help him
understand cases like these, he asked us to build a feature that would provide
a breakdown of every trade: essentially a record of the algorithm that
triggered it, every step of the way. At the time I didn't appreciate just how
unique this was.