Why are you so busy?(tomlingham.com)
tomlingham.com
Why are you so busy?
https://tomlingham.com/articles/why-are-you-so-busy/
129 comments
The general thesis: "to optimize, do less" is correct (even tautological in the time performance area) but specific examples without additional context are troubling:
I see an enthusiastic manager reading your post as an endorsement of dropping tests, code reviews, git, any kind of automation, etc (as it doesn't bring direct business value). Obviously, it is shortsighted. You'll pay dearly for any time you initially save by dropping these practices in most contexts.
I run the data science department in a corporation. The best thing I've done is banishing Excel from our reporting workflow and replacing it with various types of automated reporting. Stuff like that is what you should cut, not something that'll end up adding technical debt.
This is what I keep telling my (senior) managers. In order to let people do “more X”, you should have available a list of Y they are already doing and Z that will fall below the fold if prioritizing X. If you don’t have that list, any discussion about resources and priorities is an emotional one, not a rational one based on an adequate view of what teams are delivering.
To piggyback there -- people stop asking questions when counterparties meet or exceed expectations. It is essential that expectations are set reasonably, otherwise one or both parties are in for a world of hurt.
> I know that most feel that they absolutely HAVE to do these things, since there are part of the business process/ definition of done/company guidelines etc...
Anecdote: at current position I've noticed 100% of my team time goes to "these things". As a team lead I tried to figure out the actual necessity. After I've "lost" the half of the team insisting on doing all the rituals the remaining half started to deliver actual value with much less stress.
Anecdote: at current position I've noticed 100% of my team time goes to "these things". As a team lead I tried to figure out the actual necessity. After I've "lost" the half of the team insisting on doing all the rituals the remaining half started to deliver actual value with much less stress.
As the company gets bigger, it naturally starts doing more rituals. Some are justified, most are a cargo cult.
The sad part is that since rituals are an inherent to a big company, following (and enforcing) rituals is synonymous to being professional. And fighting them is often seen as amateur.
No, I'm not doing performance reviews and weekly 1:1 with each team member. Not because I'm an amateur, but because I'm in the trenches with them every day. Maybe I'll start doing those when we get bigger. But let's get there first.
The sad part is that since rituals are an inherent to a big company, following (and enforcing) rituals is synonymous to being professional. And fighting them is often seen as amateur.
No, I'm not doing performance reviews and weekly 1:1 with each team member. Not because I'm an amateur, but because I'm in the trenches with them every day. Maybe I'll start doing those when we get bigger. But let's get there first.
> As the company gets bigger
In first startup I was working we were four engineers and our whole shared context could fit into two whiteboards and Kanban board in GitHub.
Next one was a couple of hundreds of engineers and a lot of coordination activity directed by iron fist of program managers.
Next one was fifty engineers but with the same amount of coordination activities (for the sake of the process) and much less progress.
And the current one had ten people in engineering, three chapters (backend, frontend, DevOps), incident board, 1-1s, retro, planning, refinement, weekly, quarter retro and planning and sprint review.
Fun fact: at current place no one knew the term "cargo cult". When I explained the meaning some colleagues considered it offensive.
In first startup I was working we were four engineers and our whole shared context could fit into two whiteboards and Kanban board in GitHub.
Next one was a couple of hundreds of engineers and a lot of coordination activity directed by iron fist of program managers.
Next one was fifty engineers but with the same amount of coordination activities (for the sake of the process) and much less progress.
And the current one had ten people in engineering, three chapters (backend, frontend, DevOps), incident board, 1-1s, retro, planning, refinement, weekly, quarter retro and planning and sprint review.
Fun fact: at current place no one knew the term "cargo cult". When I explained the meaning some colleagues considered it offensive.
A good question to ask: why is it a part of our business process to do things that don't generate business value?
The honest answer is usually: we don't really know what is the right process for us, but because we couldn't admit it, we tried to replicate somebody else's process.
"Nobody ever got fired for implementing OKRs".
The honest answer is usually: we don't really know what is the right process for us, but because we couldn't admit it, we tried to replicate somebody else's process.
"Nobody ever got fired for implementing OKRs".
A while back I took a couple years off from working. Sometimes I'd still find myself saying "I've just been too busy" when asking myself why I didn't get something done. Didn't take long to realize that "I'm too busy" had been an excuse I had been using to justify poorly thought out priorities. I still haven't fully broken the "I'm too busy" pattern but at least now I know there's a decent chance that I haven't actually been too busy and I need to look more at what it is that I have been doing and whether or not those things are truly more important than whatever I was "too busy" to do.
Agreed, sometimes you can literally replace the phrase with "it's not important to me" and shock yourself
Yep. A lot of the times I don't care about something, I use the time excuse.
My brother retired in his mid-40s. He has the same problem. He was a chef and had spent 2 decades working himself to the bone, genuinely being too busy to get things done. In retirement, he became "the busiest unemployed person I know" and hearing that a few times helped to snap him out of it.
One has to be fair to oneself too though. Most of us could probably do more in a day's time, than we do. There are consequences though, if one goes to the max for a time. For example we could learn a lot and get a better paid job. However, we might lose some friends, because we did not put any time into interacting with them instead of learning a lot. Just as an example.
So cut yourself some slack too. The balance of that might not be obvious.
So cut yourself some slack too. The balance of that might not be obvious.
While I love this quote:
> as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.
I feel like this is missing an acknowledgement that "what a team is capable of" actually depends on the manager! Managing people and priorities takes skills that require practice and learning. A manager that, for example, assigns people to work on things they enjoy working on and avoids excess pressure is going to have a team capable of a lot more than a team where the manager doesn't bother.
So, when I see the list of "reasonable ways for the business to exert influence over the work" I feel like a huge missing one is "help the manager manage their workload and the team better". The manager has a manager and this is ostensibly their responsibility to see and correct
> as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.
I feel like this is missing an acknowledgement that "what a team is capable of" actually depends on the manager! Managing people and priorities takes skills that require practice and learning. A manager that, for example, assigns people to work on things they enjoy working on and avoids excess pressure is going to have a team capable of a lot more than a team where the manager doesn't bother.
So, when I see the list of "reasonable ways for the business to exert influence over the work" I feel like a huge missing one is "help the manager manage their workload and the team better". The manager has a manager and this is ostensibly their responsibility to see and correct
I couldn't agree more. This is written from the perspective of a manager so I am likely asking a bit too much from the reader to make the connection. Thank you for the feedback!
My experience tends to be that managers will rarely get help to manage the teams WIP and it's often left to that same manager to provide that mechanism of back-pressure. But if they then don't, for whatever reason, then it can be bad news for the team.
I'm weeks away from going on a significant period of leave and I sincerely hope that the precedents I have set carry forward during my absence.
My experience tends to be that managers will rarely get help to manage the teams WIP and it's often left to that same manager to provide that mechanism of back-pressure. But if they then don't, for whatever reason, then it can be bad news for the team.
I'm weeks away from going on a significant period of leave and I sincerely hope that the precedents I have set carry forward during my absence.
As a manager, my long term goals are perfectly aligned with my teams. I want them to be (mentally) healthy, motivated and happy. This is what makes the team (and me!) loyal and productive, and it will prevent sickness/absence. I never get the manager vs team perspective, it feels like whenever there is a “versus” in perspectives, something is wrong and will lead to problems over time.
Surely then all that should matter is reviewing the code and reviewing the WIP (jira). for each manager each day
doing anything else is pretending project managers are managers
doing anything else is pretending project managers are managers
In a team of specialists, it can kill the whole nice plan if one leaves for annoyance about productivity. People get offers all the time on linked in, don't give them a reason to listen.
One time I left because I could rarely do my actual job. Meetings, wasting time with bad internal tools, having useless complex processes, nobody wanting to take responsibility for final decisions.
I totally work (paid or flex) overtime, if I have the feeling of productivity in the normal time. But not if the company or project structure is a time wasting machine where you learn nothing but how to be annoyed.
One time I left because I could rarely do my actual job. Meetings, wasting time with bad internal tools, having useless complex processes, nobody wanting to take responsibility for final decisions.
I totally work (paid or flex) overtime, if I have the feeling of productivity in the normal time. But not if the company or project structure is a time wasting machine where you learn nothing but how to be annoyed.
I turned this into a poster and hung it in front of my desk. Great quote.
“as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.“
“as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.“
Often very useful things are never the "next most important" if you don't scope "importance" very carefully.
"Slow down to speed up" can capture it, setting aside times for those non-critical maintenance steps that prevent problems or make everything just a little bit faster can make worlds of difference in your work, but never seem to be able to compete with the "next most important" thing on the list.
"Slow down to speed up" can capture it, setting aside times for those non-critical maintenance steps that prevent problems or make everything just a little bit faster can make worlds of difference in your work, but never seem to be able to compete with the "next most important" thing on the list.
That reminds me of the military saying "slow is smooth, smooth is fast".
I like that analogy a lot! I've just realised that the same thing applies to racing, for example. The way I tend to play racing simulators is that I try to go full throttle all the time, and then when I stumble upon sharp turns, I just crash into them, losing much more time than I would if I didn't try to go as fast as I can all the time.
This is actually a thing in real racing, the fastest times through complex curves look slow.
I think the “doing your work well” part is often the question. Am I really doing all I can? Could I do better/more? This then leads to working more and being busier. Maybe the problem is that it’s hard (for some of us) to know what “well” really means.
I think "Could I do better/more?" is just a dumb question. As an employee, I have no plans to ever ask that of myself again. I'll get some things done that I set out to do, sometimes they'll take more or less time than I think, and the rest is either neutral or margin. There's no point in doing more. But you're right, you need a measure of what the right amount is, and I think that varies and can be hard to pin down.
This comment reminded me of this from the recent post of Sivers' Relax article.
In a marathon-like environment, you don't want to go to 100% for a very long time, because you'll drop to 50% or less for a longer time than maintaining at 85% for the majority of the event.
You can always do more, so the question then is: Do you really need to be doing more right now? Is this the best use of the boost before I need a break?
https://news.ycombinator.com/item?id=32626119 sive.rs/relax
In a marathon-like environment, you don't want to go to 100% for a very long time, because you'll drop to 50% or less for a longer time than maintaining at 85% for the majority of the event.
You can always do more, so the question then is: Do you really need to be doing more right now? Is this the best use of the boost before I need a break?
https://news.ycombinator.com/item?id=32626119 sive.rs/relax
This is one reason why I go all in on practices that are backed by data to correlate with business success (CI/CD, DevOps, etc.). Think the Accelerate book. Software development has the added difficulty of being quite a young industry (relatively speaking), but (with tongue in cheek) how can you be expected to do better than practices espoused by industry leading research and companies?
Thanks, that sounds like a good strategy. I’ll have a look at the Accelerate book.
> how can you be expected to do better than practices espoused by industry leading research and companies? True, but not everyone has reasonable expectations :-) In those cases perhaps all that remains is to either have a frank discussion or to part ways.
> how can you be expected to do better than practices espoused by industry leading research and companies? True, but not everyone has reasonable expectations :-) In those cases perhaps all that remains is to either have a frank discussion or to part ways.
Like I tell my kids when they go too fast (I heard it from somewhere)...
"Smooth is fast kids, smooth is fast!"Originally it was: "slow is smooth, smooth is fast"
and speed is economy of motion
I love how far removed from reality these idealistic blog posts are from "technology thinkers".
You're busy? You shouldn't be so let me give you some cookie cutter advice filled with: "you need", "you should", "you could". More in my book.
You're busy? You shouldn't be so let me give you some cookie cutter advice filled with: "you need", "you should", "you could". More in my book.
I don't think this is removed from reality. I think people who are in perma-crunch believing that just over the next hump they'll find level ground are the ones who are removed from reality.
This is spoken like someone that has yet to really face any real and lengthy incredibly stressful life events. I really wish I could be this privileged and out of touch to make a statement like this.
If you want to remain functional during lengthy and stressful life events, it is critical to understand your capacity, prioritize the tasks ahead, seek skilled collaborators/contractors, and forgive yourself for the things you simply cannot do.
When a life-crisis turns into an extended campaign, it is essential to know how to prevent yourself from burning out. Burning beyond that level must be reserved for true emergencies, where the goal is to bring things back into a new balance.
If you're operating beyond your capacity for too long, the endeavor will begin to stumble. That's what the article was trying to help the reader avoid.
When a life-crisis turns into an extended campaign, it is essential to know how to prevent yourself from burning out. Burning beyond that level must be reserved for true emergencies, where the goal is to bring things back into a new balance.
If you're operating beyond your capacity for too long, the endeavor will begin to stumble. That's what the article was trying to help the reader avoid.
I could be mistaken, yet can't help but imagine divorce when reading such lines:
>When a life-crisis turns into an extended campaign
It's sad to see people trying hard to keep a stoic stance while such a vile thing is being done to them. Why such ruinous dynamics didn't get a society-wide political solution for a decade after decade...
My generation is afraid to marry due to reading such stories.
>When a life-crisis turns into an extended campaign
It's sad to see people trying hard to keep a stoic stance while such a vile thing is being done to them. Why such ruinous dynamics didn't get a society-wide political solution for a decade after decade...
My generation is afraid to marry due to reading such stories.
With the important acknowledgement that divorce can be devastating to many people, especially children (myself included):
One can readily argue that divorce was created to solve the problem of entrapment in unhealthy marriages.
The possibility of divorce ought to make people more willing to marry; it is possible to escape if everything goes wrong.
One can readily argue that divorce was created to solve the problem of entrapment in unhealthy marriages.
The possibility of divorce ought to make people more willing to marry; it is possible to escape if everything goes wrong.
Well this seems like a useful attitude to have.
Some people probably can’t escape their workload with better time management. Fair! Some people certainly can though (I know many such cases), rendering your comment a little ridiculous, and extremely rude.
Note for future empathy exercises: most people encounter difficulties in their lives.
Some people probably can’t escape their workload with better time management. Fair! Some people certainly can though (I know many such cases), rendering your comment a little ridiculous, and extremely rude.
Note for future empathy exercises: most people encounter difficulties in their lives.
This is spoken like someone who has faced too many lengthy events like this, and doesn't enjoy thinking there may have been a way around some of them.
I've worked in offices where everyone is super busy but seemingly little to no progress is made. It's really maddening.
One time I put together a strategy where the recommendation: "watch and wait". The idea was - there wasn't any work to do, what we had was "good enough" and flexible to be a good option no matter if the market shifts, and our job was to watch the market over the next quarter, observe, and collect insights. We were anticipating market changes, so any work done now might be worthless in 3 months.
People weren't comfortable with that at all. Clearly we should kick off some new product feature, or engage new start-ups on something innovative. We had to do something.
It reminds me of that scene from the movie Ronin when they are waiting for more information on the target:
Gregor: It would be nice to do something.
Sam: We are doing something. We're sitting here, waiting.
One time I put together a strategy where the recommendation: "watch and wait". The idea was - there wasn't any work to do, what we had was "good enough" and flexible to be a good option no matter if the market shifts, and our job was to watch the market over the next quarter, observe, and collect insights. We were anticipating market changes, so any work done now might be worthless in 3 months.
People weren't comfortable with that at all. Clearly we should kick off some new product feature, or engage new start-ups on something innovative. We had to do something.
It reminds me of that scene from the movie Ronin when they are waiting for more information on the target:
Gregor: It would be nice to do something.
Sam: We are doing something. We're sitting here, waiting.
Reminds me of the Blaise Pascal quote:
> “All of humanity's problems stem from man's inability to sit quietly in a room alone.”
Doing nothing is uncomfortable, because you might accidentally discover a truth about yourself that you've been busy avoiding.
> “All of humanity's problems stem from man's inability to sit quietly in a room alone.”
Doing nothing is uncomfortable, because you might accidentally discover a truth about yourself that you've been busy avoiding.
The crazy thing about this is that it can be purely mental. My most productive coding session this year happened when I had to quarantine and I knew my employer wouldn't mind if I just did nothing. There was no pressure, but I still wanted to move on a little bit with the project. Just a few hours a day. I mai ly did this because I like the project and I would get into a lot stress later if it was not done.
I got more done in two half-days at home than in a week of full days at the office. No distractions, no meetings, no obligation to answer mails and phone calls. Paradise.
I got more done in two half-days at home than in a week of full days at the office. No distractions, no meetings, no obligation to answer mails and phone calls. Paradise.
"In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state in which a person performing some activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity."
You entered this state.
You entered this state.
Thats why I think the approach ti estimates and project planning should be: developers are trusted
not to slack off and not to over engineering it. So it takes as long as it takes. But if it might go up an order of magnitude talk to the team to see if it is still worth doing or how to reduce scope.
Instead of the usual estimate, negotiate the dev down, use a mythical man-month then bollock them for not getting it done on time (ok these days microaggressions are in fashion as you can’t outright yell)
Instead of the usual estimate, negotiate the dev down, use a mythical man-month then bollock them for not getting it done on time (ok these days microaggressions are in fashion as you can’t outright yell)
I also do this (flow on my own mini projects) a few times a year it seems.
I think it’s easy to idealize it, but likely those times are enabled by cultivation of your thought during all the other times at work, and there’s a selection bias of I know that you can accomplish it in that time. Basically it’s a well defined task already specc’d out (or defined bounds or a path forward) in your mind ahead of time. This is just as important to flow as removing distractions.
I think it’s easy to idealize it, but likely those times are enabled by cultivation of your thought during all the other times at work, and there’s a selection bias of I know that you can accomplish it in that time. Basically it’s a well defined task already specc’d out (or defined bounds or a path forward) in your mind ahead of time. This is just as important to flow as removing distractions.
Please note the important caveat in the article:
If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps).
This is all too often the root cause of developers being "too busy".
I've had some variation of the following conversation nearly verbatim with six different teams in the last twelve months:
Me: "I can help you guys to set up Azure DevOps pipelines to automate your builds and deployments, you just need to make sure your code builds on an isolated machine first."
Them: "That sounds nice, but we're too busy to work on that."
Me: "May I ask what is keeping you guys so busy?"
Them: "We have three (manual) deployments this week."
Me: "ಠ_ಠ"
If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps).
This is all too often the root cause of developers being "too busy".
I've had some variation of the following conversation nearly verbatim with six different teams in the last twelve months:
Me: "I can help you guys to set up Azure DevOps pipelines to automate your builds and deployments, you just need to make sure your code builds on an isolated machine first."
Them: "That sounds nice, but we're too busy to work on that."
Me: "May I ask what is keeping you guys so busy?"
Them: "We have three (manual) deployments this week."
Me: "ಠ_ಠ"
While this example feels pretty obvious, I think in practice, these conversations conflict with the third caveat mentioned:
"Your team is always working on the next most important thing (as prioritised by the business)"
When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company.
Early on in my career I felt angry at these kinds of negotiations. As I've become more mild and open to business needs across the board I realise that most people will agree with the goodness of the idea but it becomes the duty of the proposer to sell it in terms that the business unit can agree to.
Overall, this is a great thought provoking article. Concise. Yet nuanced.
"Your team is always working on the next most important thing (as prioritised by the business)"
When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company.
Early on in my career I felt angry at these kinds of negotiations. As I've become more mild and open to business needs across the board I realise that most people will agree with the goodness of the idea but it becomes the duty of the proposer to sell it in terms that the business unit can agree to.
Overall, this is a great thought provoking article. Concise. Yet nuanced.
> When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company.
I think that this is the crux of the problem, but the solution lies elsewhere rather than just in negotiations.
After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.
So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations? That's about the same as writing tests instead of having bad coverage due to an ever growing backlog and scope creep which eat up all your time.
After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project. Tests, CI/CD, configuration automation etc. should be treated the same, since we're paid to be engineers and a part of that engineering is ensuring at least decent quality.
Note: this probably doesn't apply to larger efforts, like changing the entire architecture of your application etc.
I think that this is the crux of the problem, but the solution lies elsewhere rather than just in negotiations.
After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.
So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations? That's about the same as writing tests instead of having bad coverage due to an ever growing backlog and scope creep which eat up all your time.
After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project. Tests, CI/CD, configuration automation etc. should be treated the same, since we're paid to be engineers and a part of that engineering is ensuring at least decent quality.
Note: this probably doesn't apply to larger efforts, like changing the entire architecture of your application etc.
I agree with the idea that solutions can lie in more than just negotiations. But I will also say that I’m at the point in my life[1] where I believe the vast majority of solutions do lie almost purely in some form of negotiation.
Take your own example:
> After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.
This right here is a negotiation between business and engineering. The business unit cares about technical debt only if it affects successful delivery of business goals. As such it needs to be negotiated along those lines. In fact, I’d say you make a wonderful negotiation right after:
> So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations?
That is an excellent negotiation right there. The business cares about successful continued operations. Stopping everything to focus entirely on technical debt is not successful to the business. Allocating x% time to a mutually beneficial goal where x can be continuously tweaked is an acceptable point.
> After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project.
The thing about this point is that it is:
A) easy to get setup.
B) well understood enough now to know the benefits to the organization
I’d argue that ci/cd is coming closer to that point now. Definitely is on the right trajectory and for the same reasons. Easy to setup and the benefits are well known and easily understood.
More nebulous topics like testing and tech debt will for the foreseeable future be topics requiring decent negotiation.
[1] I may change my mind on this in the future. Definitely been around on topics where I believe one thing, believe an alternate point of view, and later have a softer or accepting view of the original idea :).
Take your own example:
> After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.
This right here is a negotiation between business and engineering. The business unit cares about technical debt only if it affects successful delivery of business goals. As such it needs to be negotiated along those lines. In fact, I’d say you make a wonderful negotiation right after:
> So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations?
That is an excellent negotiation right there. The business cares about successful continued operations. Stopping everything to focus entirely on technical debt is not successful to the business. Allocating x% time to a mutually beneficial goal where x can be continuously tweaked is an acceptable point.
> After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project.
The thing about this point is that it is:
A) easy to get setup.
B) well understood enough now to know the benefits to the organization
I’d argue that ci/cd is coming closer to that point now. Definitely is on the right trajectory and for the same reasons. Easy to setup and the benefits are well known and easily understood.
More nebulous topics like testing and tech debt will for the foreseeable future be topics requiring decent negotiation.
[1] I may change my mind on this in the future. Definitely been around on topics where I believe one thing, believe an alternate point of view, and later have a softer or accepting view of the original idea :).
> well understood enough now to know the benefits to the organization
Maybe to you, but unless your business is 100% IT focused (like a software startup), I guarantee you that virtually nobody outside of the dev team knows what version control is, let alone the cost-benefit considerations.
A surgeon doesn't ask the patient whether to use antiseptic or latex gloves.
An engineer doesn't ask the client if the concrete should need steel reinforcing or not.
The lawyer doesn't ask the defendant if he should reference precedent.
The developer shouldn't ask the business for permission to automate their workflow.
Maybe to you, but unless your business is 100% IT focused (like a software startup), I guarantee you that virtually nobody outside of the dev team knows what version control is, let alone the cost-benefit considerations.
A surgeon doesn't ask the patient whether to use antiseptic or latex gloves.
An engineer doesn't ask the client if the concrete should need steel reinforcing or not.
The lawyer doesn't ask the defendant if he should reference precedent.
The developer shouldn't ask the business for permission to automate their workflow.
When I started at Microsoft, this exact scenario happened. I was told I couldn’t automate things because there was no time. I did it anyway, and a 3 person job suddenly became an extremely part time job for one person.
It blew my mind that anyone at Microsoft, of all places would have this mindset.
It blew my mind that anyone at Microsoft, of all places would have this mindset.
When I was at Microsoft circa 2018, our team had a senior engineer whose primary job was doing manual validation of releases. That and keeping a single custom legacy build server running.
I would love to share my experience of release management at MSFT but it would out me.
In the ballpark of 20ish engineers chasing build errors and test failures for a month to bump a version number (one line change).
In the ballpark of 20ish engineers chasing build errors and test failures for a month to bump a version number (one line change).
Because it worked out for you, that time. As a manager and probably the person that would have told you no, or to justify more before we attempt it, I've seen this scenario go pear-shaped way more times than not. It's about risk, priorities, and specifically knowledge/experience (sometimes wrong) that says this is "not a good idea". Sometimes it's also just plain old complacency, though.
It's amazing how many people you can hire (and how many bugs you can ship with) when you sell something that's free to distribute and has no true competition.
I feel both sides of this one.
Yes, creating automated processes would make things easier, but the time it would take to automate the process would take too much time before you have to deliver.
So everyone knows what needs to be done, everyone recognizes that it would help things, but no one can put down what they're juggling to handle it.
Sometimes it takes bringing on a person just to take on that project as its own thing to relieve the pressure on the existing team.
Yes, creating automated processes would make things easier, but the time it would take to automate the process would take too much time before you have to deliver.
So everyone knows what needs to be done, everyone recognizes that it would help things, but no one can put down what they're juggling to handle it.
Sometimes it takes bringing on a person just to take on that project as its own thing to relieve the pressure on the existing team.
Regarding a dedicated person to handle the CI, here is my experience.
In the small company I am working now, I had setup a adhoc deployment script that was working fine, took less than 5min (with no user interaction) on my dev PC. Since it is not a SaaS, our release cycle was a bit slower than wanted, 1 or 2 times per month, depending on circumstances.
A guy was hired and he wanted to speed this up. I explained clearly that the build/deploy script was not the cullprit of the "slow" release cycle. It takes time to decide was is ready for production, write a nice changelog for users (not just collecting git messages), testing on the custom hardware...
That is why it took me an hour to half a day when the boss said: we need a release today. The above guy was justifying its work by: "After I am done, you will just need to put a tag and the rest will be automatic". I could not convince my boss this was fantasy land.
Result 3 years later: we have a "nice" CI which rebuild the world several times per day. But we are doing maximum 2 official releases per year, with much more stress. We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.
And the CI person is constantly tweaking bits of the CI (it has become part of his job), breaking thing here and there.
I long for the old days...
In the small company I am working now, I had setup a adhoc deployment script that was working fine, took less than 5min (with no user interaction) on my dev PC. Since it is not a SaaS, our release cycle was a bit slower than wanted, 1 or 2 times per month, depending on circumstances.
A guy was hired and he wanted to speed this up. I explained clearly that the build/deploy script was not the cullprit of the "slow" release cycle. It takes time to decide was is ready for production, write a nice changelog for users (not just collecting git messages), testing on the custom hardware...
That is why it took me an hour to half a day when the boss said: we need a release today. The above guy was justifying its work by: "After I am done, you will just need to put a tag and the rest will be automatic". I could not convince my boss this was fantasy land.
Result 3 years later: we have a "nice" CI which rebuild the world several times per day. But we are doing maximum 2 official releases per year, with much more stress. We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.
And the CI person is constantly tweaking bits of the CI (it has become part of his job), breaking thing here and there.
I long for the old days...
Then I don't understand what your issue is.
> We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.
That sounds like the problem is that the CI is not testing on hardware, or that you're running ad-hoc manual tests on hardware that could be automated or at least formalized.
> We had a few "releases" which needed very urgent hot-fixes because of last-minute changes and not enough testing on hardware.
That sounds like the problem is that the CI is not testing on hardware, or that you're running ad-hoc manual tests on hardware that could be automated or at least formalized.
Your problem is not the CI. It's that the CI does not test the custom hardware.
You need a hardware testing engineer who can automate the tests that you're currently running manually.
You need a hardware testing engineer who can automate the tests that you're currently running manually.
The initial script was fine, but not ideal. The CI is better in this regards.
The CI is not the problem, sure. But it is not the solution either. That was my point.
The CI is not the problem, sure. But it is not the solution either. That was my point.
The strategic use of interns. With obvious ROI that makes subsequent interns easier to acquire.
There's also the more insidious version of this where instead they go, "That sounds nice, but we really don't need it."
"May I ask why you don't need it?"
"Oh, we found that we spent so much time on deployments that we decided to do only one planned deployment per year now."
In this case, the people you're talking to have obviously only swept the dirt under the rug, but sometimes they honestly think they've solved the problem this way!
(And then they ask everyone to "work harder" because the competition is running circles around them. This usually means cramming more things into already big deployments and failing even harder than before.)
"May I ask why you don't need it?"
"Oh, we found that we spent so much time on deployments that we decided to do only one planned deployment per year now."
In this case, the people you're talking to have obviously only swept the dirt under the rug, but sometimes they honestly think they've solved the problem this way!
(And then they ask everyone to "work harder" because the competition is running circles around them. This usually means cramming more things into already big deployments and failing even harder than before.)
I always thought this was strange. A lot of our deployments don't take time to actually do, they mostly take time to decide when the next deployment is and what should be included. If I could deploy as fast as possible I think I would end up spending less time.
I'm not sure what you mean. If you have the luxury of deployments not taking time, then why do you need to debate what to include? Just deploy as soon as anything is ready for deployment.
"Normalisation of deviance" is a wonderful thing to Google.
I've seen people trying to justify a workflow what is literally 10,000x slower than the industry norm. Then patiently explaining to me that dealing with the fallout of that is necessary, and I was just being uncooperative.
A recent example is I showed a dev team how to identify and fix some crash bugs in minutes. Because they were "busy" and deployments require a mile high pile of paperwork, six months later those bugs are still occurring in production.
They're busy with BAU / support tickets, which is why they can't get around to doing a deployment of bugs they've already fixed.
Guess what the users in those tickets are complaining about.
I think they've fixed the same bug in like.. three separate un-merged, un-deployed branches.
This is what the opposite of CI/CD looks like.
I've seen people trying to justify a workflow what is literally 10,000x slower than the industry norm. Then patiently explaining to me that dealing with the fallout of that is necessary, and I was just being uncooperative.
A recent example is I showed a dev team how to identify and fix some crash bugs in minutes. Because they were "busy" and deployments require a mile high pile of paperwork, six months later those bugs are still occurring in production.
They're busy with BAU / support tickets, which is why they can't get around to doing a deployment of bugs they've already fixed.
Guess what the users in those tickets are complaining about.
I think they've fixed the same bug in like.. three separate un-merged, un-deployed branches.
This is what the opposite of CI/CD looks like.
[deleted]
The Phoenix Project is a good novel where the protagonist cuts scope to save the company. It's been years since I read it, but this post made me think of it.
I would certainly be lying if I said the Phoenix Project hadn't helped me form some of my ideas around capacity and limits on WIP. Agreed, a great read.
Being busy is more about power struggle between someone paying the money and someone doing the job. It's similar in other jobs. The most important part is that the one paying, usually have no idea how to do the thing. If she trust you that you do your job well or is scared that you leave - you wont be busy, but if she doesn't trust you or thinks she knows better, and you can't stand up to this, the only thing left is being absurdly too busy.
I highly recommend reading "Four Thousand Weeks".
https://www.goodreads.com/book/show/54785515-four-thousand-w...
https://www.goodreads.com/book/show/54785515-four-thousand-w...
I have a question: I've noticed that whenever I talk to Americans, or read American blogs and books, they always tend to talk about working so many hours. Personally having worked in Switzerland and Holland I've never experienced this.
Is it that Americans actually structurally work overtime? Or is it the braggadocio way American English works where everything is always in hyperbole? Has anybody here worked on both continents? Can you tell me more whether a cultural divide exists?
Is it that Americans actually structurally work overtime? Or is it the braggadocio way American English works where everything is always in hyperbole? Has anybody here worked on both continents? Can you tell me more whether a cultural divide exists?
I haven’t worked in both continents. But in US some people do and some people don’t. We definitely have many people who subscribe to a work hard to get more attitude. Those people work hard including long hours because they are ambitious, especially startup cultures. Founders really hustle. Alternately there are those that work hard because their manager makes it expected and the employee need their job badly and it’s “easy” to fire people in US. Alternately there are MANY people too that have good WLB or coast.
Personally my WLB has varied by job and responsibilities. I’ve had many years of ~35h weeks, and never worked a 50hr week. My partner though is more neurotic and ambitious and often works 10hr days.
Personally my WLB has varied by job and responsibilities. I’ve had many years of ~35h weeks, and never worked a 50hr week. My partner though is more neurotic and ambitious and often works 10hr days.
In the tech engineering manager role, the busy comes from constant re-evaluation of the next important things from "the business", aka, the non-tech managers that don't care to understand nor keep the current priorities nor work with a software development process. The explanation/deep dive of that reevaluation with non-tech people take a LOT of time.
I watched my manager fall into the "I'm so busy" trap over a few decades. At first he planned things carefully, allowed extra time, adjusted schedules based on feedback. Then his friends started filling him full of business management ideas that I think they got from magazines. Things like "just ask for more, you'll be surprised that your employees will deliver" and "don't give raises above inflation" and "start the next project immediately after the previous one" instead of giving employees some time to relax. Part of this advice he pickup up from medical professionals, who have always had insane work schedules (80 hours shifts as a resident, really? Why doesn't medicine listen to its own advice?) There are lots of older medical professionals who edit a journal, give speeches, consult with companies, are writing a book, are running a blog, doing research, and are still seeing patients in their practice! They have trained themselves to get sleep in 20 minute increments, to push through when they feel sick, and to always take on any opportunity that presents itself no matter how busy they are. And because they demand this of themselves they also demand it from everyone who works for them. It is completely destructive, after a few years of this my manager could no longer remember anything beyond the last week, was setting ridiculous deadlines ("we can do the experiments and write a journal paper in two weeks, but it has to be world class"), and basically missing all his deadlines because they were stupidly unreasonable. His professional career took off though, which added even more tasks to his work, which gave his employees a respite because he had to reduce the number of meetings with them. So it looks to me like there are some meme's that came out of the management/medical worlds that profess to get the most out of employees and they have been widely adopted, but they do not work and just grind up people. If you can ride it out you become a big important person, but you also become dead inside and can't hear anything anyone says any more.
> then you should actually (yes you should, I'll die on this sword)
Die on this hill :) You'll certainly die on a sword, but you won't have defended anything in doing so.
Die on this hill :) You'll certainly die on a sword, but you won't have defended anything in doing so.
[deleted]
Well, bugger. Thank you for the correction.
It's a great article. Glad to help :)
Whenever I read articles like this filled with buzzwords and a LinkedIn way or looking at the world, I am always under the impression that the main driving force behind the busyness and burnout is just the fact that it's all unimportant nonsense and the worker is aware of it whether on a conscious or unconscious level.
"Leader-ofleaders"? We are talking about attention economy software and scrum meetings, not Hannibal crossing the goddamn Alps.
"Leader-ofleaders"? We are talking about attention economy software and scrum meetings, not Hannibal crossing the goddamn Alps.
There was a saying: If you want something important to be done, give it to the busiest person, not to a person who is free.
The busy people tend to be more efficient and organized. You do not need to explain them what to do -- they can figure out themselves.
The people who have free time tend to require external motivation/explanation, so you will end up micromanaging them, wasting your own time.
The busy people tend to be more efficient and organized. You do not need to explain them what to do -- they can figure out themselves.
The people who have free time tend to require external motivation/explanation, so you will end up micromanaging them, wasting your own time.
Some people are very good at appearing busy or at making themselves busy by being inefficient or by adding unnecessary steps and noise to the thing that needs doing.
> There was a saying: If you want something important to be done, give it to the busiest person, not to a person who is free.
> The busy people tend to be more efficient and organized. You do not need to explain them what to do -- they can figure out themselves.
Sounds like a great recipe for burning out your highest performers.
> The busy people tend to be more efficient and organized. You do not need to explain them what to do -- they can figure out themselves.
Sounds like a great recipe for burning out your highest performers.
Also people look busy for all the wrong reasons. It’s a ridiculous rule of thumb. Like the ‘he did $1M of damage on his first day, why fire him, I spent $1M’ training him’. The odds are the new hire is a fool who will repeatedly make costly mistakes.
If you think this, just fire the people with free time.
It is false that someone with free time has it because they are incompetent. It is false that someone who needs up-front hand holding needs it throughout an assignment.
I need a decent amount of explanation to wrap my head around concepts, but once I have the prerequisite information and the tools I need to develop a tool, I can do it.
And like others said, "give the busy people all the work" is how you get your top workers to navigate to LinkedIn.
It is false that someone with free time has it because they are incompetent. It is false that someone who needs up-front hand holding needs it throughout an assignment.
I need a decent amount of explanation to wrap my head around concepts, but once I have the prerequisite information and the tools I need to develop a tool, I can do it.
And like others said, "give the busy people all the work" is how you get your top workers to navigate to LinkedIn.
Or, hear me out: save yourself the trouble and don't build a team of people needing micromanagement in the first place.
What does this mean: "We’ve modeled the architecture, work, and communications of the team(s) as effectively as you can (with respect to what you can influence)"
I get modeling systems, but can someone enlighten me? This seemed like a straightforward and high quality article, so I'd like to understand every inch of it.
I get modeling systems, but can someone enlighten me? This seemed like a straightforward and high quality article, so I'd like to understand every inch of it.
Great question! I'll try my best to explain, though it's late and I may ramble – apologies in advance.
(You said you understand this bit but I'll put it here too just incase someone else could benefit). By modelling "the architecture", I'm referring to the architecture or the design of the system where work is happening. Think, for example, whether it's a system composed of many small components (modules, micro-services, micro-frontends, mono-repo), or a single large application (more traditional monolith).
By modelling "work" I mean: how do you distribute the work and the ownership of that work to teams. You can't easily have teams that share ownership, because if everyone is responsible then no one is. And you need to ensure responsibility for work is clear. For example, what are the outcomes you need from the other team building out that new API? Does your team also integrate code into those services that the other team are building? Probably not, but for some it isn't always clear. And if it's fundamentally required, how can you have many teams effectively contributing code to a single service without stepping on each other's toes and dilluting the concept of ownership?
By "communications of the team(s)" I mean to say that you need to influence how teams communicate. In a perfect world, all teams would be perfectly autonomous and never need to have the overhead of talking to or depending on another team to deliver work. In reality, teams need to communicate but there are different models to facilitate this (self service systems, service oriented software design, documentation, etc.). Organic collaboration can be harmful as companies grow beyond certain limits if not kept in check. The book Team Topologies by Matthew Skelton is a deep dive on this topic if you find that interesting.
I hope that answers your question.
(You said you understand this bit but I'll put it here too just incase someone else could benefit). By modelling "the architecture", I'm referring to the architecture or the design of the system where work is happening. Think, for example, whether it's a system composed of many small components (modules, micro-services, micro-frontends, mono-repo), or a single large application (more traditional monolith).
By modelling "work" I mean: how do you distribute the work and the ownership of that work to teams. You can't easily have teams that share ownership, because if everyone is responsible then no one is. And you need to ensure responsibility for work is clear. For example, what are the outcomes you need from the other team building out that new API? Does your team also integrate code into those services that the other team are building? Probably not, but for some it isn't always clear. And if it's fundamentally required, how can you have many teams effectively contributing code to a single service without stepping on each other's toes and dilluting the concept of ownership?
By "communications of the team(s)" I mean to say that you need to influence how teams communicate. In a perfect world, all teams would be perfectly autonomous and never need to have the overhead of talking to or depending on another team to deliver work. In reality, teams need to communicate but there are different models to facilitate this (self service systems, service oriented software design, documentation, etc.). Organic collaboration can be harmful as companies grow beyond certain limits if not kept in check. The book Team Topologies by Matthew Skelton is a deep dive on this topic if you find that interesting.
I hope that answers your question.
Thank you. A quibble: "model" may not be the best choice of verb here (it's what threw me off). I think "have well understood processes in place" is what you're trying to communicate, which is both "model" and "adhere".
Thank you – I think of "model" as meaning the way I think about, reason, and communicate an idea. But I completely see how that usage is not idiomatic. I appreciate the feedback.
Those of us who loathe laying off good employees are busy because we are understaffed. We're understaffed because we are sure that a downturn, recession or worse is upon us (or coming soon) and that the agony, expense and distraction of layoffs (to equalize income & overhead) are a bear market squeeze not worth the bull market juice.
So we get by with fewer employees, more part-time & gig workers. We work harder than we probably should, and so do our employees. The imbalance this creates in good times is offset by the job security we enjoy in bad times. How do I know this is true? Because I'm old enough to have withstood three recessions, the last one by the skin of our corporate teeth.
We've had two good employees leave in good times for less work for more money. Both came back after a few years when boom business cycles that drove that dislocation reverted to the mean.
What the "anti-work"/"no wagie" crowd get's right is the inequity of hard work in a commoditized job at a company that doesn't give a rat's ass about you or your work product. What they get wrong is that small businesses like mine, who do care, require hard work to smooth the volatility - providing security for the business, the employees & the owner. We do this while insurance (health & general) rockets skyward, as the government stealth taxes the crap out of us, and while foreign competition engages in currency & regulatory manipulation for unfair advantage.
My advice to the "don't be so busy" folks... get busy. Do a good job and tactfully take credit for it. Work hard and make sure your name is associated with results.
An economic storm is probably coming as soon as politically motivated band-aids come loose. Most likely after the US mid-term elections, but perhaps after 2024 if they can somehow postpone it that long... get ready.
So we get by with fewer employees, more part-time & gig workers. We work harder than we probably should, and so do our employees. The imbalance this creates in good times is offset by the job security we enjoy in bad times. How do I know this is true? Because I'm old enough to have withstood three recessions, the last one by the skin of our corporate teeth.
We've had two good employees leave in good times for less work for more money. Both came back after a few years when boom business cycles that drove that dislocation reverted to the mean.
What the "anti-work"/"no wagie" crowd get's right is the inequity of hard work in a commoditized job at a company that doesn't give a rat's ass about you or your work product. What they get wrong is that small businesses like mine, who do care, require hard work to smooth the volatility - providing security for the business, the employees & the owner. We do this while insurance (health & general) rockets skyward, as the government stealth taxes the crap out of us, and while foreign competition engages in currency & regulatory manipulation for unfair advantage.
My advice to the "don't be so busy" folks... get busy. Do a good job and tactfully take credit for it. Work hard and make sure your name is associated with results.
An economic storm is probably coming as soon as politically motivated band-aids come loose. Most likely after the US mid-term elections, but perhaps after 2024 if they can somehow postpone it that long... get ready.
That's great for you, but this is rarely, if ever, logical for the employee. This is very much a "you should be happy with your stable, lower wage job because it's stable" argument that is frequently used to suppress wage increases.
As an employee, the only thing that really matters is the dollars flowing out of your account into mine on a regular basis. Trust, job security, growth opportunities, work life balance... they're all just words until they're not. Unless you're willing to sign a multi-year contract guaranteeing job security, put your money where your mouth is or I'm out the door as soon as greener pastures present themselves. And in this industry, there's always greener pastures.
> We've had two good employees leave in good times for less work for more money. Both came back after a few years when boom business cycles that drove that dislocation reverted to the mean.
Sounds like they were properly maximizing their opportunity.
Alternatively, give people job security and also pay them what they deserve. It works even better than whatever "the mean" is.
As an employee, the only thing that really matters is the dollars flowing out of your account into mine on a regular basis. Trust, job security, growth opportunities, work life balance... they're all just words until they're not. Unless you're willing to sign a multi-year contract guaranteeing job security, put your money where your mouth is or I'm out the door as soon as greener pastures present themselves. And in this industry, there's always greener pastures.
> We've had two good employees leave in good times for less work for more money. Both came back after a few years when boom business cycles that drove that dislocation reverted to the mean.
Sounds like they were properly maximizing their opportunity.
Alternatively, give people job security and also pay them what they deserve. It works even better than whatever "the mean" is.
To add to this, There is no guarantee that the company that makes you hustle doesn't simply lay you off in the bad times anyway. I'd much rather earn an extra 20% for 5 years and have 1 extra year's cash in the bank, then work in a "stable" environment that may or may not think I'm worth having around in 5 years.
>Trust, job security, growth opportunities, work life balance... they're all just words
Or not, if you have been at a good company where people got treated well, with good bonuses, great healthcare, tons of time off and job security during recessions and times when an unscrupulous company could have fired people.
A lot of people are asserting that companies and business owners are physically and psychologically incapable of anything except slitting throats at the earliest opportunity.
Or not, if you have been at a good company where people got treated well, with good bonuses, great healthcare, tons of time off and job security during recessions and times when an unscrupulous company could have fired people.
A lot of people are asserting that companies and business owners are physically and psychologically incapable of anything except slitting throats at the earliest opportunity.
I mean....what's a realistic split on this? 95/5 bad to good? If these unicorn companies exist those jobs are vanishingly rare because people wouldn't move, correct? Im 'young' and I don't know I would ever give a company the benefit of the doubt. Been screwed too many times
I've worked at a private fortune 100 company and a publicly traded company and both had their ups and downs. I get compensated substantially more at the public one, but as a consultant of sorts, the work ethic and vacation expectations are a bit more... Documented. Either way, I must have been lucky to have 10 of 12 years with entirely competent and hard working managers, good vacation and so on. I liked almost every coworker I've had and pre COVID, we would get lunch or coffee together every day and chat about work and life.
If anything, I've lost some sense of purpose and direction, partially due to societal upheaval and partially due to depression and burnout. But I have never hated my job or been afraid of losing it.
If anything, I've lost some sense of purpose and direction, partially due to societal upheaval and partially due to depression and burnout. But I have never hated my job or been afraid of losing it.
> Or not, if you have been at a good company where people got treated well, with good bonuses, great healthcare, tons of time off and job security during recessions and times when an unscrupulous company could have fired people.
Unless you have this in ink or blood it's not guaranteed any more so than at a bad company where people get treated horribly.
Don't ever delude yourself into believing that the paradise of today will survive to see tomorrow. All the best companies even include this in their financial statements:
> Past performance is not indicative of future results.
We've been living in the very good times.
Unless you have this in ink or blood it's not guaranteed any more so than at a bad company where people get treated horribly.
Don't ever delude yourself into believing that the paradise of today will survive to see tomorrow. All the best companies even include this in their financial statements:
> Past performance is not indicative of future results.
We've been living in the very good times.
> providing security for the business, the employees & the owner
The problem is that everything you've described only provides stability for the owner, and no one else. There's zero reason for an employee to believe money in your bank account somehow provides for their security -- even if you are honest and ethical and magically choose to do it, no one else ever does -- there is no way a reasonable person can believe the owner is just going to keep them on through hard times, just out of the goodness of their heart.
The problem is that everything you've described only provides stability for the owner, and no one else. There's zero reason for an employee to believe money in your bank account somehow provides for their security -- even if you are honest and ethical and magically choose to do it, no one else ever does -- there is no way a reasonable person can believe the owner is just going to keep them on through hard times, just out of the goodness of their heart.
Not only stability for the owner. Stability for the business. Which is where the money for salaries comes from.
Owning a business for a number of years was a very eye opening experience and has made me a much better employee and I'm in agreement with OP.
Owning a business for a number of years was a very eye opening experience and has made me a much better employee and I'm in agreement with OP.
>even if you are honest and ethical and magically choose to do it, no one else ever does
That's right, literally no employer ever does right by their employees in tough times except for this one HN commenter.
Or to put it non sarcastic, it's entirely possible for an employer not to be a bastard, even if it is less common than the opposite.
That's right, literally no employer ever does right by their employees in tough times except for this one HN commenter.
Or to put it non sarcastic, it's entirely possible for an employer not to be a bastard, even if it is less common than the opposite.
People are expected to keep savings to weather through the lean times, and corporations should do the same- set up a fund to keep valued workers through lean times.
From personal experience, you can do good work and still be laid off. I got laid off a couple months after the company's president gave himself a 5M bonus, fully aware a recession was ongoing and that measures would have to be taken.
From my perspective many businesses are very happy to have people stick around to do the work with less pay, dur8ng good times they give the profits of this labor to the people at the top + shareholders and then when a downturn comes they trim off workers. They could have kept the people they laid off and paid everyone more if they'd (rather than giving bonuses to executives) put that money away for a rainy day. I don't see the benefit of having loyalty and working yourself to the bone when the people you're working for have lots of loyalty to the bottom line, themselves, and their investors, yet very little to the quality of life of the people who work under them.
Sure, I'm willing to work crazy hours and do whatever needs to get done but I expect to be met halfway and be respected (preferrably properly compensated) for the sacrifices I'm willing to make for the work I do.
From personal experience, you can do good work and still be laid off. I got laid off a couple months after the company's president gave himself a 5M bonus, fully aware a recession was ongoing and that measures would have to be taken.
From my perspective many businesses are very happy to have people stick around to do the work with less pay, dur8ng good times they give the profits of this labor to the people at the top + shareholders and then when a downturn comes they trim off workers. They could have kept the people they laid off and paid everyone more if they'd (rather than giving bonuses to executives) put that money away for a rainy day. I don't see the benefit of having loyalty and working yourself to the bone when the people you're working for have lots of loyalty to the bottom line, themselves, and their investors, yet very little to the quality of life of the people who work under them.
Sure, I'm willing to work crazy hours and do whatever needs to get done but I expect to be met halfway and be respected (preferrably properly compensated) for the sacrifices I'm willing to make for the work I do.
As a business owner myself this is total nonsense. I proudly pay my staff well and I don't overwork them. Anything else is a choice and it's a choice that nearly always benefits you not your employees.
Yes.
Sounds like an unprofitable business where the owner refuses to accept reality that the work conditions are marginal because the business is marginal.
Sounds like an unprofitable business where the owner refuses to accept reality that the work conditions are marginal because the business is marginal.
Business cycles sensitivity = marginal business?
Big cyclical reversion on its way that will test your theory wherever you are employed.
I think busyness, work hours, productivity, and context switching are all conflated with each other. They're interrelated but not the same.
When a lot of people talk about being busy, they're not so much saying "I had to do 50 hours of focused work this week," they're saying "I did 10 hours of focused work, because clients kept emailing me and we had a bunch of meetings, then our biggest customer's DB got corrupted for preventable reasons and we had to recover it, but we never test our restore process and so it all went wrong."
This is touched on in the grey box side-note and elsewhere in the article. Writing software is not usually a factory floor job where hours worked is linearly correlated with output. Removing slack from your team (not the app, the "free time" that gets filled with urgent incoming tasks or maintenance work) has long-lasting consequences for everyone that may be counterproductive.
When a lot of people talk about being busy, they're not so much saying "I had to do 50 hours of focused work this week," they're saying "I did 10 hours of focused work, because clients kept emailing me and we had a bunch of meetings, then our biggest customer's DB got corrupted for preventable reasons and we had to recover it, but we never test our restore process and so it all went wrong."
This is touched on in the grey box side-note and elsewhere in the article. Writing software is not usually a factory floor job where hours worked is linearly correlated with output. Removing slack from your team (not the app, the "free time" that gets filled with urgent incoming tasks or maintenance work) has long-lasting consequences for everyone that may be counterproductive.
>We've had two good employees leave in good times for less work for more money. Both came back after a few years when boom business cycles that drove that dislocation reverted to the mean.
Did they experience a pay increase between leaving and coming back?
Did they experience a pay increase between leaving and coming back?
Because large organizations are slow to respond to market forces, it is typically easier to get a rise by leaving and coming back than by staying on, which is a shame.
Worse, in many places, people who stay on for half a decade or more are assumed permanent fixtures ("Bob has been here forever, he doesn't want to leave, or he can't get a job elsewhere") that are unlikely to ever leave, and therefore may be ignored when salary adjustments are conducted.
Worse, in many places, people who stay on for half a decade or more are assumed permanent fixtures ("Bob has been here forever, he doesn't want to leave, or he can't get a job elsewhere") that are unlikely to ever leave, and therefore may be ignored when salary adjustments are conducted.
> My advice to the "don't be so busy" folks... get busy. Do a good job and tactfully take credit for it. Work hard and make sure your name is associated with results.
If you are in a dysfunctional org this will be very hard to do. What you think is a great outcome can be overshadowed because in 500ms some higher up decided it was a shit outcome. And customer/boss is always right is the culture in general.
You need to be busy on the right things. And the right thing might be brushing up the resume. Or it might be pulling an all nighter at the current job and bragging about it the next day. Or managing the manager. Or it might be giving yourself a break, by taking leave. But it is never clear, you just have to decide.
If you are in a dysfunctional org this will be very hard to do. What you think is a great outcome can be overshadowed because in 500ms some higher up decided it was a shit outcome. And customer/boss is always right is the culture in general.
You need to be busy on the right things. And the right thing might be brushing up the resume. Or it might be pulling an all nighter at the current job and bragging about it the next day. Or managing the manager. Or it might be giving yourself a break, by taking leave. But it is never clear, you just have to decide.
Or, you know, I could stay at the same company I’ve been working for for more than 20 years that pays me a hefty six figure salary and I maybe put in 30 hours of work a week.
Or you maximise your income during good times, accept layoffs (vacation) during bad times, ride out the difference by being smart with money and making good investments, and in the end you've made the same money but had far more free time.
Thanks, I mostly see the employee perspective here, good to see the perspective of an employer responsible for other people's stability.
I don't think a lot of people expect small businesses to make up for a largely unequal and unfair economic system. That should be the an atribution of government and society as a whole.
"more part-time" are there more part-time positions due to recession (or fears of one)? Are there job board for part time jobs, ideally remote?
did we read the same article?
[deleted]
Context switching and interruptions can make you busy really quickly
If i like doing what i do i just get busy, no sense of time
I was thinking to myself as I read this: "this man has never worked somewhere long enough to be the guy who has to fix things when it breaks", and lo-and-behold, he's had 7 jobs in 8 years.
Aha.. like an engineer who's never supported the product they shipped. Lotta talk.
I agree in spirit with everything he wrote. Except that it's just not real life, even when I've worked for businesses FLUSH with cash to "do the right thing". Even after saying almost his exact words to an otherwise intelligent boss, quantifying my point, and being proven right when I predicted his optimistic plan didn't work. Reality is messy when you peel back the first layer.
I agree in spirit with everything he wrote. Except that it's just not real life, even when I've worked for businesses FLUSH with cash to "do the right thing". Even after saying almost his exact words to an otherwise intelligent boss, quantifying my point, and being proven right when I predicted his optimistic plan didn't work. Reality is messy when you peel back the first layer.
Thanks for pointing out. Someone who can’t hold a job for more than a year on average in almost a decade isn’t someone i would take team/engineering advice from.
> can’t hold
That's a bit presumptuous. He could have left for better opportunities.
That's a bit presumptuous. He could have left for better opportunities.
Don't sweat it - It's easy to gatekeep when your job is your identity
It really seems to be the case that "those who can, do; those who can't, teach"
The people who are really doing usually aren't wasting their time waxing poetic about stuff like this. They are too busy doing. So we are left with all the not-really-doers to bless us with their incredibly profound musings on things they understand poorly.
The people who are really doing usually aren't wasting their time waxing poetic about stuff like this. They are too busy doing. So we are left with all the not-really-doers to bless us with their incredibly profound musings on things they understand poorly.
And here I was thinking my 3.5 yr average was on the low side.. (I mean it really is but I feel slightly better now).
The other thing you learn working at one organization for a long time is what matters for that organization (and it’s stakeholders) value. That’s almost never getting one random deployment out the door, or implement new industry best practices/technologies.
[deleted]
The correct question should be "What can we NOT do?" - and usually there's a long list of things that don't generate business value - from processes, meetings, reporting and overly detailed planning sessions to technical hurdles including slow builds, pre-check in hooks, sign off requirements etc.
I know that most feel that they absolutely HAVE to do these things, since there are part of the business process/ definition of done/company guidelines etc... but here's the thing: If your team delivers value, people stop asking questions. It might take some forceful pushback and even some fights initially, but even if your team is absent from meetings or doesn't jump through every hoop, as long as you churn out value, you make yourself, your superiors and the business as a whole look good and in turn will be cut some slack.