Planning for Unplanned Work in Linear | Hacker News Reader

Planning for Unplanned Work in Linear

linear.app

> Unplanned work happens unexpectedly, but it’s not unexpected. You know that there will be bug reports, you just don’t know when, where, and in what shape they will come up. The only thing that is certain is that they will appear.

I am tempted, half tongue-in-cheek, to suggest simply scheduling it:

    09:00-09:30 get coffee and morning standup
    09:30-11:30 work on project A
    11:30-12:30 lunch
    12:30-14:00 deal with the emergency of the day
    14:00-17:00 work on project B

And for all that that's exaggerated for humorous effect, I actually have played with scheduling blocks of time for catching up on Slack messages, which is pretty similar really.

I work with a team from PT->CET and am in UTC-0 so no joke the first thirty minutes to an hour of my day is catching up with the rest of what happened the previous day and what’s going on at the start of the next day. I don’t need to schedule it because thankfully my morning is usually quiet but it’s common enough I mention it in my work log.

I don’t think this is unplanned work so much as unrecognised work. Few Gantt charts etc. keep track of that overhead like the overhead from ‘surprise’ tasks.

I love multi timezone teams because it forces everyone to work asynchronous. I find those environments to be really relaxing and flexible.

To an extent, for me at least I get a great block in the morning to early afternoon then a lot of meetings that are mostly 1:1s with direct reports and strategy/planning clustered around PT morning and my evening. I like that though but it’s a struggle to not be brain dead especially with people freshly awake and full of coffee.

If your company is sensible. Some mandate "core working hours" based on the HQ, and meetings around the clock.

Why is this exaggerated or humorous? That's literally what I do. Works great.

Same here. And I put in my calendar to make it obvious to others that it's there. I used to put in in the issue-tracker, too, but lately our team manager started reducing the "normal" expected story points to a level that reflects the time left in the iteration after the average amount of "unplanned" work is considered, which also works.

I guess the joke is that I would have liked to imagine that I didn't have an emergency a day like clockwork. Let me keep my fantasies;)

I always hear these 9 to 5 references about working time.

As someone in Europe where lunch break doesn’t count as working time, this would amount to 7 work hours. Here the norm is 8 hours.

Does lunch break in the USA counts as working, or you typically work 7 hour days?

Depends, but traditionally in the USA white-collar jobs are 9-5 with time for lunch.

I kind of like the article take on how to handle emergent issues, but I don't like that it still sort of silos software development into two parts -- planned and unplanned.

I hate the term "unplanned" to describe this kind of work. By using a very narrow definition of "plan", for work "organized and scheduled in advance" but only within projects and roadmaps, it sort of works. A more informal usage of unplanned, though, suggests a kind of blindness to the reality of software development and maintenance.

The reality is that the effort in software development isn't easily divided into these streams. The article fails to address an important consequence of putting effort into fighting fires: the project plans and roadmaps of the affected teams will be disrupted. This is where the term "unplanned" really fails, because if the organization never takes into account the effort taken to address issues and emergencies, the plans are worse than having no plan at all.

On a different note, one place I consulted with had its planning and tracking tool (Jira-like Azure DevOps) directly feed into its accounting system, such that different types of work were bucketed into different amortization flows. Planned work was a capital expenditure (CapEx), while anything funneled into Unplanned became an operating expenditure (OpEx). Any accountant that knows the implications of CapEx vs. OpEx can see where this is going. This company had a lot of bugs and issues that were left unaddressed.

> The reality is that the effort in software development isn't easily divided into these streams. The article fails to address an important consequence of putting effort into fighting fires: the project plans and roadmaps of the affected teams will be disrupted. This is where the term "unplanned" really fails, because if the organization never takes into account the effort taken to address issues and emergencies, the plans are worse than having no plan at all.

The article likely glosses over these particular details because it's a sales pitch for an app that offers a, seemingly, smooth flow to get "unplanned" work into the "plan." The "plan" just being the ticketing system where work-to-be-performed is assigned, not the roadmap.

You're not wrong that "unplanned work", of any form, can disrupt your timelines. And that why the features they are describing, that are separate from the assigned work, are important. They require someone to explicitly acknowledge and accept the costs of that work before adding it to the "plan."

That said, your roadmap, like it's analogous counterpart, generally won't be that specific. It's just there to layout the direction and highlight important landmarks. You don't use the roadmap to draw every gas stop or who is driving each stretch of road on the road map because it's hard to anticipate those details and expensive to update when things go awry. And even if you try, sometimes you just want to take a detour and see the Largest Ball of Yarn because you need to stretch your legs and it's only a few miles out of the way. Your roadmap shouldn't care about any of that, it's just there to help you get back on track when you're done.

But once you get to the car, you make a plan. You decide who is going to drive first and how far you expect to go. And you can change that plan when the fuel tank doesn't get you as far as you thought, or a poor night's sleep catches up with you sooner than expected, or there's a rock shop on the side of the road, because you can ask the other people in the car whether its worth arriving a little later to look at some cool rocks.

Usually it's the largest ball of twine.

You can see the Largest Ball of Twine from the road, so you never get to actually stretch your legs, which was the whole point, and your detour ends up being a waste of time that contributes nothing to the endeavor.

That seems familiar enough I feel like it might also be a great analogy for something, but now I'm sore, disappointed, and behind schedule, so I'm just going to drop it and bunker down to finish this as quickly as possible.

> On a different note, one place I consulted with had its planning and tracking tool (Jira-like Azure DevOps) directly feed into its accounting system, such that different types of work were bucketed into different amortization flows. Planned work was a capital expenditure (CapEx), while anything funneled into Unplanned became an operating expenditure (OpEx). Any accountant that knows the implications of CapEx vs. OpEx can see where this is going. This company had a lot of bugs and issues that were left unaddressed.

Same experience where I work. Not perhaps "directly fed" to the accounting, but something similar. Basically: someone somewhere needs to know how many hours were CapEx and how many were OpEx. The division between planned work and unplanned work is a crude way of doing that. It's not perfect, but I do prefer that division over having to report hour by hour whether I did cap/op-ex work. The only problem I see with it is if this creates pressure on either a) creatively marking work as one type or the other or b) prioritizing incorrectly due to on this. Those are real problems (luckily I have not seen that where I work). But the division itself seems like as good a method as any.

> The only problem I see with it is if this creates pressure on either a) creatively marking work as one type or the other or b) prioritizing incorrectly due to on this.

This pressure is inexorable. With the wrong incentives, anything that falls under OpEx will be discouraged.

Put whatever unexpected work comes up into a general inbox somewhere, without preprocessing it (i.e. without figuring the next steps). Then periodically process what's in the inbox (figuring out the next steps and scheduling them), once a day, once a week, whatever. Also, buffer for unexpected stuff in your deadlines, in my work it's generally 40%.

Sounds like the GTD approach. Works well for me too!

They had to call it an "Ask" :(

Has anyone here used Linear? Looks interesting

Been using it at work for a bit over a year now. It's great, very lean, snappy. They're deliverying features at crazy speed too. A breath of fresh air after having had to use Jira for way too long. Can highly recommend.

I've been using it at my job for about a year now. It's pretty decent. Their support team is also highly active on Slack, so if you run into any trouble, they will help you resolve it right away

I use it. It's ok. Slick, simple, gets the job done.

After wading through the molasses that is Jira, Linear is very good. Very fast and snappy though not as extensible and configurable as Jira of course

Started using it a few months ago. It’s a normal issue tracker feature-wise. Doesn’t seem to reinvent the wheel, functionally. Where it shines is in UX: crazy fast and snappy, great layouts, keyboard shortcuts, look and feel, etc. I’m at a point where I go “ugh” if I have to use anything else.

Yes - I don't hate it.

...which is literally the highest praise I have ever given and probably ever will to issue-management software. They correctly realize that we mainly want to not notice the software, which is something that every competitor gets wrong.

What I can't figure out is how they possibly got funding in the reddest of red oceans with a pitch that couldn't have been much more than "we'll make Jira but not suck" (that's essentially all it is), but I'm glad they did.

Jira sucks a lot so this is understandable

Same.

My biggest complaint is that they don't believe in email notifications. They have a very basic "catch up digest" but it comes in very slow and doesn't appear at all of you happen to look at Linear at the wrong time (because you are "active" and so clearly don't want a notification). So it is easy to miss stuff unless you are constantly checking their inbox.

It also has a bit too much structure with projects/tasks/subtasks which I find is less useful then just dependencies as you often want to break up a subtask but it doesn't really support that. But it does have raw dependencies so you can just use those even if they are quite basic.

But overall it is fine. Which is also the best thing I've ever said about an issue manager.

Yep, using it for my small software company. We used Jira before, and while we had a halfway decent config so it didn't suck too badly, Linear is just light years ahead in terms of usability. I take a lot of inspiration from how they approach software.

There are some drawbacks. Linear is highly opinionated about some stuff. I happen to think most of their opinions are sensible, so that doesn't bother me, but it's explicitly not a general purpose replacement for Jira.

I'm pretty impressed with their new developments. This article shows they are thinking about issue tracking from first principles, which is helpful. This triage thing is definitely something we've been struggling with, and something that most other issue trackers do not deal with well at all. We've been a customer for about a year now, and we're constantly seeing steady improvements. Recently upgraded to the top tier package, and I had a minor scare because I did not realize it was going to be billed annually (it mentioned a monthly price with 'billed annually' under it but my brain wasn't braining very well when I clicked upgrade), so I sent an e-mail asking about it, and they got back to me quickly, with a proper in-depth, human sounding response. I just love being in contact with an actual human, and not feeling like a number in an arbitrary system, even though given their scale I must be.

So two thumbs up from me.

Been a customer for 3 years. Easily the best ticketing software I've used, particularly day to day as an engineer. As a manager I found it lacking some higher level planning tools, but they've been putting a lot of effort in. As a sibling said usually the defaults are sensible. I could in theory do more things with JIRA, but that assumes my org configured my instance in a way I like, I can find the customization, or not get entirely turned off by waiting for page loads.

They have been incredibly focused on improving the product in ways that are visible and get uptake from me immediately. Its one of the few pieces of software where I want to read the release notes everytime.

If I worked at a shop with less than 200 employees, its the no brainer choice.

How does it compare with Height or Shortcut?

Hi. Ty for the article and responses. Is there a similar open source, transparent, and modifiable tool using things like git or emacs org mode? Please don't flame the noob.

Absolutely nothing in this actually covered how to plan for unplanned work. While yes becoming aware of issues quicker and preventing things from falling through the cracks is great and all, it's still strictly post hoc. "Dealing with unplanned work" would be a better title.

Reply on news.ycombinator.com