Management Tricks

The Actual State of Management Tricks

Most people treat management tricks like a collection of productivity hacks you can bolt onto a broken process and expect things to improve. That does not work. It makes the situation worse. I have watched teams spend six weeks trying a new ritual or adopting a dashboard system that added zero value to the actual work. The reason is straightforward. Management tricks are not a separate layer you apply after the work is figured out. They are the work itself, or they are nothing. Here is what I have found useful after dealing with this for years. The first trick is also the simplest one, which is why almost nobody does it properly. You track decisions alongside deliverables. Not outcomes. Decisions. When someone ships a feature or completes a report, the real information lives in what was decided along the way. The assumption they operated under. The constraint they accepted without documenting it. The alternative they dismissed and should not have. I used to ignore this until my team started producing perfectly polished output that solved the wrong problem three times in a row. The same misalignment kept repeating because nobody wrote down the reasoning. Once I started requiring a two-line decision log attached to every major deliverable, the repetition dropped to almost nothing. It took me about ten minutes each week to review those logs. Before that, I was spending hours firefighting rework. The second trick is less obvious and more controversial. You intentionally under-specify the middle of projects. Managers love to break work into tiny bite-sized tasks and assign them one at a time. This looks efficient on a Gantt chart. It slows real work down. Every time you pause to assign, clarify, and re-assign, you introduce a coordination tax. I learned this the hard way when I was managing a data migration for a client. I had mapped out three hundred individual tasks. The project took four months. We did not finish on time. When I redid the same migration the next year with the same scope, I only defined the entry criteria and the exit criteria. The team handled the middle themselves. It took six weeks. Not eight weeks. Six weeks. The difference was not better planning. The difference was removing the manager as a bottleneck between decisions.

There is a counter-intuitive point here that people miss. Management tricks only work when the team already has competence. If the people executing do not understand the domain, no amount of clever process design will help. You will just create a system where incompetent people follow steps incorrectly with extra documentation. The trick is knowing when to invest in people instead of investing in process. I once inherited a team that was drowning in status meetings, sprint reviews, and progress trackers. The problem was not the process. The problem was that three of the five people on the team had never built a production system before. I pulled them out of all the ceremonies for two weeks, paired them with senior engineers, and then slowly reintroduced lightweight check-ins. The process came back better than before because the people underneath it were actually capable now. This is not a management trick. It is a hiring and training problem wearing a management hat. Another trick that gets misunderstood is the use of pre-mortems. A pre-mortem is where you imagine the project has already failed and work backward to figure out why. Most people run these as a group exercise and get vague answers like "we might run out of time" or "scope could creep." That is useless. The trick is to make it personal and specific. You ask each person individually, in writing, what specific thing they think will go wrong, and you collect those answers before anyone shares them. I did this on a product launch that had every marker of a healthy project. Clean timeline. Committed stakeholders. Everything looked good. The pre-mortem revealed that the lead engineer had been quietly dreading a particular integration with an external API because the documentation was outdated. He did not raise it in the group session because he assumed he was the only one who noticed. That single dependency became the critical path delay. We ended up building a mock service to decouple from the external API. Saved about three weeks of downtime. The trick worked because it was individual, written, and collected before social pressure set in. There is a trick involving what I call constraint stacking that most managers never learn. You deliberately impose an artificial but tight constraint on one dimension of a project to force clarity in another dimension. For example, capping a development cycle at exactly fifteen days forces the team to cut scope aggressively and ship something real instead of building toward an invisible finish line. Capping the number of concurrent projects at two per person forces prioritization that would otherwise never happen. I have seen teams claim they are "too busy" to do anything differently. The moment you cap their capacity, they find a way. It feels harsh. It is not. It is just honesty about scarcity. The downside is that this trick requires a manager who can absorb pushback and tolerate short-term discomfort. If you are the type who caves when people complain, constraint stacking will look like punishment rather than a tool. I know because I used to cave. Then my teams learned they could get everything they asked for if they just complained long enough. That ended badly for everyone.

One more thing that is worth mentioning and rarely discussed. Management tricks fail completely when the organization measures activity instead of output. You can implement every process improvement in the world, but if your performance reviews reward hours logged, meetings attended, and tickets closed, people will optimize for those metrics and the tricks become theater. I worked at a company once where we introduced Kanban, daily standups, story points, and WIP limits. Everything you would expect. Within six months, the average story point count inflated by forty percent while actual velocity stayed flat. People were gaming the estimation system because estimation accuracy became a tracked metric. The management tricks created a parallel reality where the numbers looked healthy and the work was still delayed. The only fix was to stop tracking story points entirely and start tracking shipping dates against committed scope. Everything else was noise. The real management tricks are not tricks at all. They are just observations about how human systems behave that most organizations ignore because they are uncomfortable. Accountability is uncomfortable. Scope discipline is uncomfortable. Pairing underperformers with strong performers is uncomfortable. The tricks that last are the ones that require you to be honest about what is actually happening instead of managing the appearance of productivity.