Why are you so busy?(tomlingham.com) |
Why are you so busy?(tomlingham.com) |
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.
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.
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 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".
So cut yourself some slack too. The balance of that might not be obvious.
> 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
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.
doing anything else is pretending project managers are managers
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.
“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.“
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.
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.
> “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.
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.
You entered this state.
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 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.
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: "ಠ_ಠ"
https://www.goodreads.com/book/show/54785515-four-thousand-w...
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?
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.
Die on this hill :) You'll certainly die on a sword, but you won't have defended anything in doing so.
"Leader-ofleaders"? We are talking about attention economy software and scrum meetings, not Hannibal crossing the goddamn Alps.
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.
Sounds like a great recipe for burning out your highest performers.
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.
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.
(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.
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.
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.
That's a bit presumptuous. He could have left for better opportunities.
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.
"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.
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
"Smooth is fast kids, smooth is fast!""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.
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.
It blew my mind that anyone at Microsoft, of all places would have this mindset.
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.
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...
"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.)
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.
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.
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.
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.
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.
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.
Sounds like an unprofitable business where the owner refuses to accept reality that the work conditions are marginal because the business is marginal.
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.
Did they experience a pay increase between leaving and coming back?
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.
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.
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.
> 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.
In the ballpark of 20ish engineers chasing build errors and test failures for a month to bump a version number (one line change).
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 :).
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.
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.
> 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.
You need a hardware testing engineer who can automate the tests that you're currently running manually.
The CI is not the problem, sure. But it is not the solution either. That was my point.
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.
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.
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'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.
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.
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.