Blind spots and bright spots

Tim Ferriss had Adam Grant on recently. It’s a fantastic episode, but it gets extra fantastic at 1:33:00. Adam says that we shouldn’t write our own personal READMEs. We should have our coworkers write them for us.

Who better to give tips for working with you than the people who work with you? They’ll expose your blind spots and your bright spots (i.e., things you’re good at that you don’t know you’re good at). That’s the stuff that a personal README needs. That’s the meat.

Here are the questions he says your team should answer:

  • What are my strengths and what brings those out?
  • What are my weaknesses and what brings those out?
  • What do you now know about working with me that you wish you had known from the start?

Camille Fournier posted a crispy Twitter thread about this a couple years ago:

Adam’s suggestion should expose the “glaring blind spot that will undermine your credibility.” Have your coworkers write your README and your own blind spots are irrelevant.

I’m going to give it a shot. I’ll report back!

Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!


Non-fluffy brainstorming questions for long term career planning

  • If someone kicked you out of your house all day every day, what would you do with all that time?
  • Who would you like to trade places with? Whose job do you wish you could take?
  • What’s true about you today that would make the 10 year old version of you sad?
  • What are your 2 values? How can you build a career around those 2 values?
  • What would you do all day if you didn’t have to worry about making money?
  • When are you at your best (if you’re not sure, ask your coworkers and friends)? How can you build a career around that?
  • What are some things you’re good at, and how can you combine them?
  • What can you do with your time that is important? Of that list, what makes you feel excited?

Did you read those and get overwhelmed? Did you start convincing yourself that you don’t need to worry about it right now? You’re wrong. Right now is exactly when you need to worry about it.

If you wait until it feels urgent, you’ve waited too long.


A tiny guide to Sprint Planning in Scrum

The team only has to answer 2 questions in Sprint Planning, but they’re big ones:

  1. What can we do in this sprint?
  2. How are we going to do it?

Only the Development Team can answer those 2 questions. Nobody else can tell them how much work they can do, or how they should do it. Therefore, the Development Team leads sprint planning

First the whole team works together to create the Sprint Goal.

Then, the Development Team moves tickets one by one from the top of the prioritized Product Backlog into the Sprint Backlog. They stop when they feel like the Sprint is full enough.

After that, the Development Team self organizes around the work and creates a plan for the sprint. This is where they discuss parallel vs. sequential work, or decompose tickets that are too big, etc.

Voila! That’s a planned Sprint!

For more information, see the Scrum Guide section on Sprint Planning.


  1. Sprint Planning shouldn’t be led by anyone besides the Development Team. Not the Scrum Master, not the Product Owner, not the PM. It’s harder for the Development Team to take ownership of their work if they aren’t leading the discussion.
  2. Sprint Planning shouldn’t gather a collection of unrelated tickets for the Sprint. As much as possible, tickets should all relate to the single Sprint Goal so that people can work together towards a single iteration.
  3. Sprints should never be pre-planned before Sprint Planning starts. The Sprint Backlog should be empty when Sprint Planning starts, so there’s no hidden pressure to commit to a pre-planned sprint. I’m talking to you, Product Owner who puts tickets into “sprint buckets” before Sprint Planning.

Do you feel like you’ve grown more in the last few years than you will in the next few years?

I came across the end-of-history illusion the other day, and it hurt.

The end-of-history illusion is a psychological illusion in which individuals of all ages believe that they have experienced significant personal growth and changes in tastes up to the present moment, but will not substantially grow or mature in the future.

[…] Overall the study concludes that at all ages individuals seem to believe that their pace of personal change has now slowed to a crawl, while evidence points to this being an underestimation.


Owwwww! I have grown and changed so much in the past few years. It doesn’t seem possible to repeat that rate of growth in the next few years. What else is there to learn? How else could I possibly change? I’m an idiot, but hey, apparently so is everyone else.

One of the conclusions of the original study was that “not only do people underestimate how much they will change in the future, but in doing so jeopardize their optimal decision making.” That’s terrifying.

Growth is one of my 2 values and a few weeks ago I realized that I should pursue growth rather than happiness. Now I’m realizing why that took me so long: because I assumed I couldn’t continue to grow at the rate that I have.

Make mistakes of ambition, and not mistakes of sloth.

Niccolò Machiavelli

My takeaway is there’s no speed limit on growth. There’s no point of diminishing returns. The more I look, the more I’ll find.

I can’t make decisions based on the assumption that growth will slow down. I can’t make mistakes of sloth. If I’m going to make mistakes, they better be mistakes of ambition.


“Strong opinions, loosely held.” Sure but why?

The question that everyone starts with is: how can an opinion be both strong and loose? Answer: it’s referring to 2 different things. Strong is a level of extremity, and loose is a level of conviction. We could rephrase it as “extreme opinions, with low conviction.”

Example of a strong opinion, loosely held:

Python is a terrible solution for this problem, but I’d be open to changing my mind if you showed me a nice proof of concept.

Example of the opposite – a weak opinion, tightly held:

Python may be ok-ish for this problem but I don’t think it’s my top choice, and there’s nothing you could say or do that would change my mind.

With me so far? Good. So why is this valuable?

First let’s define the scope of this advice. This is not a way to live your life in general. It’s a way to approach discussions and debates to make them productive. (But note that debates can also be internal; they don’t have to involve other people.)

Let’s start with the easy part: “loosely held.” Don’t be stubborn. Change your mind easily. Otherwise, why would anyone waste their time discussing anything with you?

Now the tougher part: “strong opinions.” Why? Because weak opinions aren’t valuable in a discussion.

Say I believe that “Python is an OK solution.” What’s the point of debating that? There’s no discussion to be had there no matter how loosely held that opinion is. It’s not a productive point of view in a discussion.

But say I believe that “Python is absolutely the best solution.” That’s ripe for a productive debate as long as that opinion is loosely held. Now, you may be saying “so I have to always pretend like my is opinion is strong even if it isn’t?” No, just don’t have a discussion around an opinion unless it’s a strong one.

If opinions were cars, “strong opinions” would be powerful motors. “Loosely held opinions” would be top notch brakes and steering. Be the zoomy car that can stop and turn on a dime. Don’t be the slow moving tank that takes forever to change direction.

I tend to think of things in terms of experiments. We could rephrase “strong opinions, loosely held” as “form a hypothesis and then try to prove it wrong.” It’s the scientific method dumbed down to a catchy sentence. And you can’t argue with science.

(Note, this post came out of a Twitter discussion which came out of an episode of the Not Overthinking podcast.)

Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!


The hero culture conundrum

Tell me if both of these things describe your company:

  1. Managers say overtime is bad and it leads to burnout and “we don’t need heroes” and so on.
  2. Managers say thanks and kudos to people who “go the extra mile” to hit a deadline or sprint commitment

We can’t reward a behavior while also saying that behavior needs to die. “Please don’t do X. Oh, you did X? Awesome, you rock!” What the heck? Pick one!

A new hire sees their tech lead pushing code at midnight and getting thanked for it on standup the next day. They think “oh ok, I guess that’s how you get a good reputation here.” It doesn’t matter how much you tell them “we don’t need heroes” because your culture says you’re lying.

So what’s the solution? Punish the heroes. Do not thank them. Give them negative feedback. Tell them that overtime is only acceptable if team decides it’s necessary.

I know it feels backwards to criticize the people working the hardest. But there are bigger things than deadlines. Deadlines are not the be-all and end-all; culture is. Deadlines are a test of your culture, and you’re failing the test.

If you want to reward someone, reward the new hero. Reward the person who says “the only way to hit this deadline is to work overtime, what do we think about that?” Reward the person who makes overtime unnecessary by simplifying scope or calling out too many sequential tickets in a sprint plan.

These new heroes are the people living your culture instead of speaking it. These are the people that deserve your thanks.

Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!


Parkinson’s Law and friends

Work expands so as to fill the time available for its completion.

Parkinson’s Law

The more I think about it, the more I’m convinced that Parkinson’s Law runs the world.

There are lots of fun corollaries here, such as:

Work complicates to fill the available time.

Parkinson’s Law, but spicier

The work doesn’t just expand, it complicates. And remember that work doesn’t complicate itself, humans have to do that. We are our own worst enemy, as usual.

If you wait until the last minute, it only takes a minute to do.

Stock–Sanford corollary

Said every student ever, amirite?

In ten hours a day you have time to fall twice as far behind your commitments as in five hours a day

Asimov corollary

That one reminds me of the quote “If you want a task done quickly, ask a busy person to do it.”

And as with all good things, Parkinson’s Law applies to computers:

Data expands to fill the space available for storage.

Peter Jansen

But my favorite is this one:

Work contracts to fit in the time we give it.

Horstman’s corollary

The book Critical Chain by Eliyahu Goldratt says we should estimate with 50% certainty instead of 90+%. Say there’s a 50% chance you can get something done in 1 week, and a 90% chance you can get it done in 2 weeks. Go with the 1 week estimate. That’ll prevent the work from expanding to fill the 2 weeks.

Goldratt calls it Student Syndrome. Students wait until the last minute because that triggers a feeling of urgency. They need that urgency to find the motivation to work on it.

When we estimate with 90% certainty, we’re expecting to finish early. But we never do, because of Parkinson’s Law/Student Syndrome. So the buffer we add onto each task gets eaten up, meaning the project doesn’t have any wiggle room. Then all it takes is a delay on a single task to push back the entire critical path, and the project is late.

Estimating with 50% certainty should fix that, according to Goldratt. Instead of adding a buffer to each task, combine all those per-task buffers and shove them at the end of the project. That way delays in tasks don’t push back the project, and Parkinson’s Law can help us instead of strangle us.

The Estimates vs. appetites chapter from the book Shape Up is a neato burrito implementation of this. They say how much time a feature is worth to them (i.e., their “appetite”). The feature expands or contracts to fit that time.

Then there’s Scrum, where Sprints are an answer to Parkinson’s Law. Each Sprint is a deadline, even if we call it a “forecast.” It’s a line in the sand that’s missing from Kanban’s focus on cycle time over velocity. That’s part of why Scrum has been so successful.

Think about the world through the lens of Parkinson’s Law. It’s everywhere.

Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!


Heads Down Tuesday

For the past year, I’ve made every Tuesday a focus day. For me, this means two things:

  • I decline all meeting invites unless it’s an emergency
  • I block Slack except for a few minutes every hour

Tuesday for me is a day for Deep Work. I get more accomplished on Tuesday than the rest of the week put together, and I look forward to it every time.

There’s power in 8 hours of unbroken time. It’s not the same as 4 chunks of 2 hours. And it’s not even close to 8 chunks of 1 hour. I sit down for the day and look at my empty calendar, and I’m ready to take on the world.

In the classic essay “Maker’s Schedule, Manager’s Schedule”, Paul Graham describes this phenomenon:

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

Paul Graham

Heads Down Tuesday is the only solution I’ve been able to find. It’s the only time I’m comfortable starting something ambitious.

As with all good things, there are plenty of reasons not to try it. You don’t want to upset your team (hint: talk to them about it ahead of time). You’re worried something catastrophic will happen while you aren’t looking (hint: give out your cell phone number for actual emergencies). I’m sure you have plenty of other reasons.

But it’s worth a try. Find your least-meeting-heavy day and pitch it as an experimental focus day to your team. And if you do, report back!

Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!


Failing with abandon

I came across the phrase “failing with abandon” last week and it was a swift and ruthless kick in the pants.

Say you’re trying to eat no more than 2000 calories per day, and then you eat 2300 by the end of dinner, you don’t have to say “well I already missed my target, so I might as well indulge.”

Over and over, I see people set themselves a target, miss it by a little, and then throw all restraint to the wind. “Well,” they seem to think, “willpower has failed me; I might as well over-indulge.” I call this pattern “failing with abandon.”

Nate Soares

In my personal life, I see this everywhere. I fail with abandon like I’m getting paid for it, hence the kick in the pants upon hearing a name for it.

But it’s not a problem at all at work. If I miss a deadline, I don’t say “oh well, it’s already late so I’ll take my time!” I get it done as soon after the deadline as I can.

So what’s the difference? Why do I fail personal goals with abandon but not work goals? The difference is that I fail with abandon on goals that only I care about. When I overeat, I’m the only person who suffers. But my coworkers and managers suffer from me missing deadlines.

Sure, there’s power in having someone watching over my shoulder. This is why accountabilibuddies are a thing. But that’s not enough. The real power comes from having someone else’s success depend on mine.

Failing with abandon is too easy when only I am invested. But how can I get other people invested in my diet and exercise? I don’t know, but that seems like a question worth pondering.

Any suggestions?

Thanks for reading! Subscribe via email or RSS, or follow me on Twitter!


Thanking random internet people

As one of my weekly experiments, I’ve been thanking people on the internet. Usually they wrote a blog post that I liked or posted some code on Stack Overflow that I copied. I’ve been tracking down their Twitter handle or email address and sending them a little note.

About half of them have responded back so far. Here are some of the responses I’ve gotten:

This one even retweeted it. ♥️

When I posted that I was thinking about doing this, someone read it and emailed me this:

I can confirm for you in advance that making a habit of thank you’s will boost your reputation for good-naturedness… precisely by transforming you into someone who notices opportunities for gratitude.

So far, I have not found that to be true. I’ve had to set a daily reminder at 4pm to thank someone, otherwise I’d forget. I haven’t been noticing opportunities for gratitude any more than before. But it might be too soon; I only started too weeks ago.

I’m going to keep this going a while longer and see if I notice any changes. In the meantime, at least it feels good when they reply so I know they got my note and felt appreciated for a bit.