Putting Jedi Techniques to the Test
Should PMs read Jedi Techniques by Maxim Dorofeev? A look at which ideas from the book actually earn their place in project work.
Jedi Techniques by Russian author Maxim Dorofeev came out in 2017. I read it pretty much as soon as it was published. Over the years, I’ve worked my way through a fair amount of professional reading. Not every book has stuck with me. A PM’s working memory does a decent job of handling client wish lists, deadlines and other people’s commitments. Everything else gets whatever capacity is left.
Which makes it all the more interesting that I still remember some of Dorofeev’s ideas. It’s a book about personal productivity, but several of its principles work just as well in project management. Let’s look at what’s actually useful and where the Jedi techniques end and plain old PM work begins.
The team’s mind fuel
One of Dorofeev’s central ideas is “mind fuel”, a limited resource for focused mental effort. On a project, difficult tasks aren’t the only things that use it up. Badly organised processes do a pretty good job too.
A developer asks for clarification on the requirements for the third time. An analyst explains the agreed logic all over again. The PM gives the client yet another recap of the last meeting. Everyone’s busy, but the time is going into piecing information back together. So check where decisions are recorded, who keeps the requirements up to date and why the team keeps revisiting the same questions. Sometimes good documentation saves more time than another attempt to make development go faster.
Make the task clear
One useful principle in the book is to write tasks as concrete actions. That alone won’t cover everything project management needs. Clarity is still a good place to start.
“Finish the integration” or “sort out authentication” are excellent task descriptions if you fancy spending half an hour later working out what anyone meant. A proper brief needs an expected outcome, the necessary context and clear acceptance criteria. Instead of “test the integration”, list the test scenarios, say where to log bugs and explain what a passing result looks like.
The book’s “next action” principle doesn’t replace breaking work down or writing a spec. Complex features still need estimates and a proper look at scope, dependencies and constraints. Clear wording does cut down a lot of the back-and-forth, though.
A priority label won’t make development faster
Dorofeev makes a fairly sharp observation:
“You can set a deadline, assign a priority and explain how important a task is. Often, though, that does more to make the person responsible feel guilty than to change when the task gets done, or whether it gets done at all.”
You see this on projects all the time. A PM marks a task as high priority, sets a deadline for tomorrow and expects it to somehow move faster. But a new label doesn’t free up a developer’s time or cancel their existing commitments.
An urgent request means reviewing capacity and the order of work. Sometimes you have to push back less important tasks, negotiate with the client or admit the proposed deadline isn’t realistic. Especially when “ASAP” is the entire business case for the priority.
Open loops
Another useful idea is to record commitments and check on them regularly. For a PM, that connects directly to managing dependencies.
The client is signing off on designs. A vendor is setting up access. A developer is estimating a change. If all of that is just sitting under “Waiting”, there’s very little to manage. Every open item needs an owner, an expected action and a follow-up date. If it affects the timeline, you also need a clear escalation path.
The same goes for meetings. Record the decisions and next steps, then assign owners. Otherwise the next call may well start with another discussion of the last one. Very productive.
Where the Jedi stuff stops
Useful as the book is, its methods don’t replace project management. Dorofeev helps you handle information, tasks and commitments. Resource planning, budgeting, risk management and change control still need their own tools.
There’s no need to turn every tip into mandatory company policy either. If the team is getting work done, adding procedures just to comply with a method is fairly pointless. Sometimes all you need is a clearer task description or an agreement on where decisions go. You don’t have to rebuild the entire workflow.
I think Jedi Techniques is worth a PM’s time. Especially if agreements keep getting lost, tasks keep coming back for clarification and the same questions get discussed again and again. Pick tools that address the team’s actual problems. Just don’t get so carried away rolling them out that you end up optimising the processes you created to optimise your processes.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.