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.
Here's a little tip I received fairly early in my career. I've heard this in
various forms from various people, but the following is a quote from a boss I
had not too many years ago:
Operate as if you already have the job that you want and then you'll be
promoted and everyone will be surprised, thinking you had been in that role
It's been a while! This is another 60-minute post.
Here's a concept I often find myself mentally coming back to. I frequently want
to use these terms in conversation, but I refrain because I am aware whoever
I'm talking to doesn't have a shared understanding of what I mean by these
terms. So this is me writing it down so that I can link to it in the future.
If you search for "pit of success" (a well-known concept in the software field,
and perhaps in other fields) in Google, the first result is a blog post on
by Jeff Atwood. In the post, he links to an MSDN
by Brad Abrams, which as far as I can tell is considered the seminal piece of
writing on the topic (though the term itself was apparently coined by a CLR
architect named Rico Mariani).