Accounting has a Mythical Man Month too

Aquila has grown rapidly in the past several years and has grown exponentially more complicated. Starting the new year, we will have offices in over 12 countries and with employees in several more. Our clients range from public sector to private sector, from compliance and financially focused products to workflow and marketing automation products with almost every type of technology being used. In order to run our businesses, we depend a lot of information flowing across time zones in multiple languages. All while trying to do this with all the managers empowered to know it is their show – their team and that they have all of what they need to provide the best solution to our clients.

I believe deeply in an organization that can get the right information to the right people at the right time will have a growing competitive advantage over time. Sounds like great theory but it is really hard to accomplish. It becomes exceptionally hard to execute while growing rapidly across large numbers of time zones and multiple languages. Ultimately, the only common language is numbers.

Challenges aside, there is no need to stop aspiring to that goal as when our target may feel too high, just in the stretching for it we will get much better. The key to getting the right information in the hands of the right people starts with getting your financial foundation in place. As we have integrated many companies over the past several years that were fairly complex, I started to realize a pattern of challenges that felt oddly familiar to challenges in scaling Development. It finally hit me:

Accounting has its Mythical Man Month too

As I thought it through it stated to gain more and more traction. Ways scaling software development matches the challenges to scaling Accounting:

1.      The first solution to most problems = “more bodies”. Most accounting individuals when under pressure of why things are taking so long claim to solve the problem they need MORE resources.

2.      Faster is thought to be = “lower quality”. We want our books closed in a couple business days each month. That allows the managers to act upon the data and do something. Most Accountants have been doing things a particular way, with a particular process for so long they often don’t know any other way. Developers often say the same thing. When we press for sooner, what a Developer or Accountant hears is “give me more errors”. Speed often creates more problems in both of these situations

3.      The number of tools available to assist is overwhelming. Half of being a great accountant these days is knowing when to use the right tool and when to redo a particular process in the moment. Developers can often be accused of falling in love with the latest widget but it is the proper use of the new tools and environments that really helps in productivity gains. When to add a tool, drop a tool, how to implement new technologies – we are all implementers of technology and we have to know how best and when to do it.

4.      They have an outside perception of not caring about responsiveness. When things are complicated, it is hard to provide clear and simple answers to use silly “distracting” manager’s questions. Without clear and simple answers, the perception (erroneously of course) is that those in the middle of the complication don’t understand what they are doing. They usually do – but the translation is the trick

5.      When things go wrong in a complicated process, we often solve it with more complication. Ever been involved in a development process where there were quality issues because there were too many people touching the product and no one owned the quality deliver to the client? The easy solution to most? Add a QA team (which does not solve the problem but now there is a group to blame when things continue to go wrong). Accountants often may have missed a step in a long, complicated process only to solve it by adding another manual separately calculated spreadsheet that needs to be checked all the time (oh, and does not solve the problem but just checks to see if it happened again)

Anyone involved in trying to speed up a Development project knows the mythical man month is related to complexity – this is no different when it comes to speeding up a complex Accounting team. Here are three guiding principles that have worked for me as we have stepped through multiple process improvements:

1.      Design the system as simple as possible to provide clear accountability. It should be setup so that a key person can see how the entire system works.

2.      Invest in process improvements – continuously. You need cycles of time (start with just a handful of dedicated hours) to improve the process every couple of weeks or each month. It may only be small at first but use that to save more hours in the future and then use that newly gained time to improve further. This type of pay-if-forward saves many, many issues over time.

3.      Make the team as small as possible. When a team gets beyond a particular size, ownership of the outcome is lost. Each person starts to define their job as only what they can control and then when exceptions happen (and they always do) no one knows who should stand up and do something.

Complexity is the byproduct of short-term solutions to recurring problems. If we just get better 1% a month, it does not feel like much but it compounds quickly. You need to invest incrementally in the tools and the process to automate the recurring elements of our jobs so that we can spend our time doing what we all do best – which is overcoming new challenges.


Leave A Comment