Something that I've noticed recently is that in my work life, I'm finding there's more bureaucracy in what I do, mostly in the name of "efficiency". When you encounter a problem to solve, there's often a process already defined that is most efficient (or at least thought to be most efficient), when accomplishing tasks, there's a pre-defined way of laying out the tasks (i.e. tickets), updating them, reviewing them, and organizationally figuring out what's best to do next.
In my opinion, these processes are an attempt at organizational efficiency. However, the flip side is it reduces personal agency for the worker. There's little room to diverge or think about what you're doing. If you diverge, such as taking longer to do something than what was prescribed, or using a different pattern to solve a problem, there is a cost to you within the system. You must explain why, which itself "costs" something. In a sense, you're punished for doing things differently.
That loss of personal agency is absolutely soul-sucking. You feel like a machine, again at the cost of organizational efficiency. Slack is definitely important because it lets people acquire some sense of personal agency again.
The thing that kills me about the ticketing systems is that they are often put into place in a way that is locally efficient but does not make sense globally.
For example, an application owner might have to submit a ticket to request an upgrade once a year (or when a new OS is supported). What often happens is that the application owner now has to know about, find, and correctly understand a form that they see once (or less) per year. That work has been offloaded from a single team (measurable impact to efficiency) to immeasurable shadow work for others in the organization. A form that would take 1 minute of effort from the team that runs the upgrade to fill out and track, because they are in it all day, ends up taking a half hour, cut across multiple starts and stops due to other similar interruptions.
This becomes pervasive (book your own travel with this system, book your own PTO here, track your time here, fill out tickets for this system, use the help desk ticketing system to request an application installation) and ends up eating a huge chunk of employee time doing unfamiliar overhead tasks on systems optimized for the team doing the work and not the customer. I think we are getting to the point where all of the systems that were designed to take away the need for administrative assistants may once again require an assistant to navigate efficiently.
A lot of medium-to-large organizations used to have dedicated administrative staff, not just for senior management, but for everyone. It was good because the people in the admin pools were experts at navigating the organizational structures. They did it every day, all the time, for everyone, so they knew the tricks.
In the interest of cutting labor costs, those jobs were cut, and self-service systems like the ones you describe became the standard.
I've been around long enough to remember a time when, if I needed to travel for work, someone made all the arrangements, and just handed me tickets and an itinerary. I was really junior at the time, it was just how travel was done.
Now I'm pretty senior, but not senior enough to have my own assistant. I get paid a lot more, too. But employers seem to think it's more efficient for me to spend a day figuring out the corporate travel portal to plan and book my trip than to pay an expert to get it done in an hour or so.
The culture of "self-service" in companies is more like the culture of "self-waste". What just used to take a single e-mail earlier now takes navigating a plethora of half-broken apps, sites, wikis and issue-trackers - all done in the name of cost, process and 'metrics'.
Use Jira, make your own bookings (etc), and submit reimbursement requests or have an assistant and earn quite a bit less... hmmm.
> all of the systems that were designed to take away the need for administrative assistants may once again require an assistant to navigate efficiently
Made me laugh. My org has a completely automated online self-service travel booking system that even includes dedicated support from a corporate travel agent - and I recently needed a single flight booked for a day in another city (about the simplest travel you can do) and somebody "loaned" me their PA to do the booking because it takes much time and knowledge to do it right. Part of the problem is that the org has implemented a gigantic set of strict rules about what kinds of flights can be booked to save money. So it can be quite hard to select the right flight that won't get knocked back further downstream or alternatively navigate through the forms to justify why you aren't selecting a compliant flight...
Is there a term for the organizational autoimmune disorder where the cost of fighting inefficiency (or, in the case of governments, fraud) is significantly greater than the amount that would be lost without such policies?
I wonder how much the company would save if they just gave you a budget for the trip and let you make the arrangements yourself on your own time and keep the difference.
I trusted Amazon to book me a simple flight for an interview and I wound up with the absolute worst seat on the plane. The only thing that saved my 6'2" frame from being crushed into a corner was the kindness of a stranger who gave me their seat on the aisle. I know I can do better on my own!
It is exactly the extra rules, inevitably poorly communicated, that aren't hard coded into the form that make these anxiety inducing to navigate.
I am here, procrastinating on one form right now. I have left myself this week to get to stage one( of three).
Great insight! It literally happened in my company where the system to order physical goods is so complicated and ugly. Now a secretary handles feeding and tracking requests in this system.
BTW our time tracking tool is a company wide motivation killer that costed 300kā¬ and does not auto-fill holidays.
>BTW our time tracking tool is a company wide motivation killer
HINT: They all are.
> the systems that were designed to take away the need for administrative assistants may once again require an assistant to navigate efficiently
This is something that I've lamented over too. Infrequent interactions and setups take so long to do, the people who do it every day don't see a problem because it's easy but it's not a core competency for the rest of us. We need a community liaison role in internal teams that we can reach out to for a guiding hand. No, our sales staff don't know how to fill out your form about getting a new mail subdomain set up, no matter how easy they'll get something wrong and waste your time anyway. Why not walk them through it?
Iāve been bumped into SLA hell when incorrectly filling out a form as well.
Go fill the form to make the request - itās got a 3 day SLA so it shouldnāt be a problem. Day 3 - form rejected due to missing a small detail / something they could call me about. Day 4 - I see the notice the form is rejected and either a) have to resubmit and wait 3 more days or b) escalate because now this is an emergency.
A company I worked at was aquired by another company. The new management team talked almost exclusively about tickets and metrics that came from tickets.
They knew almost nothing else, if you spoke to them they seemed confused if you didn't describe how it related to tickets.
It was weird.
A few months into the new company there was an emergency meeting. It was found that the ticket metrics were horribly wrong. They showed that a handful of yokels from the Midwest were closing ticktes faster than the folks in Silicon Valley...and worse they were staying closed and customer's were reporting more positive feedback, just didn't make sense.
So they ticket obsessed valley folks declared the guys from the new company must be creating fake tickets and otherwise messing with the numbers!
After months of accusations they got someone from the outside to investigate. They found there were widespread fake tickets and other shenanigans....
Everyone up to shenanigans worked for the ticket obsessed valley based managers.... all the folks who made the accusations.
They had driven their teams so hard that the employees just played the only game the management responded to, closing tickets....
The resolution? They declared the old metrics bad, reorganized the teams so management had some valley and some midwestern employees so that the pockets of ticket shenanigans wasn't as obvious.
Otherwise nothing changed. The ticket mania continued.
"When a measure becomes a target, it ceases to be a good measure."
I recently heard a clever man argue (canāt remember who), that process does make things more efficient. Starting at chaos, the more things are defined, the more you get done.
Until it doesnāt, at which point the relation inverts and you eventually end up stagnant.
The problem is that because adding ever more processes worked so far, and now that youāve hired process people, you continue adding more and more and ever more.
The process machine feeds itself.
I heard Jim Keller (the chip-designer) say this (or something similar) recently in a podcast with Lex Fridman.
It is at the 24.40 mark in "Jim Keller: The Future of Computing, AI, Life, and Consciousness | Lex Fridman Podcast"
https://youtu.be/G4hL5Om4IJ4?t=1480
"So there is a graph. Y-axis is productivity. X-axis at 0 is chaos and infinity is complete order. As you improve order, you increase productivity. And at some point productivity peaks, and it goes down again. Too much order -- Nothing can happen... Once you start moving towards order, the force vector that drives you towards order is unstoppable."
Yes. At complete chaos you can't see the world, because of information overload. And with complete order, you're no longer acting in response to the world. You're only acting in response to the order you've created. (In practice, models, metrics and beliefs). And at some point that can become self reinforcing if you don't ground your choices out by talking to real humans in the real world.
This happens all the time with ideology. If you get too steeped in any particular ideology, you no longer react to the world. You're only reacting to the ideology. (Or the world framed through the ideology). You see this all the time in the blockchain world. So much effort is going into making software and tools that nobody outside of the blockchain world wants or cares about; because it only makes sense from the perspective of other blockchain stuff. And of course, it happens all the time with twitter style politics.
"We have a problem! How do I solve it?" "Make the metrics go up! Use a blockchain! Acknowledge your privilege!" "Wait! I haven't told you what my problem is yet!"
There's a great quote from Bill Clinton: "The problem with any ideology is that it gives the answer before you look at the evidence."
I would extend your point to say that any system with infinite chaos or infinite order necessarily lacks information about the world. Any system encoding information about reality necessarily looks like a mix of chaos and order. Unfortunately, any system that perfectly encodes / decodes information about reality has to be more complicated than reality itself.
Holy Molly, loved this point of view, really makes sense.
Ty for the reference :)
that process does make things more efficient.
In my experience, process is to make things predictable, not efficient. Nothing scares a middle manager more than having to say "I don't know". They'd much rather say "this will take my team 8 months" than "this will take between 3 weeks and 6 months to complete".
I suspect one of the reasons things become more predictable is that overheads start to dominate the time it takes to do things, and overheads seems to be much more predictable.
The Goal is one of my favorite ābusinessā book (itās written as a novel). it addresses all of the wasted energy when you target efficiency at the expense of hitting your true goals.
A truly efficient process would be a bullet in the head at birth bypassing everything else. So yeah, goals aside from efficiency are important.
Now some efficiency expert is thinking about how we can skip the bullet to save money.
Yep The Goal is absolutely brilliant. I have read it 3 times and will read it again.
And this is why you schedule flights in the morning: there's so damn little slack in the system that if things go wrong at 10:00 AM at O'Hare, flights for the whole rest of the day are screwed up owing to the cascading delays.
At least in the morning the airlines have had the overnight to unsnarl the previous day's mess because of the reduced revenue traffic overnight and the corresponding slack that accrues as a happy side effect.
This is also why things like the healthcare system, transportation network, and postal system shouldn't be run for maximum utilization/efficiency under normal load: if there isn't any slack in the system it gets real ugly when things get squirrelly. In cases of localized disturbance, we get by on mutual aid: linemen and bucket trucks from far away respond in the aftermath of e.g. a hurricane or tornado. Likewise, fire departments from all over The greater Boston area responded to the gas explosions in the Merrimack Valley[0] and companies from even further away repositioned trucks to cover the departments that responded directly.
When it's national or global scale event, you're left leaning on whatever slack was in the system. As we're all painfully aware, there hasn't been enough. The public health and healthcare systems have been doing heroic work, but if they weren't stretched so tight in the name of efficiency beforehand, there'd be less need for the heroic efforts.
[0] https://en.wikipedia.org/wiki/Merrimack_Valley_gas_explosion...
> This is also why things like the healthcare system, transportation network, and postal system shouldn't be run for maximum utilization/efficiency under normal load: if there isn't any slack in the system it gets real ugly when things get squirrelly.
A couple years before the pandemic, the counties neighboring mine (where I lived at the time) cut out most public medical services (mind you, these aren't free, just publicly funded, people still paid for them). There wasn't enough money for a private hospital to bother so this was a critical piece of infrastructure. They kept emergency and urgent care clinics in each county, but directed people to the other (more populated, higher income) counties like mine for many services. Last year was not a good year for those counties as people were now being shuttled 40+ miles if they needed to be treated (at a hospital) for COVID.
Lean means cutting the fat, not the meat. They didn't just cut the fat and meat, they cut to the bone. This is when organizations find themselves in trouble and fail their clients/customers: eliminating things they don't think they need because they're "underutilized", only to discover later there was a sound reason to have that capability to begin with.
> Lean means cutting the fat, not the meat. They didn't just cut the fat and meat, they cut to the bone.
I will upvote you just for coming up with this illustration. This should be useful for future reference.
Shortly before the Covid-19 pandemic, a highly-influential think tank (the Bertelsmann-Stiftung) suggested closing half of Germany's hospitals because of the low bed utilization and simple inefficiencies that pop up when smaller hospitals deal with less-common cases.
That plan has now been effectively scrapped. The large number of ICU beds per capita has been one of the main reasons why Germany got so well through the first wave. The plan also overlooked that the main bottleneck has always been staff, who were already running with very low slack.
Yep, I started my programming career optimizing stuff (traveling salesmen, roster, schedules) and the optimizing criteria in academia is very far from reality. The effects of not having slack are disastrous.
Although, the effects start showing after the optimization makes people believe they can squeeze even more work. The initial optimized schedules create more slack than handcrafted ones.
The problem imho is that most places want to shed the freed labor rather than redistribute the load. Just slowing hiring a little adds burden.
Been seeing this with UPS after the Texas snow storm. Packages were canceled or delivered late, often missing parts of it, for over a month. It's an obvious problem with homebuilders, too. I keep seeing all these constructions just halt all work, sometimes for a few weeks or months, sometimes for a couple years. They seem to operate with absolutely no margin for error and run out of money really easily.
We've replaced secretaries with software, and now we have people making $150k+ a year busy working on things that they should be paying someone $40k a year to handle.
And the same happened to everyone else too, just with smaller dollar amounts.
During my high school and early university years, I was in love with the concept of being able to run errands over the Internet. Why go to the bank when I can order a transfer on-line? Why make orders over the phone when I can choose what I want on a webpage with few clicks? Why ask anyone to do anything, when I could just click or type my way through?
As an adult with a bit more years behind me, I now feel the exact opposite way. Why on Earth am I doing these errands, when I could ask or pay someone else to do them? Why do I waste my time clicking on this bloated, user-hostile page full of upselling garbage, when I could just phone the company and tell them what I need? Alas, companies jumped at the opportunity to outsource the effort to customers, so increasingly I can't phone anyone. Self-service becomes the only option.
I suppose the shift in perspective comes from the fact that back then, I had no money and a lot of time; these days, I have some disposable income, but very little time to spare.
To me, the web page nearly is always faster than asking a human. Even setting aside the phone trees designed to slow me down, I'm more comfortable with the bloated, user-hostile page than trying to understand a human voice through a 4000 Hz telephone channel. I like not having to try to explain to them what I want. With the web I can do it whenever I want, at my own pace.
It feels like a voice call is an admission of failure: sometimes of their web interface design, sometimes of my ability to read. If I am calling on the phone it's only because I want to talk to a human being, and I want that disgusting process over with as soon as possible.
There is never anything I want from the phone tree except a human operator. If you could automate my request then you should have done it over the far clearer interface of the web page. Maybe there are some people who have a phone but not a computer, but I am not one of them. I'm only talking to you because the easier (for me) ways have failed.
> There is never anything I want from the phone tree except a human operator. If you could automate my request then you should have done it over the far clearer interface of the web page.
This. It's particularly infuriating that now many phone trees don't even have a built-in "I want to talk to a human, now" option. Hitting "0" used to be a fairly common way to do that, but doesn't appear to be any more. Often I have to wade through three or four levels of phone menus just to get to something that will take me to a human.
The idea was that all the jobs of someone handling errands for you were automated away and it became a self service thing. Yes, sometimes it is easier to buy something online, no doubt about that but when problems creep in it takes too much of our precious time and from our mental context dealing with things that would be dealt with if those jobs existed. If those jobs existed in higher numbers you could just call a number and a human responds and assists on the other end of the line.
Phoning for anything is my favorite thing. Absolutely I want to talk to customer service. No I donāt want this automated (especially when Iām trying to get myself a slightly better deal). And I hate phone trees with a passion, just get me the operator now.
Phoning is my least favorite thing (well, except for in-person visits), but I also want a human on the other end of the line when I call. If I'm calling, it means I couldn't get the website to do the right thing for me.
Same with self checkout at the grocery store: I know a lot of people like it, but whenever I do it Iām thinking āthis is someone elseās job! Why the hell am I having to do it now? ?ā
Around here we have two self-service checkout systems: one is as described, where you have to take each item individually out of your card and present it to a scanner. I detest those, as it makes me feel like a fool fumbling around with the scanners while the cashiers are 10x faster than I am.
The other one is where you pick up a handheld scanner at the store entrance, and you build up your item list while you're in the store loading your cart. Those ones I like, as they feel much faster and much more reliable to me. Moreover, I can look at the display of the scanner to see if I have all the items I came for, I don't have to search the cart.
And inevitably there are always at least 2 employees standing around the self-checkout helping customers that are having problems with the machines.
For me checkout with a cashier doesn't feel like less work though. I bring them my bag, take out each item, they scan them, and then I put them back in my bag. All they're doing is swiping! (Growing up we had disposable bags and human baggers, so maybe it saved a tiny bit more time.)
Ideal customer service has both an api/app/webpage and a human to call for support.
It's easier to prove that one "saved" the company money by removing a support position than to evaluate the amount of money wasted yearly by engineers having to buy paperclips and figuring out how to expense them in the horrible expensing software.
Itās a very human tendency: we can see the downside so obviously, but the upside is a lot harder to see.
Open offices: another amazing example of enormous value destruction in the name of saving a little bit of money.
I never thought open offices were about cost savings, I always thought it was about someone reading that we spend too much time isolated and need more interaction or some such BS.
yes and there is also often departmental budget arb going on here
Devs in engineering org now have to spend more time on self-service portals & chasing tickets because the manager of the infrastructure org laid off a bunch of sysadmins.
I once worked at a bank where even replacing a physical disk in a US datacenter involved a ticketing system which dispatched tickets to India. The remote guys would then, presumably, raise some sort of internal ticket so the guy physically in US could you know.. replace a bad disk.
Turnaround on bad disk swaps went from hours to weeks. As the hardware aged, we started to have enough disk failures pile up on RAID arrays that data losses occurred.
Somewhere someone in infra cut his budget though!
Systems are better too though. When I was an intern all meeting scheduling was done on some convoluted mainframe system. Most of my co-workers had forgot their login to the system, they either grabbed a room that was empty and left if someone showed up, or they had the secretary schedule it (these were computer programmers Sun workstations on their desk, not computer haters who refused to learn). One day we rolled out a new system that was easy to use and suddenly all meetings got scheduled by whoever wanted to have one (then that got replaced by exchange/outlook which we could figure out but wasn't anywhere near as easy).
So some of the savings is good. It is faster for me to schedule a meeting in outlook (not the same company) than to find a secretary to schedule my meetings. However the secretary might be worth going back to just because they always knew important gossip that was worth knowing.
Your example definitely is something that should have been automated and not good use of an administrative assistant's time, but humans are good at navigating unclear processes and organizations.
For example, in one of my internships, it turns out that someone mistyped my address so my paychecks were sent to the wrong building; after a few weeks of that not getting resolved through HR, the administrative assistant took it upon herself to fix it and figured out whom to go yell at to get it resolved within a few days.
They're also good for things where having specialized knowledge of a process that's not done often can be done by someone who does it more often.
For example, when it comes to corporate travel, our company has a self service portal, and every time I need to book business travel I have waste an hour to figure out the right combination of flights and hotels to use, and another hour after returning to enter all of the expenses in the expensing system; I'd much rather send an email like "need to go to office X between Y and Z, no red eye flights" and "here's the receipts from our last trip, we took client W for a business dinner on May nth" and have it all happen.
Someone who does it several times per week would be much more efficient at doing it than me doing it a few times per year. But maybe in a few years we'll get some AI assistant that figures out that I like seat 3A, departures that are not too early, and figures out how to determine the expense types from various receipts.
The difference is that a single $150k/year programmer can make software that replaces an unlimited amount of $40k/year secretaries.
Software scales - that's why programmers have such high salaries (which are usually only a fraction of the value that they're delivering anyway).
Iām saying those programmers should have secretaries to help them with all of the admin etc. They shouldnāt be booking their own flights, or making dinner reservations, or running expenses (or a lot of other manual work)
My previous office went through that cycle.
Circa 2000 (and continuing through the 00s) there was a massive cutback in administrative personnel. By the time I got there (circa 2010) there were essentially no administrative support personnel except for those at the very top. During the 10s they realized that they were spending around $10k/year/person on travel related stuffs not because it was necessary, but because of the time lost to deal with the software that was supposed to remove the need for the full-time administrative staff.
By the end of the 10s, they'd restored the administrative teams and were spending much less per year on "overhead" (non-billable hour) even if you counted the admin teams as only overhead. Down from around $10 million to less than $1 million by just having a dedicated team that dealt with travel and finance stuffs.
The problem was that most people only traveled once a year, at best, and so they had no real experience with the unintuitive software. The average traveler was spending a week extra per trip, which was not billed to customers, dealing with reservations (1-2 days total pre-trip) and finances (2-3 days total post-trip).
Mythical Man Month describes secretaries in a software context. What spoke to me about it was none of things, but instead: scheduling meetings, taking and distributing agendas and notes for those meetings, being the curator and librarian of project documentation. Just because these things are digital now, doesnāt mean any of the engineers on the team will step up to do them consistently or well. Many projects could run more smoothly with someone in that role.
Software can only replace some roles that administrative staff filled. Most often, like in the case of email and word processors, it distributes the work and eats up everyone's time by moving it from specialists to non-specialists.
Isn't it ironic.
The optimum should be, of course, software empowering the specialists, so they can do more with less, providing better service to more people. But hey, a specialist costs $X in salary; a specialist + software that empowers them cost $X + $Y for the expensive license. Meanwhile, a SaaS that allows everyone to do the task lets us save $X on the specialist, and costs peanuts... plus a good fraction of everyone's salary, but nobody notices that.
Do really programmers in the US get all that money? I mean, I don't even get the money that a secretary gets... and in Europe, not in India
Absolutely, I'm in the poorest part of the country and I made more than that last year after a bonus. Will make less this year.
One of the uncomfortable conversations we're going to have to have soon is about how 'Flow State' is efficient but ineffective.
One of the characteristics of Flow State is a diminished sense of considering the consequences of an action. Exactly the "so busy figuring out if they could do it that they didn't stop to think if they should do it".
In particular I've noticed that people get extremely defensive about code they wrote in Flow State. My working theory is that we think somewhere on a spectrum from, "how could anything that made me feel that good really be bad?" to "I got three days of work done in one day you are crapping all over it instead of congratulating me? Fuck you!"
I know that the efficacy of my code tends to be higher when I 'come up for air', reason out what to do next, and if I find that Flow Me is disagreeing with Planning Me, I stop and regroup. This is essentially the same skill I use to, among other things, keep from overspending at a store - setting ground rules and stopping when I'm tempted to violate them.
Pomodoro might be a little to structured for many of us, but as a starting point it might be a reasonable antidote.
I think in general that programmers have an easier time entering Flow State, but if you're going to willingly exit it, you had better have some confidence you can find it again, so you need to have better than 50:50 odds of being able to enter it at will instead of just going with it when it happens. This seems to be a rarer skill.
I think you're misconstruing the Zone with the Flow State. Note these are really just arbitrary terms with vague meanings, but I think it's still useful to have terms to root the discussion.
What they have in common is the aspect of no-self, where you lose your sense of self and become what you're doing. But I think how this manifests is different. In the Zone is where you have the full context of the problem in your head and are completely focused on it. You are the problem. Whereas in the Flow there is no conscious focus, you are the work, the muscle memory act. Maybe another way to put it, using your terms, is that when I'm coding, in the Zone, I have both the Flow Me and the Planning Me active at the same time but when I'm playing the piano I only have the Flow Me active.
I personally find both experiences very enjoyable but, at least in my case, the experience is different.
Usuallly you are going over old grooves in a flow state, Iostly get them with physical actions like skiing or playing an instrument. Its like an autopilot mode. If one needs to reason, they must necessarily pop out of flow-state, potentially just back into the "zone" .
I find it interesting that Wikipedia agrees with me. Whatās your opinion on them treating the two as equivalent?
But for argumentās sake letās say they are different and Iām talking about the Zone Which is Not Flow. The hazard is still there, right?
What youāre describing is, to me, one of several other mental states, in which you can perform one physical task while your attention can be on any subject, from the subject matter of the task at hand, to philosophy. Because you are working from rote, itās optional whether you consider the profound long term implications of your actions. In this state you arenāt really going faster than anybody around you doing the same activity. Whereas rearchitecting a big part of your code base invites a trip to the Zone, even if Refactoring teaches us that with enough experience you can achieve similar outcomes without it.
In particular, mastery of a subject involves pushing much of the work into intuitive thinking, where it is cheap and affords you to focus consciously on anything you want. This is just mastery though, or what Thinking Fast and Slow might call Type 1 vs Type 2 Thinking. Maybe Iām weird, but I donāt really agree this is a mental state. Not any more. Iād be curious to see if, as you advance in your career and hobbies, if you still agree with your assertion that this is a mental state, rather than an achievement.
Something Iāve discovered is that a number of different groups lay claim to a Zone-like experience and for at least the ones Iāve tried, Iāve found they are all the same thing. Even though strategies vary for how to enter it, the feeling is exactly the same. Multiple sports, programming, even once in a yoga class (last day of a class, I recall thinking, āuh oh, this could be addictiveā). Iām starting to have my suspicions about satori, and wondering if this is just some peopleās first experiences with The Zone.
At any rate, this experience informs my comments about practicing entry and exit with the purpose of using it in small chunks instead of all at once (or all the time). The danger is if you can push that button why wouldnāt you all the time? It feels amazing, I wouldnāt doubt thereās a dopamine hit going on. But I donāt for the same reasons that getting buzzed on alcohol once a week or fortnight is one thing, and being drunk all the time is something else entirely. For many it becomes a conscious decision which road to take.
(I will confess that after all these years, including a six year run as an endurance cyclist, I still canāt say which of these states the Runnerās High is. Iāve felt good, Iāve been In the Zone, Iāve gotten lost in thought and had epiphanies, and Iāve had the miles melt away. I never felt a āhighā that turned out to be a distinct experience, although in some cases it was my first.)
I agree with this. Flow is a useful adaptation for something like learning muscle memory - practicing athletics or performing music. But when we're talking about intellectual pursuits like programming, if what you've done by entering flow is convert thinking into muscle memory - a cycle of mashing edit and debug keys - you may have just "laborized" your work. And this has some implications for what kinds of software can be sold to people, as well as how software is created.
The norm of programming is really to flip between "trivial 5 minute task" and "requires a day off to contemplate". And in the industrial context, it's evident that most of software is built to restate a preexisting belief - this is good, if we make an app that does it, it's better. This means disengaging from the philosophical problem of whether it's actually "good" and contemplating it until the resulting belief structure has grown so unwieldy and contradictory that it is a technical challenge to maintain it. But selling a preexisting belief is one of the best markets to be in: if you're selling to artists, you sell software that looks like a paint canvas. If you sell to musicians, you sell software that looks like studio gear from 50 years ago. If you sell to investors, you sell a thing that looks like money. What you can't sell(easily) is: new ways of making visuals, new ways of describing and performing music, new ways of explaining credit and value transfer in an economy.
Hence there is an awful conundrum; if you are experiencing a lot of flow, a lot of "wind in your sails", the whole thing is almost certainly on the wrong track and you'll only wake up to it later, because it means your ability to contemplate went out the window. The problem is not just that you can write something bad this way, you can even be praised and given access to more resources if your wrong belief is shared!
That is probably why software has this underlying tendency towards mysticism and cargo cults, in fact; "It's a good practice." "Why?" "It makes me feel good and the customer likes it." "What's the benchmark?" "I get paid, and it hasn't failed yet."
> and you'll only wake up to it later
I generally consider myself fairly good at gathering evidence of self inflicted problems, but Iāve worked at places where the worst offenders never really admitted hey have a problem. Once you involve the ego, people can feel an existential threat when you tell them the thing they are good at, the thing they enjoy doing, is hurting everybody.
We tend to develop coping mechanisms to deal with our own flaws, but everyone else can find themselves adapting to the new circumstances fairly suddenly.
Very interesting idea, and honestly quite scary. I love my flow state, but I do recognize the defensiveness. Not sure I have run into making bad decisions "in the flow" yet, but I could see how it happens.
If true, the bad decisions coupled with defensiveness could be a potentially really toxic combination.
I think youāre completely right and one way to counteract it is to bake in ānon workā or āidle workā time regularly. This doesnāt have to be a vacation, but it does mean staying out of flow and reflecting on the project as a whole. This can also be a good time to fix little boring things like individual UI elements.
I work in public sector digitalisation and have for a decade, so this article sort of rings home with me. Especially now, having passed a year of thousands of office workers working from home and having seen a rise in efficiency and quality across all our sectors. Iām not saying working from home is an all-good sort of thing, we have also seen an increase in stress and depression related sickness, but in terms of getting shit done, things have been never been better.
Which is sort of ironic from my department, because this has also been a year where our process optimisers and MBAs have been almost completely unable of performing their usual efficiency and benefit realisation consulting in our different departments, as thatās a hands on sort of thing. Not that theyāve done nothing, theyāve been to really good work helping managers coordinate remote work and teaching both the CEO and Political layers how to use Microsoft teams efficiently.
Anyway, if weāve increased efficiency and quality more in a year or not trying to, it sort of begs the question what good trying really does. You obviously canāt really conclude anything scientific on our anecdotal measurements as weāve seen the major change of going remote on top of it, but it is something to think about.
Not that we will, weāre already trying to figure out how to go back to the way things were, as the majority of our managers still seem to think people work better if they spend 7 and a half hours in an open office 5 days a week.
It reminds me a little of a story I read about Alcoa, the Aluminium manufacturer.
They had been have issues with improving productivity. One of the issues was the workforce and unions were reluctant to accept any change.
New management came in and rather than pressing on productivity issues they decided to double down on safety. They hadn't been particularly bad but not great either.
Obviously staff and unions are never going to complain about making their workplace safer. What also happened was as soon as process were open to change to improve safety they were also open to change for productivity.
I wonder in cases like yours whether the pandemic just unstuck a lot of things because all the previous excuses floated away as soon as someone says "because covid".
Just throwing peanuts from the gallery, is it possible that process optimizers' hands-on efforts have been confounded by the Hawthorne effect?
Anecdotal but I know at least one megacorp that is doing layoffs of manager level positions after noticing that their services/industrial processes worked well while them being on furlough during the lockdowns.
I've only been working professionally for 5 years and this is something I am only recently beginning to appreciate. Optimizing for efficiency makes you get a lot of work done but it reduces your ability to think creatively which can potentially impact the quality of ones work.
But the MBAs have already done the [creative] thinking. They just want to throw the spec over the fence and have coders code it. /s
Your job is to make their wishful thinking the thundering success they deserve.
To counter the original point, I find removing obstacles and latency-inducing loops helpful, to start seeing what the work really should be. Gaining efficiency through simplifying is a good thing, and can be creative too. The goal is not efficiency though.
I think you're on to something important here - the word "efficiency" is used to describe optimization in two different mental regimes: one, "how to meet a given quality of work with the minimum of friction/wastage" vs two, "how to perform the maximal work within a fixed resource allocation."
They sound similar, which is probably why we use the word "efficiency" to describe improvements in both regimes, but the fundamental constraint is different: in the first case, it's the standard of work that must be achieved; in the second, it's the resources allocated to the work. I'd summarize the first "do enough with enough" and the second as "do more with less."
What you describe sounds like "doing enough with enough:" given the work to be done, how can we remove resource-draining obstacles, idle loops, etc. and identify "what the work really should be?" - is that a fair assessment or am I off the mark?
> I find removing obstacles and latency-inducing loops helpful, to start seeing what the work really should be.
Should MBA's be studying DevOps?
This might even be rooted in human psychology. "The Master and His Emissary" and other books about neuroscience argue that we have brain functions specialized for focus and other brain functions specialized for context. Activating focus reduces contextual thinking.
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.
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.
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.
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.
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.
Maximising utilisation usually means an increase in latency. You don't want your ambulances or fire fighters at high utilisation.
It's a balance. If 10 firefighters don't see high utilization, you don't want to increase the staff to 20, just in case. That's just a waste of money.
The rule of thumb is that you want utilization to be where there is an acceptable latency depending on some percentile of cases. For a firefighter, you'd probably look at p99 latency. For a hamburger joint, p50 on order time would be good enough.
>you don't want to increase the staff to 20, just in case. That's just a waste of money.
I believe OP's point is that you do want the staff of 20, for the once-in-a-lifetime fire that requires 20 people. See also: the recent Texas power grid debacle, or the saturation of ERs due to COVID.
> you do want the staff of 20
No, you don't. Resources are not infinite, and at some point the budget has to be taken from other services which are more useful than a once-in-a-lifetime event.
Or you do want the staff of 20, but then it must be a volunteer and/or on-call duty system. Otherwise it is not sustainable.
In my country, the shift/switch to professionalisation that started 30 years ago has gradually become a big problem. Despite the fact that they still represent only 20% of the firemen, they are killing the budgets, and they always want more (lots of strikes); apart from 'standard' raises, the most common thing they ask for, is that on-call hours should be paid full-rate, as active hours. Which, beside being extremely costly, is absurd when they are 'working' 24h shifts! It contains a few hours of training and, depending on location, a few hours of duty; the rest is on-call (at home or on premises depending on the type of station), the number of service calls is limited, and 1 in 4 shifts happen without a single call (even more for 12h shifts).
There are plenty of other problems which surround this professionalisation, but they are not directly related to this subject.
Seems like the original article/book and your comment tie back to Little's Law from queuing theory which is used as justification in Kanban for minimizing WIP.
Great interchange of comments.
I doubt you will ever see even firefighters with low utilization. They can use extra time to do inspections to make sure there aren't any fires, or put on presentations at neighborhood association meetings teaching the public about fire hazards. If they aren't doing those things and there aren't any fires, they're just lazy.
Absolutely not. Not that those things aren't great, and hopefully already being done, but there is zero need to ask firefighters to be at 100% utilization at all times. There is value in having some one perform busy waiting in the event of an emergency. Did you know thats a training drill they perform? How fast they can be out and on their way from the moment of getting a call.
In The Netherlands it is more like our IC beds.
What does ic bed mean?
IC = Intensive Care
Intensive care
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.