The issue is that IT/tech does not know business key words or excel spreadsheets, and finance does not know tech. Nowadays it's getting blurred with data scientsts and excel crunchers that can do a mean macro (and know more than Vlookup!)

Finance people love automation. Finance people love excel. Finance people understand sunk cost fallacy. Finance people understand change. Finance people need help to embrace change, to guide decisions and make sure it's the right "tech" for the company.

Many times the right tech is O365/Sharepoint/Flow automation, or nintex. Yeah, but

it is not souless, it guides the entire company, it ist he company pursestrings.

Get them on your side, understand how to read a P/L sheet, what FPA does and you'll not only earn respect, you'll have your name said at all the exec/leaderships meetings and you'll be loved.

That's what I do in companies (consulting, self run) and w/o a good background in finance, and tech I wouldn't be where I am today (major in stats, tech was hobby, stats/math is everything etc.)

So I fully disagree 100%. You had it so close with SAAS and capex vs opex, but you missed it. But yes it does move expenses around and opex is easier to navigage then a full sunk cost capex.

once, as a pre-mba product manager at a mid-sized company, i presented a detailed financial projection (using monte carlo on the assumptions/inputs) for a project i was championing that went over the head of the controller (and acting cfo at the time). boy was i disillusioned after that.

finance should never be thought of as guiding a company. that’s giving them too much credit and (misguided) influence. rather, it should provide analyses to the executive team to use to make executive decisions, much like the congressional budget office does for congress. it’s one of many inputs needed to make executive decisions.

In my experience, it is hard to find people in the finance department who understand there are other distributions than Normal. E.g., the time I had to spend trying to convince finance people that the product of two Normals is not necessarily Normal. Or, percentiles of the sum of two Normals do not correspond to the sum of the percentiles etc.

Yet, they do end up guiding the company because money drives everything.

I once had to spend a day convincing a CFO that consecutive months of ~X% increases of MRR wasn't the same as

((($MONTHS * X) +1) * MRR)

eg. two months of 10% = +20% increase, 5 months = +50%, etc.

... which is how his spreadsheet was calculating revenue projections.

How does a CFO not understand compound interest?

Trying to think in silos and making departments fight each others is a faulty approach. If you want to transform business, change has to come from/to be accepted by the top.

The mystery to me is why IT departments run by a CFO are notoriously bad at IT. It seems like Finance will take cutting costs over increased revenue every day of the week; I don't know if they just hate taking on risk, or are just hoping someone will convince the board to hire a CIO and relieve them of the duties, but the end result is rarely pretty.

In my experience it is simply a reflexive dismissal of externalities. If you can get them to model the small but real (though fuzzy, so with error bars) costs (eg. higher employee dissatisfaction = increased turnover, lower productivity = increased time to market, etc.) of each cut it works out better: Sometimes the cumulative price does it, sometimes the cumulative uncertainty.

That doesn't help against clueless execs who live 20 years or more in the past. Japan's cybersecurity minister literally admitted to never ever having used a computer in his life (https://www.theguardian.com/world/2018/nov/15/japan-cyber-se...).

Even if you show them that your IT modernization has the potential to save the company millions of dollars a year, they will decline your proposal because "the current system works/no need to upgrade and risk issues".

The literal only way to get banking C-level execs to modernize their 70s era mainframe stacks is regulatory action. Only with the threat of massive government-levied fines or closure of business, they will go ahead with change.

As a result of searching a few years back, I ended up buying a copy of "The Personal MBA" and reading it through. This comes with the list of 99 business books, listed here; https://personalmba.com/best-business-books/

* I have no affiliation with the site, author or book. I'm just speaking from my personal experience and the benefit of business knowledge this gave me.

IMHO, the best thing you can do is work with someone in your FP&A (Financial Planning & Analysis) group discuss your investment idea and why you think it is a good idea. If they are a decent analyst, they will help build a model to describe financially your investment opportunity. This is what they live for.

So, I’d say go for it if it’s something you think you’d enjoy.

I've heard some tales about a town in Michigan - let's call it Flint - where water was distributed using some older provider, while some newer company existed which charged less. A newly hired CFO decided, logically, to save some funds by going to the cheaper one. CFO didn't know that pipes in the town were made in the old fashion (lead metal?) and the new company, which used iron pipes, used some chemicals in water which helped to keep pipes clean. This chemical wasn't used by the old water supplier. When flown through old pipes, the chemical caused dissolving the lead into water. By the time the population of Flint switched to bottled water for everything the CFO was long gone with earned bonus for saving money to town.

I wonder what such stories, if true, teach us for the future. Just general mistrust towards financiers doesn't look quite right...

financiers, including startup investors, focus on money above all else, and that alone justifies mistrust (aka skepticism). with that kind of focus, it’s inevitable that decisions are made selfishly and greedily. that doesn’t mean it’s a tool that can’t be wielded for generally positive outcomes, but that the deck is (intentionally) stacked against it. beyond that, the flint situation sounds like a real failure of leadership all around (at the very least, basic due diligence/risk analysis). that often happens when decisions are made far removed from the expertise needed to make them.

That if you're looking to maintain [water] quality, you need to have monitoring in place.

Switching to the new provider was a good idea, not a bad idea. There is no way to keep track of everything that might have happened in the past that might be affected by unspecified changes in the future, so there can't be an expectation of doing it either. But you can watch what kind of results you're getting.

But I agree that we might lose track of why some decisions were made. Yes, we may want to revert old decisions, sometimes even have to. Just some responsibility, which comes with power.

This article is disappointing in that it gives the impression that one department makes or breaks a company. To be clear, there are poorly run Finance organizations in the world and they can make the culture at a company less than fun. There are also poorly run IT organizations (to include product development) that can ruin a company culture. Even ones run by a CTO that reports to the CEO.

I have also never seen a company where the CFO does not ultimately report to the CEO. I have seen companies where the CFO reports to a Chief Administrative Officer (CAO) who reports to the CEO. I completely agree that the CEO ultimately sets the vision of the company and hires the executive team to deliver on it. That being said, a CEO is not Superman/Superwoman. They need a team surrounding them to deliver what you expect.

What the article could have emphasized is how software engineers can work with the Finance team to better describe investment opportunities like hiring production engineers to increase the productivity of application engineers. Yes, investment opportunities ultimately need to generate more cash returns than the investment. This may require serious thought around the benefits from increased software quality, faster cycle times, increased cybersecurity etc. Importantly the analyses do not have to be decimal level precise. But, if you cannot describe how your investment opportunity ultimately creates more cash flow than the investment required, your opportunity will likely not be funded.

By "slowly" I mean that they had been inching towards using the right tool for years, finding any and every excuse to abandon course. The corporate app dev unit explained to me that they were wary of working with the finance area of my division as finance had repeatedly gone 90% of the way to an improved tool only to bail out at the last minute, wasting time and money and leaving corp app managers the task of explaining why things fell through to their bosses.

The best (worst) excuse given by finance during my attempt to sort things out was after we were acquired by an even larger contractor. "We're not sure if <company> uses <software>, so we're going to need to put a complete halt on the shift." They weren't sure? It took me less than a minute to go to the acquiring corp's job req page and see that they were hiring admins/devs for the software in question. Ridiculous. Finance leadership could have made a single call to ask a single question, but rather than stepping out of the comfort zone they decided to scuttle a project which was all but guaranteed to improve their lives and the organization as a whole.

I'm close to 50/50 on whether the finance unit was doing something dishonest and wished to retain the control provided by using an opaque/incomprehensible system or if they were merely too afraid of any sort of change by virtue of their bean counting nature. Either way, they're probably still actively harming the company.

My personal hope is financial analysts get more tech savvy over time. SQL should be a year one skill with Python/R soon after. These should complement spreadsheets which would still have an important role in ad hoc analyses. Combine this increased tech savvy with an understanding of a visualization tool such as Tableau/Power BI and I think financial analysts could be significantly more productive than they are today.

There would also be far fewer spreadsheets lying around on the network drives. It is amazing how many of those spreadsheets are simply the same model with the next month's data. Better use of databases would allow one spreadsheet with a database to store the changing inputs.

Or am I wrong? Is there an easy way to get a report that tells what a given spreadsheet calculates?

Over the years I have noticed a few conventions that make spreadsheets easier to read from a model perspective. - Inputs should have their own tab and ideally a name. Should also be a color-coded font (blue is popular). - A worksheet should work left to right, top to bottom. I am always frustrated when I try to work through someone else's spreadsheet and the formulas just drift across a tab rather than working in a pattern toward a conclusion/summary - Pretty print sections should be separate from the actual engine. Do the calculations in a manner that is easy to understand. Create an output tab to create the pretty report. - Flag with a bright background color when a formula changes (yellow is popular). This frequently happens when your boss asks you to create a scenario where you override a formula with a constant. I cannot tell you how many hours of my life have been lost tracking down an overridden formula.

These types of conventions make spreadsheets easier to inherit from someone else. They do not change the fact that there can be a lot of calculations happening through a multi-tab that you simply cannot see the bigger picture.

Probably won't happen and isn't important imo. If somebody can dig SQL/Python/R then somebody can get paid more to do something other than count beans (speaking here of lowest level financial analysts [accountants]; I was probably the only person at the division trying to make a meaningful financial forecast that was more detailed than a top level number with zero transparency. I started w/ python but wanted a COTS solution. Didn't want to babysit it.).

>Better use of databases would allow one spreadsheet with a database to store the changing inputs.

This is the key. The number one complaint of every other business area was that forecasts came in asynchronously and it was impossible to tell whether what had been added or removed was real. Hallway conversations took the place of structured data. That's fine for many things, but not for projections which determine whether we need to hire twenty more engineers or let go of a dozen.

The product that would've solved the problem (and then some) was IBM's TM1 (now "Planning Analytics powered by TM1"). My model worked well in TM1 and could've been extended to being better than a calculated model--the direct inputs from the dozens of IPTs could have been collected without the need for any math used to back out of numbers. No "model", merely the collection of demands of every program and every potential contract. The program teams already generated all of this data; finance threw most of it away while rolling it up.

TM1/PA has Excel plugins which render the change invisible to the financial analysts doing the work. Their job doesn't change but the organization can hoover up more data by at least an order of magnitude, breaking the cycle of relying upon opaque, top-level numbers that no other business area actually trusts.

I agree with you that it is unlikely accountants will learn SQL/Python/R. They are tied to their ERP and Excel. My hope is the FP&A analysts will develop the SQL/Python/R skills to enable the better/faster development of complex models to forecast.

>The product that would've solved the problem (and then some) was IBM's TM1

I have not used TM1, but have heard many good things about it. Today I hear more people discuss Workday's Adaptive Planning than any other product in that class. Unfortunately most are still creating their primary forecast in a spreadsheet, then loading it into the TM1 or Adaptive which then has additional rules to build out the forecast.

I agree that using these types of products increases transparency and speed.

Noted and agreed. I'm not well versed in finance lingo beyond what I learned by taking up a business analyst role. The distinction you mention was likely lost on me due to the fact that this division didn't really have an FP&A team and every accountant was given the title of "financial analyst".

Sure, FSS made projections, but those were all terrible. They were worth less to functional managers than the paper they had been printed on. A given year's labor forecast came in the form a single column of multimillion dollar (Ex)cells per cost center. No ability to dig in. Consistently low by ~10%. Did leadership get a bonus by expanding the business book over the course of a year? Who knows?!

FP&A was an afterthought for leadership. I was probably the only full-time FP&A employee (at an office with over 700 employees), yet I did not report to finance--I was under the program management umbrella for some reason. It didn't take long to recognize the potential value-add that our finance area could provide with a single change. Alas.

Appreciate the replies. You probably feel my pain better than I do.

With respect to FP&A, I have seen several firms that simply embed them within a product line or business unit. They need to submit forecasts to a central group, but their primary mission is to support the product or business line.

[1] Who do you think the numeric keypad on 'full size' keyboards popularized by the IBM PC were for? Accountants. Granted, word processing was the other early use case... that Finance signed the checks for. IBM understood their customer.

And yet, somehow, IT departments ended up getting classified as cost centers by the finance department.

It's worth differentiating between allocation and flow - a million dollar spend can be hard to allocate to Project X, Y or Z. But it is usually simple to see it got spent on Developers, Sales people, rent, hardware licenses etc.

As the film says, if you go up high enough, there is only one man with one budget.

Cash flow is the actual movement of money - paying payroll, paying vendors, receiving cash from clients (not just sending out the invoice). Lack of cash flow is what makes companies go bankrupt.

Allocations are methods to attribute income and/or expenses to groups. It may be something simply such as dividing up an enterprise software license for email by the number of employees and allocating that expense to their department. It can be more difficult / squishy such as how to attribute brand marketing spend to various product lines. Generally, companies use allocations because they are trying to understand the profitability of something (a product, geography, client, etc).

Your example of the million dollar spend is a good one. Very easy to see where the cash flow went (Developers, Sales people, rent, etc) but the important question to assist on future investment decisions is how much should be allocated to Project X vs Y vs Z. One would also need to understand how much cash was generated by Project X, Y, and Z so they can determine the ROI (Return On Investment) for each project. Knowing the ROI is important in making future investment decisions.

The thing that most project managers / engineers don't see is that finance's real job is to simplify the story and fact check the assumptions so that execs can rely on the investment being reasonable. Execs don't care if the NPV is to the penny, they care that it makes logical sense and that business leaders (brand leaders, region leaders or whoever is SVPsh level) supports the project. More than 50% of my time was just talking to execs trying to lock down support for other people's projects so they could get them done.

Often times when a project get rejected, its not because finance made the decision, its because tech didn't get the right business leaders on board before asking for a project investment.

> Risky and unproven new projects with unclear (but potentially massive) returns or indirect relations like production engineers increasing the productivity of application engineers through automation do simply not exist in that world.

If you do a lot of risky and unproven new projects with unclear (but potentially massive) returns, the business will go bankrupt and everyone will lose their jobs and equity. Incremental, but repeated small and correct bets usually are best for driving high returns on capital overtime. Sometimes when an intuitive exec sees an opportunity they need to take a shot on goal and risk some capital. In those cases, finance is kind of out of the picture as the exec needs to stand on their own.

> And that includes the finance department, of which I've certainly seen some of the most stupid ideas. Like software capitalization/activation that did made sense for converting opex to capex in the GAAP sheets, but in the end drove all the best engineers away because of all the mindless paperwork. Just one of many examples.

The opex to capex justification stuff comes from accounting, not finance. Its very painful, but the accounting teams must follow the law/gaap rules of accounting.

> Finance isn't any more intelligent than the other players in the company.

Absolutely correct. Just another cog in the corporate machine. If you find yourself frustrated with any cog (co-workers) its probably best to talk to them and figure out what you are missing.

Most people are trying their hardest.

That's great for long term shorts.

You know you've got a top notch DevSecOps team for example if everything is smooth, calm and boring — because most issues are automated away. That's exactly the point when you know you can safely fire that expensive team, because it'll usually take a few years until the automation surplus has been exhausted and then a few more until the starting chaos has propagated into actual outside-visible incidents.

Makes for a great bottom-line at approximately the end of shares vesting.

You didn't get that pro-tip from me.