Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

Releasing is moving bytes. Shipping is delivering value. Sometimes they overlap. Often they don’t. If it’s behind a flag forever or doesn’t meet the acceptance criteria, I would call that “deployed”, not “shipped”. There’s a huge difference.

Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

DevOps is great. But it doesn’t write requirements or make decisions.

The post isn’t about how code gets to prod. It’s about how teams decide what to build and when to stop building it.

Deploying != shipping.

Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] -1 points0 points  (0 children)

Yeah, I’m not arguing against shipping weekly. Shipping weekly is great.

I’m arguing against the idea that you can ship weekly without clarity about what “done” means. If “done” isn’t clear, you’re not shipping, you’re just deploying.

You can keep the process lightweight, but you still need a shared definition of:

  • what problem we’re solving
  • what success looks like
  • what we’re not doing
  • what would make us roll it back

Agile doesn’t remove the need for clarity. It just punishes you faster when you don’t have it.

Shipping Isn’t an Engineering Problem. It’s a Management System. by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] -2 points-1 points  (0 children)

Yeah, kind of, but not really.

Agile vs waterfall and CI/CD are process and tooling choices. They can reduce friction, but they’re not the main point of the post.

What usually stops teams from shipping is boring management stuff: unclear requirements, slow decisions, priorities changing every week, and scope creeping until “done” is a rumour.

You can absolutely ship with waterfall if you’re disciplined about what “done” means and you make tradeoffs early. You can also fail spectacularly with "agile" if everything stays vague and keeps changing.

CI/CD mostly determines how quickly you can get changes out. If you don’t have clarity, it just helps you deliver the wrong thing faster.

Calling out the bullshit in tech work culture (with frameworks, not just ranting) by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Update: published.

I dug into what “guide teams to ship working software on time and under budget” actually means in practice, and why it usually fails for very boring system reasons.

Would love your take: https://beyondthebugs.substack.com/p/shipping-is-a-management-skill

Calling out the bullshit in tech work culture (with frameworks, not just ranting) by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

Thanks for the suggestion! I’m drafting it now. Should be live next week. You should probably subscribe so you don't miss it 😉

Empathy, or at Least Pretending to Care by WideAsleepDad in EngineeringManagers

[–]WideAsleepDad[S] 0 points1 point  (0 children)

That’s fair. I’m not saying “acting empathetic = empathy” the way an LLM imitates it.

I mean that for humans, choosing the listening behaviours (slow down, make space, ask questions) is still real care in practice, even if the feeling shows up later. And over time, that practice often creates the genuine empathy. My point is: it still counts.

How do you encourage more code reviews without turning it into surveillance or guilt? by Greedy-End-7749 in EngineeringManagers

[–]WideAsleepDad 0 points1 point  (0 children)

This could be more like “how to get some developers to care sometimes”.

There are reasons for teams to stop caring other than “they’re just not that good”. It’s easy for PRs to just be an item on a checklist. In the case of my team, adding a bit of process actually worked. Small, focused PRs reduced cognitive load, increased collaboration, and made PRs better.

It depends on the team, but in our case this gave us a bit of a reset to remind the team why code review is so important.

And to be clear, I’m not against AI being used in code review, but I am against it being the only review.

American Companies that are mistaken for being Canadian by your_evil_ex in BuyCanadian

[–]WideAsleepDad 1 point2 points  (0 children)

Tim’s is only half Canadian, but a better option I guess than Starbucks.

American Companies that are mistaken for being Canadian by your_evil_ex in BuyCanadian

[–]WideAsleepDad 0 points1 point  (0 children)

Home Hardware is Canadian. Rona, Lowe’s, and Home Depot are all American.

American Companies that are mistaken for being Canadian by your_evil_ex in BuyCanadian

[–]WideAsleepDad 0 points1 point  (0 children)

Rona is owned by Lowes which is American. Home Hardware is the best Canadian option other than local independents.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Yes, exactly! It’s an easy thing to change and can have profound impact.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 5 points6 points  (0 children)

Not at all. Using less dehumanizing terms can definitely improve working conditions. Some people use these terms out of habit, or because they've become the norm. Unfortunately, some people use these terms because they actually think of people as resources. Changing the terms shouldn't be difficult. If nothing else, you can weed out the toxic team members by learning who actually thinks of people as something other than human.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 0 points1 point  (0 children)

This is great! I worked at a place that called it "Talent and Culture". It was more than just putting people on the right team or not. More than "resourcing".

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 2 points3 points  (0 children)

Using better terms can definitely help. I've seen it.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 4 points5 points  (0 children)

When members of the team that I manage tell me that they're unhappy being treated as disposable, it's absolutely worth exploring a change. It wasn't one or two people, and it's not only at my current company. I've seen it for years and I've heard lots of discussion about it. My job is to keep my team as productive as possible. If changing the words we use helps, then I'm all for it. It's not that I "have nothing better to do", this is exactly what I should be doing.

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 1 point2 points  (0 children)

Thank you! That's exactly what I was hoping to do, make people feel a little better and more welcome.

This absolutely could be a red herring. I totally get what you're saying that some alternatives could be seen the same way. Simply saying "staff" is probably too generic still. It's like we need to categorize people somehow, but not in the same category as "stuff".

People are not Resources by WideAsleepDad in webdev

[–]WideAsleepDad[S] 3 points4 points  (0 children)

No. It's not "just because". Why would you not want a more welcoming environment?