Adopt a Small Company Mindset in Treasury Development

Small companies have one clear advantage over large corporations: they can act flexibly and innovatively, without much bureaucracy. Successful small companies try new things, make a lot of mistakes, and learn from them. This enables them to quickly react to a changing environment.

I know the difference as I worked in large corporations – in banks and corporate treasury departments – from the late 1980s until the turn of the millennium when I started as an entrepreneur. We can now make decisions in one afternoon that would have taken countless meetings, memos, and arguments over several months in a large corporation.

The small company mindset is crucial when things change quickly. For instance, at the onset of the financial crisis in 2007, we saw more than half of our budgeted revenue for the next 12 months vanish within weeks (a lot of our revenue came from work for major banks at the time). Our ability to make fast decisions is the only reason for us being able to stay in business and now be back in growth mode.

The treasury of a large corporation tends to adhere to the large-corporate way even in their internal development projects. Great attention is spent on planning, options are weighed endlessly, partners are scrutinised and committee meetings are held as if the treasury had nothing else to do with its unlimited resources. In reality, a typical treasury works under strain to develop its processes with extremely thin resources. This reality is that of a small corporation.

This is why it makes sense for a treasury to adopt a small company mindset in their development projects:

  • It is the results that count, not how you arrive at them.
  • Speed is of essence and things cannot be pondered to death.
  • One should not be afraid of making mistakes, but learn to correct them quickly and learn from them.
  • Developing new things requires constant small steps that eventually translate into the right solution; you simply cannot expect to directly jump to perfection.

This means that a traditional IT project – in which the problem is documented, requirements are specified, the request for information (RFI)/request for proposal (RFP)/request for quote (RFQ) merry-go-round is run for several months – is simply not a functional solution. A much better alternative is a small steps approach. Make constant small improvements, study the results, and correct the inevitable mistakes quickly while it is still easy and inexpensive. Using a traditional software project model, the mistakes are found two years later when the solution is fully deployed and correcting them is no longer financially feasible.

If the immediate problem is unreliable (or non-existent) cash forecasting, you should select a solution that can be deployed in a few days – and that can be easily dumped if it does not turn out to be a good choice. It will not meet all your needs, but the key issue is fast improvement so that you can move on to the next important project.


Related reading