I've said before that staff engineers should be thinking at least a year ahead. Managers should too. In fact, anyone who's senior should have a robust belief in the future.
Believing in the future may sound obvious, but it's easy to forget in fast-moving software engineering teams. Sure, we make our roadmaps and we define our Objectives and Key Results. But when it comes to planning ahead, we're more likely to talk about what we want to do next than what we'll look back in hindsight and wish we'd done. While a lot of our project work requires us to put on our product manager hats and put ourselves into the minds of our customers, there's another stakeholder we should consider: we need to put ourselves into the minds of our future selves.
Future people are real people
Life’s busy. It’s easy to focus on what’s happening right now. It can be hard to see past the problem we’re currently solving, the shiny idea we’re exploring, and the current big push towards the current big goal. But a year from now we will (hopefully) still exist and we'll still have goals and motivations. We think of a year as a long time, but the small decisions we make now – or the decisions we avoid making – will still have consequences then.
I think this is where a lot of the bad kinds of technical debt comes from: we don’t really internalize that the future people who will need to deal with our choices are real people who will be mad at us for sending this stuff to them. Our future teams – and our future selves – will have their own problems, their own new ideas, and their own exciting initiatives that we can’t even imagine yet. They won’t want to have to think about the messy parts of our projects that we’re avoiding dealing with. But often that’s what we send them.
Sending gifts into the future
What if, instead of sending them our problems, we sent small but thoughtful gifts?
Imagine how delighted future-you would be to receive a beautifully-wrapped little package that contains something they need – like deprecation dates. Teams sometimes avoid announcing deprecation dates for old systems, even if they know the systems aren’t sustainable. A common objection is something like, ‘It would take us a year to move everyone off this system, and we’re not ready to start the migration yet.’ But we know that a year from now, future-us will still want to be rid of the system. If we announce now that we’re planning to turn it off in 18 months, other teams will know not to invest in it. New projects will know not to use it. Some teams may find themselves with free time and will move to the new system without you even asking them. It’s worth a small amount of work now to set people’s expectations and make the future deprecation project a little easier.
This year’s gift guide
Your future self and future team’s needs may come in many forms. Deprecation dates are just one of the ways we can help those schmucks out. Here are some others:
- Will your team need expertise in some technology in a year? Sure, maybe you’ll be able to hire an industry expert between now and then. But just in case you’re not, start one of your team off on the path to becoming that expert now.
- Will future-you wish you’d announced some key decision, recommended a best practice, or otherwise made some future migration project a bit more tractable? Take the time to do that.
- Do you wish you were able to create a graph of how some value has changed over the last three years? Might you wish the same thing in another three years? Start collecting the metrics now.
- Are there problems that get a little worse every quarter but aren’t yet actually on fire? Get those on your roadmap now. Let yourself fix them under controlled circumstances, rather than in a massive panic as you get near a due date or a scaling cliff.
- Did you figure out how to do something that's complicated and that you won't need to do again for two years? Write down every detail as if you're explaining it to someone who has no idea what you're talking about. Because you may well be that person!
- Will future-you want to get a bunch of busy people into a meeting for a couple of hours, or even a one-day summit? Block out some time in their calendars now, even if it’s months or quarters away and you aren’t sure yet what your agenda is.
You signed me up for WHAT?
Sending future-you a gift (or a “gift”) is a good way to force yourself to do something scary too. It’s how I started conference speaking: I sent in a proposal for a talk, and told myself that even if they accepted (they did) I could still decline the invitation (I didn’t). Then, I convinced myself that the conference was far enough in the future that I’d figure out how to not be scared by the time I got there (haha nope). When the day got close, you better believe I was terrified, but by the time future-me became present-me, I was at least used to the idea. At that point, I didn’t have a lot of choice but to go ahead. And it went well!
I’ve taken sabbaticals like this too. It’s never easy to take time off in the near future – there are projects in flight and things that are hard to drop. But I have twice sent a sabbatical to my future self by booking the leave for eight months in the future and letting future-me figure out what to do with it.
I take this approach to vacation days now too. Looking ahead at the next two weeks, it will always be impossible to find a day with no interviews or big project meetings. My calendar’s calmer a few weeks out though, so I block out vacation days in the next month, without any real plan for what to do with them. I can decide whether to use them or delete them as I get closer to the time.
Whatever it is you think future-you will need, plan to get it to them. A year from now, your team, your org, and your own future self will have something they'll wish you’d done now. Think ahead and get the gift in the mail so that when you arrive there, you’ll thank your past self for being so thoughtful.