The editorial argues that France's 2017 law succeeded because it required companies to negotiate disconnection terms with worker representatives, producing nuanced policies that distinguish urgent vs. informational messages. Michigan's bill skips that mechanism entirely and instead imposes a statutory prohibition with undefined terms like 'emergency' and 'compensated for on-call status,' making it unlikely to survive contact with how modern software is actually built.
By submitting the CBS Detroit story to HN where it reached 247 points, cebert surfaced the bill as a noteworthy labor-protection development. The editorial notes that workers in finance and consulting cheered the bill on the thread, treating Michigan becoming the first U.S. state to codify right-to-disconnect as a long-overdue alignment with European norms.
The editorial reports that engineers on the HN thread raised operational objections — on-call rotations, distributed teams across time zones, incident response, and deploy windows don't map cleanly onto 'scheduled work hours.' Because the bill leaves 'emergency' and 'compensated on-call' undefined, software teams face ambiguity about whether routine after-hours coordination triggers civil penalties and a private right of action.
Michigan State Representative Matt Koleszar introduced HB 4922, the Workplace Boundaries Act, which would prohibit employers from requiring employees to monitor or respond to electronic communications outside of scheduled work hours. The bill covers email, Slack, text messages, and phone calls. Violations would carry civil penalties, with employees gaining a private right of action. The CBS Detroit story hit 247 points on Hacker News, which for a state-level labor bill is unusual signal.
The bill carves out exemptions for emergencies, on-call workers who are compensated for that status, and employees whose written job descriptions explicitly include after-hours availability. It does not define 'emergency.' It does not define what 'compensated for on-call status' means — whether that's a stipend, time-and-a-half, or just a salaried role with on-call duties baked in.
Michigan would become the first U.S. state to codify a right-to-disconnect, joining France (2017), Spain, Portugal, Belgium, Australia, and Ontario (which requires a written policy but no actual disconnection). The HN thread split predictably: workers in finance and consulting cheering, engineers asking the obvious operational question, and a small contingent pointing out that the bill, as written, doesn't survive contact with how modern software gets built.
The France precedent is instructive and the Michigan bill ignores most of what made it work. France's 2017 law didn't ban after-hours contact — it required companies with 50+ employees to negotiate the terms of disconnection with worker representatives. The mechanism was collective bargaining, not statutory prohibition. The result: large French employers like Axa and Michelin have nuanced policies that distinguish between 'urgent', 'expected response within 24 hours', and 'informational' messages, with explicit carve-outs for global teams and on-call rotations.
Michigan's bill skips that step entirely. It legislates the outcome (no required response) without legislating the process (how to define exceptions). This is the same structural failure as California's AB5 — a well-intentioned worker-protection law that turned out to be unworkable for the actual industries it touched because the legislature defined the destination but not the path. AB5 needed a parade of carve-outs (musicians, freelance journalists, truckers) before it stabilized. HB 4922 will need the same, and the carve-outs will determine whether it does anything at all.
The on-call question is the one engineers keep asking and the bill keeps not answering. A typical SRE rotation at a B2B SaaS company looks like this: salaried engineer, $180K-$240K total comp, primary on-call one week in four, expected to respond within 15 minutes to a PagerDuty page, no separate on-call stipend. Is that 'compensated for on-call status'? The bill says the job description must 'explicitly include' after-hours availability. If your offer letter says 'on-call rotation as part of role' — is that explicit enough? What about the engineer who joined three years ago when the team was small and on-call was informal, but now the company has a formal rotation?
Community reaction on HN was sharper than usual. One top comment: 'This is going to mean every job description in Michigan now has a paragraph about after-hours availability. Congratulations, you've solved nothing.' Another: 'France's law works because France has unions. Michigan doesn't. This will get litigated into uselessness within 18 months.' The pattern is consistent — practitioners see the gap between legislative intent and operational reality faster than legislators do. The bill assumes a binary between 'work hours' and 'not work hours' that hasn't existed for knowledge workers in 20 years.
There's also a federalism wrinkle. The FLSA already governs overtime for non-exempt workers. If a non-exempt employee in Michigan answers a Slack message at 9pm, that's already compensable time under federal law — the employer just has to pay for it. HB 4922 changes the question from 'must you pay' to 'can you ask at all', which is a meaningfully different regime and one that intersects awkwardly with how distributed teams coordinate across time zones.
If you run engineering in Michigan or have Michigan-based reports, three things to start thinking about now, regardless of whether this passes.
First, audit your on-call program. Is on-call participation in the written job description, or is it informal? Is there separate compensation, or is it bundled into base salary? If the answer is 'informal' or 'bundled', you're going to want to formalize before the regulatory environment forces you to. Stripe's on-call compensation framework — explicit stipend per shift plus comp time for actual pages — is a defensible template. Most companies just have 'on-call is part of the job', which under HB 4922's plain text is the worst possible position.
Second, instrument your after-hours communication. You probably can't tell me what percentage of Slack messages your engineers send between 7pm and 7am, or how many threads start in those hours and require a response. If a law like this passes in your jurisdiction, that data becomes the evidence in any wrongful-discipline claim. Tools like Time Doctor and even Slack's own analytics export will give you the baseline. Get the baseline now, while it's a curiosity rather than a deposition exhibit.
Third, separate 'async-OK' channels from 'response-required' channels. The cleanest pattern I've seen: a dedicated #incidents or #pages channel that explicitly demands response, with everything else explicitly opt-in. GitLab's handbook does a version of this — async-by-default, escalation paths documented, expectations encoded in the team agreement rather than in implied norms. The bill, if it passes, will force every Michigan company toward something like this within a year. The companies that already operate this way will absorb the change in a sprint; the ones that don't will spend a quarter rewriting expectations.
HB 4922 probably doesn't pass in its current form — labor legislation in Michigan needs both chambers and the governor, and the on-call carve-out alone will require a rewrite once any tech-employer lobby reads the bill. But the direction is real: New York, California, and Massachusetts have all had similar bills introduced in the last 18 months, and Ontario's law is now four years old without the predicted apocalypse. The right-to-disconnect is moving from European curiosity to American policy debate, and the question for engineering leaders is not whether to prepare but how. The cheap version is to wait, lobby, and react. The expensive version — formalize on-call, instrument communication, document expectations — is also the version that makes your team better regardless of what any legislature does.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.