It's my first time starting a physical, retail business and it has been quite an education in the small details.

There is no job where all work is equally important, where all ideas are equally good. Even in emergency rooms, where triage is a vital concept. I think it's ok if finding a new poster for the break room gets dropped because there's too much work treating patients right now.

That said, your answer here tells me what I need to know about the product.

One of the big benefits of a physical kanban board is that the limited space means people only write down the stuff they really care to keep track of. For me it has never resulted in people forgetting anything important. It means they don't write down the unimportant stuff.

It's possible that some people would write down a lot of trivia or fantasy features, especially to start. The best response to that is to let them write the cards and then sort them according to actual priorities. But I've never seen anybody persist in that behavior very long. If they do, I think it's a sign of organization problems that tools can at best mask, never fix.

I think this can also be true of virtual kanban boards (e.g., GitHub's kanban view) if you keep people focused on the kanban view. Then they learn to focus on what's being worked on and the near-term to-do list. You can have a backlog column and let people fill it up as much as they want, but as long as you groom the top 20 cards or so to be your actual current priorities, people eventually adapt.

These days I'm on an all-remote team, and we use GitHub's kanban interface with WIP limits. That also works fine, and them main difference form how I worked back then is that we no longer do estimates.

I'm not sure what went wrong for you, but my strong suggestion is not to think of it as a task board. Think of it as a board that lists units of value. E.g., features delivered, research completed, messes cleaned up. We do sometimes make task breakdowns for cards, but that happens as we start work on the card, and it's just a checklist somewhere (for us currently, in the GitHub issue via Markdown checklists).

An important mindset shift for a lot of teams to use kanban boards well is to get away from siloing and toward collaboration. For my teams, cards were generally not individual achievements, but things we collaborated on.

I think it's also important for software teams to have a BLOCKED column between TODO and WORKING. The only cards that should count against your WIP limit are the ones that people are truly working on that day. If there's something you can't work on for some external reason, move it to BLOCKED. Then before a card is taken from TODO, try getting any BLOCKED item going first. It's also worth talking in your retrospectives about common reasons things end up blocked, and I like to set a pretty low limit for blocked cards to force discussion.

Happy to discuss further, but kanban approaches definitely work well for software.

You must be working very hard to not understand that, as it's very simple. They signed up for a job on a thing called the Death Star. Its only job is to commit genocide at a planetary scale.

They are morally responsible for the consequences of their choices. We all are. Getting paid doesn't negate that. If anything, it amplifies it.

I get that you (and most of them) want to cash the checks without feeling responsible. Tough. People make the choice to work there, and they make the choice every day to keep working there. Other people get to make choices too, including about how they think about, describe, and treat people who profit from harming others.

Freedom of speech and freedom of action does not include freedom from consequences. Your freedom, or that of people making bank at Meta, is not more important than anybody else's freedom.

Those have always been good questions to ask, but especially these days.

What I think he's sincere about is not wanting to work at a place that builds unnecessary stuff. And if people are asking for answers that require building unnecessary stuff, I think it's a reasonable inference that the place is not right for him.

I think interviewing is always a two-way street. If I got the feel that a place was going to have a lot of over-complicated code for me to deal with, or expected a lot of status-driven deference against actual user and business need, I wouldn't just give an interview-ending tart reply. But I would politely finish out the interview and then write them off unless there were other signals that redeemed the bad interview questions.

If I want them to give me a different kind of technical answer, then I think it's on me to ask a question that actually requires what I'm looking for. It's not hard! All the Stripe interviewer had to say is, "Ok, great. It sounds like you have a good sense for system capacity. Now let's add another zero to all the load numbers." And then keep increasing orders of magnitude until they learn what they're looking to learn.

I am, just to be clear, not defending people being willfully obtuse or contrary jackasses. But that's not the scenario being described in either the Stripe story or the Google Sheets story I'm responding to. Two apparently reasonable people were asked technical questions and they gave answers that were the right thing for the business.

I think that's good and I like to hire people like that. I get lots of others don't, and I get the POSIWID reasons behind it. But I'm not going to pretend I think it's a healthy way to run an organization. And I also get that the people who like pretense and deference in interviews are not going to like me saying so. ¯\_(ツ)_/¯

If I go to a doctor and say, "Hey, please prescribe me a lot of morphine," the answer will be some version of "hell no". That's because doctors, even if you pay for the visit, have responsibilities to the patient, the profession, and society at large. Responsibilities that should not be overridden by money or power.

The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it. We're often more like the minions in a supervillain's volcano lair: whatever the boss says, we do.

We could be different, though. There's the ACM code of ethics, for example: https://www.acm.org/code-of-ethics

Or the IEEE-CS code of ethics specifically for software: https://www.computer.org/education/code-of-ethics

We could, as a profession, agree to follow those. We could build an organization that supports people who do the right thing in the face of managerial pressure. We could censure those who don't. I'd love to see it happen, but I'm not going to hold my breath.

To rethink hiring, you have to spend some time understanding why most hiring is terrible both in terms of candidate experience and actual result. In my view so much of both hiring and general business operations is about managerial status and ego. https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

I think all of those tendencies come to the fore at any organization that doesn't have either a strong sense of mission or a sufficiently desperate need for success that they pay attention to material reality rather than social reality. With a possible partial exception for things like co-ops and other places where the culture is fundamentally different enough. E.g., Mondragon, or Zingerman's.

I think Google, back in its don't be evil/organize the world's information era, probably qualified. They started with a very strong mission-driven culture rooted in academics and engineering. It took a fair bit of time for MBA dogmas to make it like most other places. But from everything I hear, what once felt almost like a calling now is just another job.

It's also terrible at that. Bitcoin is down by something like half off its peak. The odds of me losing money to "government intervention" if I'm not actively criming, are quite low. Certainly well under 50%.

> Bitcoin works because you can technically have your wealth memorized.

If you are having to reach for increasingly absurd fantasy scenarios to justify something that was supposed to have thoroughly quotidian users, maybe you should take that as a sign?

> because you have ideas which they do not agree with

Oh, that's who's using bitcoin the most? Philosophers and the like? I had no idea.

In my experience, it's much easier to train somebody on how to scale a basic system up in response to need than it is to get somebody who favors complexity to cut it back.

To make the interviewer feel smart and powerful? To hire people who will do the thing the boss wants whether or not it makes sense? To find people who will overdesign things to maximize resume impact and the ability of their bosses to talk about what sophisticated systems they're running and for which they therefore need a much bigger budget?