3 ms·

Nice read. As a sysadmin / DevOps / SRE / whatever, I also realized at some point that being constantly busy is actually a state of extreme fragility. Nowaday

Nice read. As a sysadmin / DevOps / SRE / whatever, I also realized at some point that being constantly busy is actually a state of extreme fragility. Nowadays I try spending a significant part of my day just trying new stuff and reading, not being micromanaged helps a lot.

hinkley 5y ago
I did some refactoring work a few months ago, replacing the old way we did something with the new. I didn’t have to do it, I could have punted like the creator did. But I was used to the new thing and I wasn’t about to write new code that was already deprecated. Nobody called me out on it but it wouldn’t have been the first time in my career. But now I find out belatedly that we’re changing our auth system, and now that work is going to save me from having to drop everything to get it done on time.
- loopz 5y ago
  If there's something you feel you can do, it'd be good, you absolutely should investigate that path. If it turns out it didn't work out, someone stomped on it or you get pulled elsewhere, it wasn't meant to be. You feeling that goal within your grasp, is anyways valuable as learning exercise. No matter your efforts, there's a time for everything.
tetha 5y ago
I was about to write that. This is very visible in operational teams. Depending on what is going on, an operational team will spend 20 - 40% of their time firefighting or at tightening screws and oiling wheels - maintaining systems. Sometimes it's a good week and it's just 10%. Sometimes you launched a new product, and it's 60% because everything is failing. As a conclusion from there, it's not a good idea to schedule more than 50% - 60% of deliverables with deadlines, because the right outage is going to toss those estimates really quickly. That's in itself the definition of sufficient slack. If you don't have that, prod fails and no one is around to fix it. If you do, someone can usually start poking at it quickly.
- antod 5y ago
  Yup. I always liked to have my team (been in the infra/ops/sre/devops/sysadmin areas) focussed on latency rather than throughput by having slack. Luckily we've usually been able to avoid Scrum etc, and work in a way closer to Kanban. There have been times though (like right now sigh) where we're forced into a throughput oriented mode by commitments made elsewhere out of our control. It sucks, and we end up ignoring too much of the little stuff for long enough that they end up becoming fires you need to put out (is ops debt a thing?), your tooling and automation suffer, knowledge silos build up within the team, and the throughput will end up tanking anyway. I like to use 50% allocation on "project" work as a nice rule of thumb for reactive ops oriented teams. Any higher can only be sustained for short periods without negative effects. This article resonated with me pretty deeply.

hinkley 5y ago

I did some refactoring work a few months ago, replacing the old way we did something with the new. I didn’t have to do it, I could have punted like the creator did. But I was used to the new thing and I wasn’t about to write new code that was already deprecated. Nobody called me out on it but it wouldn’t have been the first time in my career. But now I find out belatedly that we’re changing our auth system, and now that work is going to save me from having to drop everything to get it done on time.

loopz 5y ago
If there's something you feel you can do, it'd be good, you absolutely should investigate that path. If it turns out it didn't work out, someone stomped on it or you get pulled elsewhere, it wasn't meant to be. You feeling that goal within your grasp, is anyways valuable as learning exercise. No matter your efforts, there's a time for everything.

tetha 5y ago

I was about to write that. This is very visible in operational teams. Depending on what is going on, an operational team will spend 20 - 40% of their time firefighting or at tightening screws and oiling wheels - maintaining systems. Sometimes it's a good week and it's just 10%. Sometimes you launched a new product, and it's 60% because everything is failing. As a conclusion from there, it's not a good idea to schedule more than 50% - 60% of deliverables with deadlines, because the right outage is going to toss those estimates really quickly. That's in itself the definition of sufficient slack. If you don't have that, prod fails and no one is around to fix it. If you do, someone can usually start poking at it quickly.

antod 5y ago
Yup. I always liked to have my team (been in the infra/ops/sre/devops/sysadmin areas) focussed on latency rather than throughput by having slack. Luckily we've usually been able to avoid Scrum etc, and work in a way closer to Kanban. There have been times though (like right now sigh) where we're forced into a throughput oriented mode by commitments made elsewhere out of our control. It sucks, and we end up ignoring too much of the little stuff for long enough that they end up becoming fires you need to put out (is ops debt a thing?), your tooling and automation suffer, knowledge silos build up within the team, and the throughput will end up tanking anyway. I like to use 50% allocation on "project" work as a nice rule of thumb for reactive ops oriented teams. Any higher can only be sustained for short periods without negative effects. This article resonated with me pretty deeply.