Task like a 19th century Prussian general

Tasking people effectively is very hard to do, as I've learned in my late 20s, my first time being a manager-architect of a developer team. Now in 2026, when every developer (and soon every office worker) have teams of AIs standing at their command, tasking is not a niche skill anymore that only 5% of the population needs to know.

My personal method, honed from years of personal mistakes, turned out to be very close to "Auftragstaktik", invented by Prussian generals in the 19th century, and often translated as "Mission Control" or "Commander's Intent".

(If you are interested in the military history, there are lots of military sites to read about it.)

I make it easier for myself to remember by calling mine the:

"B.O.S.S." method #

• Background (Why): The goal. Why is this needed? Big picture.
• Outputs (Outcome): How the outcome looks like? Output format.
• Scope (Boundaries/constraints): What this should and should not cover. What not to do?
• Steps/Strategy (Execution): This one depends on trust in the individual and risk of the task, how high or low level.

The basic idea is so your people (or AIs) can autonomously adapt when the plan breaks, instead of freezing, blindly following, or going astray*. Humans work where you can't easily see them (in their brains), and AI just types too fast to watch all the time. Ultimately, both are somewhat uncontrollable.

How does this look like in practice? #

• Background: "We need to keep control of our spending across multiple API providers, because I'm worried we might run up high costs without even realizing".

  (Notice that this has to do nothing with the task directly. But the developer will make tons of decisions while coding, and knowing why the task is needed keeps them from going "into the forest". For example, this keeps them from spending resources on fetching and storing unnecessary, unrelated data - clearly, just the spending data is enough.)

• Outcome: "So we need a way to get logs from each of ours providers, and have a unified dashboard to see our spending as real-time as possible."

  (This is how the outcome should look like. Is it a one-time document? No. Is it only a database table? No. Updated how often? Very. This keeps them from doing a one-time, manual check, for example; or from being content with a solution that runs for hours.)

• Scope: "This should be in our internal ERP system." (It's not a separate tool. This also implicitly specified DB, tech stack, CI/CD, etc.) "Tell me if it's starting to take more than 1-2 days, or there's a hold-up."

  (If it gets out of hand, I want to know -- I might help with higher-level decisions. ("So you say, provider X's auth is braindead. Hmmm, but I know we have pre-paid credit with them, so it's impossible to run up high costs unnoticed. Forget it.")

• Steps/Strategy: This is somewhat optional, and depends on the circumstances:

  If the person is either new, or prone to mistakes, it's better the break down the task to subtasks. ("Add a new table called X, with these and these fields. Create a new "API costs" report under the Reports section. Make autotests to prove that the sums are correct with multiple providers. ...")

  If you already trust the person with the task but there are several possible approaches, then guide on which one to do. ("Try to put all providers in the same table, I don't want DB changes every time a new provider is connected.")

  On the other hand, if it's a very dangerous, delicate task, with lots of background knowledge and high cost of mistakes, then I might specify steps even for my best developers.

(P.s.: turns out the right expression is "going astray", not "going ashtray" 😆 But that always made SO MUCH more sense to me...)