A poverty trap is “any self-reinforcing mechanism which causes poverty to persist.” If it persists from generation to generation, the trap begins to reinforce itself if steps are not taken to break the cycle.
Think of a poor person that can’t afford even to buy in bulk from the supermarket, and is therefore forced to buy things on an as-needed basis from the cornershop, more expensively. Perhaps an ATM that does not charge for withdrawals is far enough that they would need to take a bus to get to it. In terms of time, think of all the things you pay for to avoid wasting your time on. A poor person does not have that option.
A key characteristic here is investment. A poor person has no available funds to invest in things that would pay back their investment several times over, even in the short run. Investing in anything but the absolutely necessary short-term needs is simply not an option.
You can see how this situation might perpetuate itself, since lack of investment on day one leads to lack of investment on day two, etc. This applies to people as well as families, communities and entire countries.
I think the self-perpetuating cycle of poverty applies to software teams as well. An overloaded team cannot afford to refactor, learn a new technology or tool, spend time architecting things correctly, review security practices, or abstract things into new libraries etc. The only thing that the team can do is struggle to complete today’s items, exhausting even their internal reserves of stamina. Without being able to pause, reflect, reconsider, and improve, the only way is down. This is not just about technical debt. It’s also about exploiting opportunities for shortcuts that require some upfront cost.
It also strikes me that “Agile” and “Scrum” as practiced in large companies today is a fantastic way to get into the software development poverty trap. Thinking of nothing else than the completion of the current goals as set by the business stakeholders means that every next “sprint” will make things worse and worse.
I’ve always been fond of what I call “meta-work”, work that is at a higher level of abstraction and saves a lot of work on the object level. Considering the software development poverty trap, it becomes more obvious that at almost all times, a significant part of a team’s energy should be getting reinvested in improving the team’s productivity. A team that does this will not only have a better experience at work, but will deliver more, deliver better, and have the results be more useful over time. What may seem like a waste on the micro level is the difference between success and failure on the macro level.
If you’re managing a software team, consider postponing some work, or taking some less work on, or even, if possible, hiring some people with a mandate of delivering improvements to the rest of the team itself rather than to the customer. Some times the improvements are so drastic that they can pay off within a single period. You may just need to encourage your team to think in that direction. A team that invests in its own productivity will deliver more software, faster.
Crucially, that team will also keep its best performers on board, rather than losing them to a better environment. And a team that cannot keep its best people (and attract more like them) is in the ultimate poverty trap, doomed to deliver only the poorest quality software, when they in fact do deliver something.
If you run a team or work in a team, I cannot encourage you more to stop and think how you can improve not only your customers’ productivity, but your own. All too often we preach the gospel of software and automation but fail to apply it to our own way of work.