If you want to transform IT, start with finance
zwischenzugs.com
zwischenzugs.com
Here’s a tell tale sign that you have product market fit - your product is buggy and sucks and your customers constantly complain and demand more improvement but they can’t give you up. They need to pay you because you serve a need they can’t or wont find somewhere else.
The customer needs a bespoke feature that really only they will use and isn’t general to anyone else? Is the founder team disciplined enough to say no and focus on what really adds value? Sure, they would love for you to be a cheap outsourced dev shop, but that’s why your CEO needs to push back and sell the vision of the company.
Phases 1, 2 and 3 are backwards. Why is the startup trying to be a consulting company? This doesn’t sound like the story of any visionary startup I know of. It sounds like a group of developers who can make a profitable software consulting company trying to pivot to making a product. IMHO a startup can be really dysfunctional in its dev process and management and still succeed, if they find product market fit first.
However, the problems he describes can easily affect enterprise SaaS companies in a niche. If your market literally has a few thousand potential customers, you could end up in a situation where onboarding a big new customer is a double-digit percentage of your current revenue. At that point, it doesn't matter if you're a SaaS or not, you're gonna feel the pressure to do things for the sake of them.
Why does a successful software business need to be a "visionary startup"? Taking on consulting work and discovering the product by listening to customers seems like a reasonable approach.
You don't see "strong product vision" and "iterating to find product market fit" as contradictory?
A "strong product vision" is a bad thing when you are "iterating to find product market fit", because most people tend to be unable to kill their darlings and do what is needed to achieve said market fit.
If your "strong product vision" is really as strong as you believe, it should already contain an idea which market and target group is ideal — or if it is a really genius idea, this won't even be necessary because it will create it's own market.
imo vision is “how is your customers world going to change as a result of using your product?” not “this is precisely what the product will look like”.
The issue with this is that it means your software won’t meet that clients requirements.
If you want to go into the enterprise space early rather than pivot their later, you can’t start by point blank refusing requirements from your first big client - particularly as you don’t know what customers want yet (or more accurately - your customers are telling you but you are saying it doesn’t meet your vision).
The problem is that if you want to break into enterprise and aren’t willing to make things bespoke, it probably means that your MVP is going to be huge for certain types of software.
This isn’t a rule for all types of software and things like infrastructure provisioning / internal IT tools are different - but I can see where he is coming from.
It’s also different in terms of selling to the SMB or consumer market, where the requirements will either be less-varied (consumer) or the customer will generally sacrifice a lower match to their functional requirements to save cost (SMB). This of course depends on how mature the market is, and in a mature market the MVP gets bigger (for example, word processors).
The only companies I’ve seen be successful starting with the enterprise have older founders who have spent a decade or more working in the industry and already have the professional network and clout to reach their buyers. Without that professional network and a track record of delivering, you’re not going to make it past the front door.
And in these types of environments, consulting / maintenance absolutely must be part of the business model. Your customers will demand it (or at least demand you have SIs lined up as implementation partners).
Often the problems 'enterprise software' solves aren't overly difficult, and if every company worked the same way it would be trivial to write the software, but the issue is that every company is different, and building everything custom isn't scalable or supportable.
In this case, your customer is more abstract, it could be a million people using your, maybe free, or maybe "pay once" product, physical or digital.
But then you seek another market because management realises that your product will sell to different market, completely different million of people. But that will take new development. Team 2 is born. It is a project in a sense that this team works with one single goal in mind: get the project off the ground and start selling it.
This doesn't look like consulting company at all, but the problems are the same: technical debt, maintenance, shared code, and eventual rewrite and platform.
The product market Fit thing is just right.
A manager once told me that Legal and IT will always tell you no before telling you yes. Basically you need to argue and escalate to get things done, and it’s frustrating. After 20 years I’ve found that pretty true, though my current company is a bit better than others I’ve worked for where IT pretty much said no to everything.
Everytime you are going to stop me from writing queries to your server, or add more security that makes it harder to do my job without sufficient support to rightfully get through that security, or deny me the ability to download legit software from the likes of Microsoft and other reputable vendors because you have some ridiculous amount of red tape, I’m absolutely going to question every dollar and be skeptical of how the funding is going to help me or my partners in HR, Sales, Supply Chain etc.
If your projects help me, and you help me, I’m definitely willing to help you more and fight for you and your budget.
However, the problem I see is that teams (hr, legal, etc) generally can’t be trusted to make decent technology decisions. They could blow $10M on something that sits on the shelf because they were “sold” or worse it disrupts the entire organization in the process of a failed implementation. Both we see happen regularly throughout the organization. Finance is responsible for vetting every possible point of failure which is why we are risk adverse, or appear so.
If you feel someone is deserving of punishment, they should know why and it shouldn’t be through your budgetary control. It’s a misuse of power.
No you can’t run arbitrary queries that bring my server to a halt. No I’m not going to give to access to my API only for you to blast my system with some python script during peak hours when you can just extract the data in CSV and use a real data analysis tool. No I won’t support your shadow IT Access DB that you created because you refuse to pay for a sql server with enterprise grade storage and redundancy.
These are things that have happened to me and I can’t imagine being in security and having to deal with people installing whatever they want.
The reason IT (including security) say no is because we have been burnt before and are left alone when someone fucks things up.
I don’t think people should install just any program willy nilly, but why in the fuck can’t I install SSIS from Microsoft to help me deal with shitty “here’s some csv’s” service I sometimes get? Literally no reason ever ever to not be able to download that.
As it must be.
> Then you need to help me with the API calls.
As it should be, with visualizations of the time-series data, if applicable.
Banks are more than ever driven by their tech teams. Tell your manager if you're suffering.
No IT department in the world has that level of resource, hence the "cybersecurity skills shortage", rolling battles between IT and engineering/sales/marketing, and Shadow IT.
The Zen of IT is giving your users the tools and knowledge they need and locking off the things that are actually illegal. The former use cases no longer bother you, the latter cases don't have exceptions to argue.
You are not doing case-by-case support. Ever.
We can always find new Actuarial Science grads.
It's the opposite of the "IT reports to CFO" problem.
>Everytime you are going to stop me from writing queries to your server or add more security that makes it harder to do my job without sufficient support to rightfully get through that security,
I would sincerely hope someone in finance would understand separation of duties and generally that being able to arbitrarily manipulate a database without any controls is a bad idea. Especially if it holds business-critical financial data.
> or deny me the ability to download legit software from the likes of Microsoft and other reputable vendors because you have some ridiculous amount of red tape
There is no absolutely zero reason why ordinary users should have administrative control over their workstations in a corporate environment. It's been considered a worst practice for several decades, pretty much every IT framework forbids it, and it genuinely prevents a vast swathe of issues and limits the scope of damage if something does occur. It also doesn't matter who the vendor is, installing updates without testing to see if they're compatible with your environment is a sure-fire way to break things (and believe me, just because they're big like Microsoft doesn't mean their quality control isn't garbage).
> because you have some ridiculous amount of red tape, I’m absolutely going to question every dollar and be skeptical of how the funding is going to help me or my partners in HR, Sales, Supply Chain etc. > If your projects help me, and you help me, I’m definitely willing to help you more and fight for you and your budget.
Sometimes IT are required to undertake projects that disrupt or inconvenience other parts of the business, but the reverse is often true. That's just how things go sometimes. Instead of becoming antagonistic, why not talk to IT and try and find out why something is happening and work with IT to solve it? It will be more productive in the long run.
Because when your computer screws out and you're unable to work, IT is on the hook for your lost time and you get to go floppy because 'the network is down'. If IT is responsible for ensuring your technology environment supports your productivity, which in almost all organisations they are, then they need to be in exclusive control of it or they cannot provide a comfortable level of assurance to the organisation. Responsibility and control go hand in hand. I won't take responsibility for anything outside of my control, and if you're sane neither will you.
Teams that are willing to confront their organisation's established norms and assume responsibility for the continued operation of their workstations and the corporate network they are trusted members of may be able to gain permission (from management, not IT) to get install privileges. If you're in an organization that's deployed a zero-trust model this is much easier, and you only have to assume responsibility for the workstations as the network is already resilient againsts it's participants.
Everyone else needs to sit down. If you're not giving me an unlimited bank account of the company's money, I'm not giving you admin rights; And the motivation for restricting both are very similar.
On the other hand, ensuring people have what they need to be able to do their job to the best of their ability is kinda the point of IT. Unfortunately it's never a simple job to distinguish between 'blustering and wants to run a bitcoin miner' from 'needs a legit piece of software to do their job better' without proper engagement to understand your needs. If you have legitimate needs you don't look any different from the dickhead in the other department that's taking the piss, until we've gone through that 'red tape'.
That can't be emphasized enough. I've seen my fair share of situations where people get saddled with responsibility and no corresponding control. When that happens, they end up being other people's clean-up crew with no time for much else.
1 - My paycheck did not increase when business was successful.
2 - When something broke as a result of assuming risks to deliver stuff, I was blamed, not business.
So I realized the most rational thing I could do was to become a bureaucrat and ended up leaving.
Now I work in a place where business and IT are in the same team and have the same financial incentives. I tend to make reasonable consesions and business people actually care about security and keeping tech debt sane. Pretty cool.
That's a perfectly normal human response - but having to schmooze the petty tyrants in Finance for something that helps the organization as a whole is why I will never again work at a company where my department is seen as a cost center.
Most finance folk are more amenable when the problem can be simplified to "if you give money; we'll make more of it" as a first order effect; anything less than that will be mired in politics and backroom dealing.
> Most finance folk are more amenable when the problem can be simplified to "if you give money; we'll make more of it"
This is or should be leadership in general. It's just business acumen 101.
> mired in politics and backroom dealing
It's usually just a sorting of all possible decisions. What you don't see is how 10x of available budget dollars is being asked for by various departments that have no clear financial ROI and someone has to decide which investments to fund and what can wait. IT as a cost center can usually wait.
My point is that they can be short-sighted by seeing value in things that directly generate money, which is the opposite of acumen. Things like "We'll halve the wait time on help-desk tickets, making everyone more productive" or "We need an additional storage array, we're almost at capacity and need head-room" are not money-makers, but the finance folk at some organizations treat it like it's your personal pet project that you have to grovel for.
It is your burden of proof though. You have to convince decision makers why your project deserves funding. Nobody in life just blindly gives out funds. Finance can be your biggest champion if you help us understand the cost/benefits.
> Things like "We'll halve the wait time on help-desk tickets, making everyone more productive"
This takes shape in many forms and it’s a fallacy of some sort. Is being more productive even the goal? The goal is to maximize productivity with current resources. You validly use lack of investment as a reason productivity has a ceiling (and should). But, likely it’s a substantial investment needed to halve wait times. And that’s money that almost always has a better use.
Eg. Spend $500K to save $500k on labor Vs Spend $500K on marketing to make $1M in recurring revenue
That is all true, and my way of playing the meta-game and flipping the risks to finance is working in Profit-center departments only. "The storage array is about to get full, and if it does, everything will grind to a halt and we'll make no money until its fixed" means the burden of proof is now on the finance person, and if they refuse and our APIs start 500'ing because of it, I'll have my paper trail ready. Fuck working in cost centers.
> This takes shape in many forms and it’s a fallacy of some sort. Is being more productive even the goal?
The answer to you question is yes, that is a goal for the helpdesk to resolve issues faster when users are complaining that the wait times are too long, especially when it's the pencil-pushers in finance who want to jump queue because "everything they work on is important and time-sensitive" and deserves to be a P0. For the modest amount required to buy a midrange, off-the-self replacement mail server, we could avoided half the tickets that were email related (server was very old, and we suspected it had bad memory, and of course we had no backup server - that would be expensive)
The two cases you mentioned do have drastically different risk profiles. One wipes up the company’s revenues and the other just loses email. It’s like comparing certain death to a broken toe. And I’d take a broken toe if it saves my life every day of the week.
When budget dollars are limited these two things can be mutually exclusive. Also, it could be 1) the company is trying to sale and but hold on all infrastructure purchases 2) the company is in talks to outsource the help desk 3) any number of things that finance knows confidentially.
I’ll leave it there. My point is, yes it seems difficult to get things approved. Plead your case in terms of cost/benefits and risk financially, operationally, and relatively to your teams goal. Accept “no” as leadership taking all the information you’ve shared and still deciding they were ok accepting the risk you brought to their attention.
No doubt that the Finance team is generally the most powerful entity in shaping a companies direction both internally as well as in your clients organisation. Finance teams love control, are (mostly) completely risk-averse and change averse. The same can also be said about badly run IT teams.
I have seen product/automation implementations being deployed seamlessly in all departments from operations to procurement but completely fail due to the finance teams. In extreme cases I have seen finance teams have so much power that they even override the CEOs decisions to make implementations fail if they feel that they are loosing control or do not like the new process workflow that the implementation brings in.
For digital transformation projects the implementation team needs to speak the language of finance, operations as well as IT. Otherwise the chances of the implementation really succeeding is close to nil.
Finance itself is the worst place to get anything done, since their view is almost always a reactive one.
When accounting and controlling are done setting up their cost centers, the most logical place from their view would be to fire all developers and double the sales team, as that's where the money is made.
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.
Finance is ultimately a completely soulless place that — just like technology-centered nerds — should defer to a CEO who puts all the pieces together into a coherent vision, ruthlessly chases product-market fit and a profit-first (but NOT profit-only or self-cannibalizing) approach and thus injects business sense into all players in their company.
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.
Finance isn't any more intelligent than the other players in the company.
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.
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 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.
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.
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.
So, I’d say go for it if it’s something you think you’d enjoy.
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.
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.
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.
[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.
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.
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.
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.
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.
So engineering managers would pitch a project, fund a bunch of consultants, get a massive piece of tech built and then fail to support it. They knew the downsides, and wanted to build long lived teams that built and support and evolve products, but there was too much push back from finance and IT.
I realised that the company would prefer to spend two or three dollars in capex every year than a dollar of opex. This helped me understand how and entire industry of overpaid an underqualified consultants existed.
So my question is, where is that accountability for the finance function? Their controls and constraints caused the company to flush huge amounts of money down the drain, just so their books could have numbers appear in the columns they wanted.
As I mention above, opex vs capex is usually a compensation issue.
The opex / capex argument is about compensation. Opex reduces income immediately while capex gets spread out over the projected life of the asset (software, power plant, computer, etc). By shifting items from opex to capex, a company temporarily increases its net income. Increasing net income often leads to higher bonuses.
This is what drives the silly behavior. To make matters worse, once a company goes down this path, it cannot get off as it is usually evaluated on a year-over-year basis.
As for accountability, CFOs of public companies can be found criminally guilty (i.e. go to jail) if they not only commit accounting fraud, but simply do not establish a robust enough control framework to ensure the financial statements are correct.
CFOs are always accountable ultimately to the CEO and sometimes to the Board of Directors. If you think the CEO was unaware the company was spending "two or three dollars in capex every year than a dollar of opex," your either mistaken or you had a clueless CEO.
My snark comes from the fact that in this organisation it was taken for granted that the CFO has a seat at the table because, after all, finance is a thing that grown-ups do. It's serious business. Because they have control of the money they can dictate how the rest of the organisation does their job.
But in reality, they're kneecapping the rest of the company – the part that is actually producing something – so that they can make some imaginary number appear in the right place. They're they ones playing made-up games.
As a CFO, I want to earn a seat at the table where decisions are made. Finance frequently has access to a significant amount of data about the company and if the Finance team does it job well, they turn that into useful information. Bringing key information to the executive team (and entire company at times) to facilitate the decision-making process is one part of how to earn that seat.
Finance does not have all of the information. The Technology (IT/Engineering/Product Dev/etc) team will have a unique perspective. Marketing will have a unique perspective. The People team will have a unique perspective. I think a company with a strong culture figures out how to embrace all of these perspectives and collaborates to develop world class products and services.
Finance does get tasked with evaluating the ROI question - does the proposed investment opportunity create more financial benefit (can be expansively evaluated) than the investment. That should be to ensure a consistent process and is frequently because Finance is viewed as independent from the group requesting the investment.
A good CFO, heck an average CFO, wants to support good investments. It is always more exciting to say 'yes' than 'no' and importantly the company grows by making smart investments. I have never seen a compensation structure for a CFO that provides for increased compensation for always saying 'no.'
This is sometimes the same in the public sector. Oversimplifying: capex can be funded with a bond, but opex increases come from taxes.
Say you have some on-prem datacenter stuff for a manufacturing plant, you might have the request from factory operations to be as available and consistent as possible. The cost for such a thing might be astronomical, but even a single day of downtime would cover it. On the other hand, the finance department might already have made a risk assessment and set aside some money or had it insured in some way and now suddenly the impact of that risky thing that might happen is a whole lot lower in terms of money.
For a lot of people that can be news, or unexpected. If you silo yourself you might end up engineering something that is completely unnecessary. At the same time, someone might be buying some expensive insurance, but forgets that unrecoverable data doesn't magically yeet itself into existence just because the insurance contract says so. So while on paper it's "covered and we just need to recover our systems and get on with it", in reality that might not be possible. Starting a company from scratch (IT-wise) leaves you with empty systems. Those are about as useful as a brick. A functional brick, but perhaps not the spreadsheet, email or CRM database you had in mind.
This is a lot of words just to say: in most companies (as long as they don't get too big), most people are there for a reason, and most departments are there for a reason. Go up the chain of reasoning and you'll find your common reason ("because the company wants to make money" for example), and now you have all you need to 'justify' to yourself that 'those other people' are there for the same reason and with the same goal as you.
Also, because of recent ransomware attacks I've been given (almost) carte blanche to secure our network and operational infrastructure with a special focus on finance, because the spice must flow.
tldr; yes, "starting with finance" is a good way to transform IT.
Repeat after me: software development *is not* IT.
IT is the department that hands out laptops and buys office licenses from MS.
Software Engineering is a product development group.
They're two entirely different functions.
IT can make sense to have under the CFO, but product development almost never does.
Just get a CTO.
But seriously, it's always hilarious to listen to non-tech companies pitch how they can pivot to becoming a "tech company just like Google" while following none of the practices in SV. Developers still working for "IT", cost cutting and penny pinching. No free food of course...
The only distinction I see is that software developers want to believe they are somehow more special than everybody else.
The companies that recognize this are the successful ones, and the ones who don't fail eventually. Even John Deere sees the light here. Why do you think they have all of the DRM BS? The value comes from the software.
IT is also not nearly as expensive as other types of businesses that require huge capital investment, like farming equipment, factory assembly lines, biotech reactors, etc.
Otherwise you lose a lot of your economies of scale because each business unit is trying to figure out the best way to do things. Or you end up with shadow IT all over the place because the BUs come up with cheaper but unsanctioned/unsupported ways to do things.
You also need a way to objectively evaluate how IT is performing. If the business units are going to third parties because IT is unresponsive or overly "expensive" then the exec team needs a way to see that. When IT is responsible for the IT budget then they have incentive to minimize costs and it's easy to do budget reviews. When the business units have to pay that budget then IT acts as a monopoly with little incentive to improve service or reduce prices and it's much harder to find the shadow IT that's being implemented to get around bad internal IT.
There's no one perfect answer.
It’s still better than the typical approach, where everyone is just angry at IT all the time “because they are such a drag with so many expenses”. Outside of the extremely dysfunctional cases, charging everything back to business units is at least the more honest approach.
I had this fight with my last CEO. She put anything tech-related under my budget. Worked with accounting to show what the budget would look like if expenses were correctly attributed, and suddenly I wasn't spending so much money anymore.
Reason she didn't want to change it? So they didn't have to explain why expenses changed so much quarter-to-quarter during the next board meeting.
Seems like a win-win. Now she knows the reality of the enterprise and is okay with the expenses but she feels that investors would be bothered by it, so better not change anything in order to avoid having to answer their questions
10 years later, my ex-CFO still thanks me for what I did, and wish I was still with the company.
Wait there are companies that don't do that?
It seems to be mostly the really large companies who have enough of an internal economy where they actually get to the point of internal chargebacks.
In my experience as an IT person, IT people are almost always full of shit when they talk money or roi. Usually when you think the tech team has their money story together, it’s because they are growing and you can hide mistakes in growth.
Once growth slows, you realize there’s some dude making $250k and nobody knows what he does. Or that you’re paying $1M/month for AWS charges that you cannot track back to revenue. Or that you’re running a data center that full of end of life equipment that isn’t used or brand new equipment that was never commissioned. So the CEO brings in the bean counters to rein in the nonsense.
Great insight, and mirrors my own experience a lot.
> you realize there’s some dude making $250k and nobody knows what he does
I've been through this situation several times as a CTO. CEO's can come off as Jekyll and Hyde, one day shouting at you to hire, hire, hire and then giving you flak about those same hires when things don't go as planned.
ROI and it's cousin TCO should be useful terms, but it's been so twisted and bastardised that it's basically a useless metric. Everyone has some bullshit story that shows that if you give them millions now they'll deliver a lower ROI or TCO.
But if you’re not growing, the obvious way to make more money is to spend less. Many companies get away with this for decades.
I joined a firm recovering from this very problem. The previous IT director spent wildly and justified every purchase to finance who trusted their judgement. When the bills finally came due it almost put the firm under and the IT director left.
My experience is that IT and finance people simply have a very difficult time communicating with each other properly. They are different type of people and speak different languages.
A CFO will be very open to invest if he’s convinced that there is a clear return on invest. Many IT folks don’t want to bothered thinking from that perspective.
If you want to have an easy life learn how to speak with your board, especially the CFO.
PS: that’s one of the core reasons some IT guys get management consultants to do the translation job.
...but without IT, everything else stops, and usually people think about that only when IT departments get so "skinny", that things fail... and then they get blamed for that too.
Understanding the language and process of basic bookkeeping and simple accounting has given me me immense traction with finance people. When I demonstrate even a rudimentary understanding of the metrics and reports finance uses (understanding what financial statements communicate, tax ramifications of CapEx vs OpEx, cost of money, etc) the trust level and willingness to listen goes up tremendously. Stand-offish and distant relationships became more concrete and productive when finance people realize I'm not spouting techno-bullshit for bullshit's (or techno's) sake.
Anybody with serious IT management aspirations in the private sector really should have a reasonable amount of business knowledge. An IT operation, both the in-house and contracted services components, should be considered an internal business unit. It should be evaluated on the expenses it charges-back to the revenue-generating business units, and on the gains in revenue it creates by driving efficiency. Knowing the metrics that finance will use to evaluate an IT operation allows you to make a case for improving those metrics.
At a bank or in retail sure, it may make sense for IT to report to the CFO. At a healthcare proivder or insurance company, ok sure that makes sense. In that case, IT is really just another part of the plumbing because the core product isn't really technology anyway. The blog post is moot because the technology itself will have a minimal impact on the value added by the company, which is elsewhere, and nobody in IT is likely to have a seat at the product discussion table anyway.
But at a technology company? One where the core value add is software products or services or hardware? I don't believe it. I simply don't think that any company that places management of technology based core value added products under the CFO can succeed. If there happens to be some company out there that has this structure, I'd treat them as having a big target on their back - they're ripe for disruption by a company where technology leads.
Its not that finance get things done, its that they can prevent things being done entirely, or reduce funding/investment to the point they naturally peter out.
with IT it is hard, because the field is changing rapidly and hiring a competent CIO/CTO is harder.
this is why CEO is critical, and he is ultimately responsible for the overall outcome