Urgency vs. Importance

I’m getting used to a new engineering team and frankly, they’re getting used to me too. This isn’t a bad process. It’s really actually enjoyable, for a lot of different reasons, but chief among them is reconsidering your mode of working, your biases and your opinions. There are junior engineers and senior engineers and project managers and engineering managers and dozens of temperaments and personalities; each member of this team is in this room for a reason, they bring some unique value to the team.

One thing about this process I find really interesting is that reconsidering your biases and values can often make you an apologist for your own beliefs.

Among those beliefs is this question that I keep wanting a clearer answer to: What makes us ship well?

By well I mean, fulfills the business requirements with eyes on what the product team might want to commission the engineering team to do in later sprints (be it two sprints away or 6 months away).

I have lots of biases at this point, like React is going to be the best framework for building UI or that TypeScript is best tool out there when you need to write JavaScript, and I’m more than confident in using GraphQL to empower the front-end to build applications versus using microservices through just fetch requests alone.

Those are all technology specific. Those are good defaults to be debated and rehashed. But there are biases past just technology choices, there are also beliefs about what makes engineers productive. Through our collective experiences they help us answer the question: “what makes us ship and ship well?”

My experience working in a lot of different organizations is there’s some really thoughtfully considered iteration or lawless deviation from an agile process, in which engineers review features and bugs, assign time and cost, then commit to those tasks in a given timeframe (usually about two weeks). That’s one bias, deciding how to cost and assign value to those tasks. But when you commit to that body of work with your team, you make a lot of choices about what’s important and what’s urgent.

You’re making a clear cut choice on what’s important and out of that come other tasks, like side projects and so-called “background” tasks. Suddenly you’re inundated with stuff to do. Then your work becomes contingent on someone else; you’re blocked so you go pick up something else to do or go on Twitter. Or the inverse, someone else’s work is contingent on you. And if neither of those things happens, the third case, which is by far my favorite, occurs, you pick up one of those “background” tasks and you get pretty far on it and now you’re putting off other important things because the side thing took up your focus and it started to be really interesting or really valuable.

Some urgency and immediacy comes with blocking someone else. Pouring time you may not have into something you care about at the expense of those other things puts them at risk on missing your deadline. Being idle due to someone else is just as bad; it’s like waiting for the grass to grow and being ready to be handed a rubix cube to solve that’s on fire.

Suddenly, things aren’t just important, they’re urgent. There’s more demand, there’s more pressure. One of the hard things I’ve had to learn is just because something is important, doesn’t mean it comes with the pre-qualification of also being urgent.

If I look at the tickets I’m assigned right now, they’re all important, arguably it’s the business justification for paying me to code. But building a codebase that’s still easy to work on 6 months from now is also important and so is working in abstractions that are easy to share between teams, mentoring junior engineers is important and explaining to director levels why we’re making certain tech choices is important. But looking at that slate, not all of them are urgent. Right now I’m blocked on a ticket, that doesn’t make it more urgent or less important.

It’s my experience and it informs my conviction: urgency and importance are too often conflated when you’re building things and especially when you’re trying to build things well.

Someone else’s fire doesn’t make it urgent for you and in that process, they’ll re-gift you their anxiety to involve you in attempt to pour their fire. Their problem is important, it just doesn’t have to be solved this minute.

Give yourself the beautiful gift of having real value over what’s important and

Also, if the environment you work in is a vicious game of white elephant, trading urgent requests and problems that don’t involve you initially; quit. Right now.

So to answer my original questions, we ship well when we meet the requirements and deliver the features we’re asked to build. We ship well when we have a collective understanding of what’s important as a team and an organization. Lots of things are important, most things are on some level, but they’re not urgent.