I needed to return from my too-long hiatus from writing before the end of July. Historically, I tend to take an extended break after the post-GDC writing deluge. Couple that with changes at my job, and my writing motivation took a hit this past month.
Anyway, I wanted to keep this post short and simply talk about the fulcrum. I'm going to assume that readers are fully aware of this simple physics/engineering concept. If not, all you need to know is that the "lever and fulcrum" is a means by which effort is used to lift proportionally greater loads than is possible through the direct application of effort/force on the load itself. It is also an apt analogy.
As a leader, you are constantly faced with seemingly binary decisions, or weighing factors. Here to, the lever and fulcrum diagram shows how much effort (man-hours, headcount, overtime) is required to raise the load (scope, quality). The fallacy lie in the fact that too many people focus only on the effort and load.
If you work in this industry, you are going to find yourself in a meeting where you are trying to find a load balance; look especially for those meetings where none of the solutions look appealing. It could be any of these topics:
- Outsourcing to meet production targets
- Overtime to hit milestone deliverables
- Additional headcount to backfill against potential attrition.
WARNING: When moving the fulcrum, do NOT then also increase the load (scope, quality expectations, shorter milestone, etc.). That is what we, in the industry, call: "screwing the team."
So, how do you move the fulcrum?
First, accept that the electing to move the fulcrum is a long-term play. When you don't have time, and most teams assume they don't even when they do, moving the fulcrum seems unreasonable. The pay out will take time, and the degree to which it pays out is not guaranteed.
Second, consistent advocacy requires you to understand that moving the fulcrum always pays off. Yes, that is in direct opposition to the previous sentence. Here is why. Moving the fulcrum is a strategic play and may have little to no immediate tactical benefit. The benefit may not be truly realized until some future project. However, the effort invested in simply trying to move the fulcrum, will bring greater understanding to why the load balance problem exists in the first place. Also, if you do not try to move the fulcrum, you will perpetually be stuck trying to balance the load -- and you won't know why.
Third, conscientiously select what type of fulcrum you're going to move. There is more than one and it must be used to address the most significant load-balance issue. I can't say I'd recommend trying lots of different fulcrums at once. Regardless, here are some fulcrums to consider moving the next time you face difficult load-balance issues.
- Training / Job Enrichment - diversify staff talent, bring new insights to the problem, employee retention and engagement
- Internships - fresh talent, new development approaches
- Tool Improvements / Tech Art expansion - improve the development environment, allow for faster iteration
- Team mobility - shift staff between projects in the middle of development rather than only at the end
- GTFO of the office - stop staring at the problem. get away from it so you can think about it again. This isn't a fulcrum at all. This is how you start to figure out whether you need one.
Focusing on the fulcrum is hard. The faster a team is moving, the more difficult it is to focus. You can't see the forest when you spend all day staring at trees. To mix metaphors and butcher them both at the same time: Don't stop chopping wood to sharpen your axe. Stop chopping wood so you can invent the fucking chainsaw, instead.
Fulcrum, baby!
