If you want to transform IT, start with finance(zwischenzugs.com)
zwischenzugs.com
If you want to transform IT, start with finance
https://zwischenzugs.com/2021/07/12/if-you-want-to-transform-it-start-with-finance/
155 comments
> 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.
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 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).
One of the biggest mistakes you can make as a founder is to go after enterprise B2B without understanding it. Companies in this space are usually not willing to buy a half-baked product. Corporate procurement doesn’t like buying from vendors without a track record. The hardest part is getting your first client — which is why SMB is the typical entry point.
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).
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).
Totally agree. The difference in 'enterprise-level' software often is configurability and the ability to meet client needs without being totally custom (although even for the biggest, most feature-rich enterprise software, most implementations will still require custom development.
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.
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.
No, this is more fundamental than that. This customer-revenue-project-tean relation and habit holds true even if we have vision and understand direction and have strong leadership.
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.
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.
Back to money flows I think - if your business has significant venture backing then your view about it is correct. The driving force in the business will be to satisfy the investors, not the early customers. Many businesses are not like this though - they start out as a consultancy gig gone good and then scale up from there. Investment comes from a workable functioning business in these cases. A new investor isn't going to be hugely interested in "vision" but much more in "the business" - what is the potential for selling more of the same?
I don't understand if you have a contention with the article, and if so, what the contention is. You say that this "doesn't sound like the story of any visionary startup [you] know of", but the article never makes the claim that this is a successful path to go down - it is very clear that this is a failure story.
I want to add this to the wit and wisdom of Hacker News book.
The product market Fit thing is just right.
The product market Fit thing is just right.
He says this is common to pre-SaaS companies. So he's mostly describing companies started at least a decade ago, perhaps two or three.
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.
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 is the startup trying to be a consulting company? This doesn’t sound like the story of any visionary startup I know of.
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.
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.
What are the biggest success stories of consulting businesses pivoting to product based companies? I can't think of any off the top of my head.
Basecamp? SAP?
Definitely SAP. If you believe the movie, Facebook. Trello/Stack Exchange (Foghat)
Mailchimp
Salesforce?
Atlassian
> Wait, this is a startup that doesn’t have a strong product vision from day 1 and isn’t aggressively iterating to find product market fit?
You don't see "strong product vision" and "iterating to find product market fit" as contradictory?
You don't see "strong product vision" and "iterating to find product market fit" as contradictory?
As someone who spent half his life in the world of (physical) product design: to me this sounds incredibly 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.
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.
Perhaps it's a vision of e.g. technology which could be applied in many different verticals? I can see the founders having a clear product idea but having to find its specific applications on the market... E.g. let's say you make a database and then you begin looking for companies that need your specific favor of database; then there could be customization for specific customer needs too.
This made me scratch my head too. I see so many startups come up with an idea/product and then try to make it fit in the market. That is completely backwards; you need to find a problem that the market has and create a product that solves that.
depends on how you understand vision i guess.
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”.
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”.
Funny to read this because I happen to work in Finance and many requests come through my team. I’m going to add some advice here for what it’s worth.
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.
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.
In my first job as a sysadmin I tried my best to support business and two things happened:
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.
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.
It sounds like you are mad at the security folk not really IT.
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.
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.
Then you need to help me write the queries . Then you need to help me with the API calls. And yes I will shadow IT all day long until you work with me on a better solution then just downloading CSV files. If you aren’t going to help me and do your best to get me a solution, Even if not perfect, I am definitely skeptical of your requests and need to watch out for empire building. I’m not writing SELECT * queries man - I have very specific data requests and have an MS in Comp Sci so while I’m far from a DBA, I’m respectful of things I don’t know. You can’t just say “no we aren’t writing requests today”.
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.
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.
> Then you need to help me write the queries .
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.
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.
>As it must be.
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.
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.
I agree that this is not a one-size-fits-all solution. However, if a business user has deep understanding of the problem domain and deep knowledge of the data model behind it (because they may have written it), then I want to move them into my tech organization.
We can always find new Actuarial Science grads.
It's the opposite of the "IT reports to CFO" problem.
We can always find new Actuarial Science grads.
It's the opposite of the "IT reports to CFO" problem.
Shadow IT is fine for now. The execs will do their next Technology Transformation to get rid of shadow IT at the advise of highly paid consultants. It will be consultants draining your coffers not IT and I can guarantee you it will be more expensive than doing IT right in the first place.
This is a bad attitude to hold. Despite common opinion, most IT departments are just trying to meet their own objectives and requirements and are not deliberately trying to frustrate the users under their care.
>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.
>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.
>deny me the ability to download legit software from the likes of Microsoft and other reputable vendors because
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'.
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'.
> Responsibility and control go hand in hand.
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.
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.
> If your projects help me, and you help me, I’m definitely willing to help you more and fight for you and your budget.
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.
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.
Profit center all the way. It's true for any job in any industry.
> 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.
> 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.
> This is or should be leadership in general. It's just business acumen 101.
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.
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.
> 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
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
> 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.
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)
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)
I hear you. Corporate finance itself is generally always a cost center. We operate on shit software and it’s a reason we pretty much try use Excel for everything. It’s the only decent software we have.
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.
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.
Did you just admit that you fight legal and IT on purpose, just to have a fight?
I work in finance and think I understand gp’s meaning. Although the end part sounds like They’re playing favorites with budget dollars which is essentially where office politics comes into play and not exactly in a way that’s in the best interest of the company.
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.
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.
I think you captured it more elegantly than I did. I know it sounds like playing favorites but consider it’s not just me I look at out for. If our IT Business Analyst Jill helps all the people in our business and everyone raves about how helpful she is, I have a lot more trust than the guy who scolds his employee for taking calls at 4 that my be issues because it’s the end of the day and he didn’t want to stay late fixing issues (I swear on my life another manager and I overheard this badgering occur). If it’s Jill vs him asking for a headcount, Jill is getting it all day long.
That’s exactly what playing favorites is. If his headcount is more impactful to achieve company goals, he gets it. You need to learn to compartmentalize
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.
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.
Nope, I am saying that there are many individuals in those functions that a solution creates more work for them, so they default to “no”. Hard no’s are understood in some cases - i.e. installing random nonsense from the internet. However, A “No, here’s why. But...” is way more helpful and generates a lot of respect from business partners.
He chooses to not help people who make his job harder, sounds like a normal human being to me.
Lots of people make other people’s jobs “harder” with good reason. Things like code review, legal compliance, IT policy, etc are just “overhead” if you assume that your knowledge is infallible - but people are fallible and we need systems like this that, yes, slow us down in order to keep from getting burned.
The overhead needs support. If you put up additional security where only IT staff can do x, then you need to ask for or transfer headcount to ensure it’s just as nimble as before. If you demonstrate that ability to manage change, then you also demonstrate that the limited funds are best in your hands.
Wow - the 4 stages of product development seems quite spot on from my experience working on b2b enterprise software products.
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.
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.
Oh god, no.
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.
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.
I disagree, if you're able to understand and do a projection, forecast, risk analysis, sunk cost analysis you can easily get finance on your side.
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.
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.
> “it is not souless, it guides the entire company…”
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.
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.
> i presented a detailed financial projection (using monte carlo on the assumptions/inputs) .. went over the head of the controller (and acting cfo at the time). boy was i disillusioned after that.
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.
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.
> Or, percentiles of the sum of two Normals do not correspond to the sum of the percentiles etc.
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?
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?
Finance is like the engineering department in Star Trek. They provide critical resources, and are limited in what they can do by the laws of physics, but they still have to respond to constant demands from executives to somehow make it work anyway. That means they aren’t steering the ship, but they are going to interpret guidance from the captain about priorities in ways that make sense to them.
Which, incidentally, is the very same challenge IT, or Product Development, or HR face.
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.
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.
> I disagree, if you're able to understand and do a projection, forecast, risk analysis, sunk cost analysis you can easily get finance on your side.
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.
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.
> 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.
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.
Spot in with the automation! Too often people rush to build a new system without thinking first about the systems and processes that already exist.
This is something I've been interested in for a while. Do you think it's worth getting an MBA or some other financial degree if you're already in the workforce, or can you learn enough on the fly?
I asked the same question a few years ago (tech background, needed to uplift my business knowledge/lingo). The response was "you should find a way to obtain the knowledge of an MBA, without having to do one".
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.
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.
I do not recommend getting an MBA or some other financial degree. Rootsudo's response is excellent. There are actually very few financial concepts involved in these types of analyses (e.g. discounted cash flows, IRR, and NPV).
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.
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.
Thanks, appreciate the suggestion.
FP&A agrees. For what it’s worth, I never did MBA. I did finance undergrad and it just felt duplicative to do it again. It can be limiting to an extent but it’s also meritocratic once you’re in. It’s a screening question for many employers at the manager/director level and up but if you haven’t built a strong enough network by then than something is off anyways. (Make friends with recruiters.)
I would agree strongly with the comment to which you are replying (the parent? This is my first time commenting :). The primary benefits of an MBA are not the knowledge learned and said knowledge is shallow enough that it is feasible to gain it without the degree.
DevFinOps and Cloud cost efficiency is a thing. As more orgs move to utility based pricing, understanding and optimizing spend and accurately projecting are becoming much more valuable.
So, I’d say go for it if it’s something you think you’d enjoy.
So, I’d say go for it if it’s something you think you’d enjoy.
> I disagree, if you're able to understand and do a projection, forecast, risk analysis, sunk cost analysis you can easily get finance on your side.
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.
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.
> And that includes the finance department, of which I've certainly seen some of the most stupid ideas.
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...
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...
> “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.
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.
> I wonder what such stories, if true, teach us for the future.
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.
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.
Switching to the new provider was a bad idea, because it is not that hard to find competent civil engineers who could tell you that rather than being a mysterious unquantifiable risk, putting the new chemical in the lead pipes would cause a problem. "Every decision that went badly was a good decision if it seemed good at the time," only holds water when it's not easy to figure out in advance what's going to happen. After all, to a sufficiently ignorant person, 50% of all decisions seem better than average.
You might be right. Or not too much - at least for me, when I heard that story, this particular decision seemed odd - surely such obvious ways to save on expenses were considered before, so why they were rejected? In general, if something seems good on the surface it doesn't necessarily actually is - and in complex systems, like a town, some checklists - I'd expect - should be followed.
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.
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.
Whoosh
Full disclosure, I am a CFO and have spent much of my career in Finance. I have never worked in a place where I or anyone else there thought Finance is "any more intelligent than the other players in the company."
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.
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.
The finance business area at the last large company I worked for was borderline ridiculous. The division I was employed at ran a billion in revenue through Excel sheets scattered across network drives. FSS had a nightmare of a week at the end of every quarter. I was given a promotion and a shift from engineering to business analysis with the goal of creating a model to predict workforce requirements for ongoing business and new contracts. After a few months of learning the ropes and the history of similar attempts, it became clear that the company already held a license for software suitable (perfect) for this goal and the finance area was already slowly working towards ditching the excel mess in favor of the sane solution.
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.
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.
It is sad how much of Finance (primarily FP&A) gets run through Excel. There are many products out there today that can make the job easier, but as you point out, not all organizations are quick to embrace them.
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.
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.
>My personal hope is financial analysts get more tech savvy over time.
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.
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 think one of the communication challenges in this broad discussion is what is a "finance" person. Several people refer to them as people in Accounting (accountants) when I think they really mean Financial Planning & Analysis (FP&A analysts). Within most Finance organizations there is a big difference. Accountants (particularly early in their career) focus primarily on the past and properly describing it in the general ledger following accounting rules (e.g. GAAP / IFRS). FP&A analysts (should) focus on forecasting the future, then looking at what happens and describing why it differed from their forecast (variance analysis) so they can make a better forecast next time.
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.
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.
>I think one of the communication challenges in this broad discussion is what is a "finance" person. Several people refer to them as people in Accounting (accountants) when I think they really mean Financial Planning & Analysis (FP&A analysts).
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.
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 reason I think Excel sucks is that it hides the formulas behind the cells. There is no way to get good report on the mathematical MODEL written in an Excel spreadsheet, far less for a group of them connected together.
Or am I wrong? Is there an easy way to get a report that tells what a given spreadsheet calculates?
Or am I wrong? Is there an easy way to get a report that tells what a given spreadsheet calculates?
IMHO, you are not wrong. The advantage of spreadsheets is they are incredibly flexible. The disadvantage of spreadsheets is they are incredibly flexible.
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.
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.
There is an audit feature to follow calculations. My truck was to replace all equal signs with QXQ to make formulas visible and diffable
I am at a point where I don't think there should be finance departments in tech companies. I also believe there shouldn't be siloed data departments for the record either. There should be teams, build around a cohesive product goal that solves customer needs. There should be someone who understands the money side of things embedded in that department doing analyses and making recommendations to the product manager, not direct to a CFO. Maybe half their job is regular market analysis work too if the role isn't that big. Those product managers should then have in their day to day functions a requirement to get that info to a CFO's hands (who is really just the executive teams internal finance person) to make their case for their product.
For clarity, when you refer to finance, I think you mean Financial Planning & Analysis (FP&A). I think you would agree that centralized Tax, Treasury, and Accounting functions are ok and should probably report to the CFO.
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.
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.
Yeah basically but I've yet to work on a team (that I didn't build myself) where the FP&A is separated from Accounting/Tax and not a direct report to the CFO or CEO if the company is pre-CFO. Sometimes even seen Accounting/Tax as a direct report under HR with zero product connection. So I just hadn't come across that term before.
Computers first came into many companies via the Finance department way back when because they recognized what computers could do as glorified calculators, spreadsheets and accounting systems.[1] IT departments were often an outgrowth of those early systems. The only 'trick' to dealing with finance people is being able to draw a direct line between a proposal and either increased revenue or decreased costs. For solutions that can do that, they are often your best champion short of having the CEO already on board. For solutions that require a leap of faith/vision/creativity, they're probably not the place to start.
[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.
[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.
> Computers first came into many companies via the Finance department way back when because they recognized what computers could do as glorified calculators, spreadsheets and accounting systems.[1] IT departments were often an outgrowth of those early systems
And yet, somehow, IT departments ended up getting classified as cost centers by the finance department.
And yet, somehow, IT departments ended up getting classified as cost centers by the finance department.
If they don't directly contribute to the bottom line, that's how they should be classified from an accounting perspective. There are at least a couple of ways IT departments could avoid that fate: having internal customers pay for their services independent of the cost or directly managing projects that otherwise contribute to the bottom line. It's rare, but it does happen.
I have worked in FP&A for the past 6 or so years after working in the investment world. For a short time (8 or so months) I supported a CIO and had to approve the NPV analysis of every tech project that the company did.
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.
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.
CFO's makes the worst CEO's for a reason.... This has been true for all of time, if you work for a company that has a CEO that spent their entire career in Finance... RUN
Agree, so my best choice is start from value stream. Culture is not specific.
> 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.
That's great for long term shorts.
That's great for long term shorts.
Well it _is_ a common trick for "making the bride pretty" or for short-term incentivized CEOs:
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.
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.
Manage cash flow in a unpredictable ever changing environment for a month and come back and tell us what you think a finance dept does cause from the comment its quite clear you really dont know.
Perhaps here would be a great place to let a few hundred developers know.
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.
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.
And that man/woman is the CEO.
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.
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.
I worked for a company where capex was cheap and easy and opex was hard to get.
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.
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.
This is not a Finance function issue. Finance has absolutely no preference between opex and capex. There are accounting rules that determine the appropriate classification and any reasonable CFO simply wants it done correctly.
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.
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.
This was an independent, but publicly funded, company. So a combination of cluelessness and perverse incentives.
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.
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.
It is unfortunate you had such a bad experience. It's even more unfortunate that there a many more such companies out there.
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.'
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.'
> I worked for a company where capex was cheap and easy and opex was hard to get.
This is sometimes the same in the public sector. Oversimplifying: capex can be funded with a bond, but opex increases come from taxes.
This is sometimes the same in the public sector. Oversimplifying: capex can be funded with a bond, but opex increases come from taxes.
Was capex preferred due to preferential tax treatment?
No. You actually get better tax treatment for opex as you can record the full amount of the expense immediately as a deduction against your income. Capex spreads the deductibility of the expense over years.
As I mention above, opex vs capex is usually a compensation issue.
As I mention above, opex vs capex is usually a compensation issue.
The stages mentioned in this article are exactly what the company I last worked for went through. Inevitably they lost customers to other products with faster release cycles. The company is still limping along but at a fraction of their former revenue. It's sad, really.
It's obviously going to strongly depend on the context, but I've found that there is a shared amount of risk in organisations where IT and Finance both have their choices to make together.
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.
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.
From an operational view finance and IT are more aligned than they are not. Finance is all about cash flow; where it's coming from and where it's going. And IT is all about data flow; where is good data coming from, what is it doing, where is it going. In my experience in IT most of the infosec applies broadly to the organization it's especially the case when working with sensitive financial information.
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.
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.
Last part made me chuckle
Finance is an excellent place to start. It's very common for IT directors to report to the CFO - not the CIO or CTO, but the chief financial officer. CFO's are (ideally) great at saving money, and it's likely they will begin to do so by pinching pennies within IT. Think about that - someone who has an entire career around a specific discipline(finance) directly governing another discipline(IT). They cannot hope to make informed decisions based on the current state of the industry unless they are neglecting their primary responsibility of finance.
tldr; yes, "starting with finance" is a good way to transform IT.
tldr; yes, "starting with finance" is a good way to transform IT.
No company where the core product is technology should have an engineering team that reports to the CFO.
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.
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.
That doesn't make any sense at all. What is the thought process behind putting IT under finance? Seems like if you don't have a cto or cio then reporting to a coo or even ceo makes more sense than cfo.
Cash is ultimately truth in the business. You can bullshit people night and day, but the bank account doesn’t lie.
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.
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.
> 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.
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.
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
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.
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.
So just because you know how to count the $ does not mean you know or are competent to decide how it is deployed or see the bigger picture.
Agreed, and actually many times the money people are complete idiots.
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.
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.
IT can be a money sink for finance, under the wrong direction.
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.
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.
When I have seen this done, it is because the CEO does not want to get into the details of IT. At that point IT needs to report to someone. There may or may not be a COO. Sometimes see it reporting to a Chief Administrative Officer (CAO), but as landryraccoon points out above, this is not the case when technology is the core product of the company.
This is just a guess, but for some companies at some point in their lifespan, finance and IT were the people who sat at computers all day.
IT is a cost center and very expensive.
This is fundamentally what Europe especially and some non-tech large US firms don't get.
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.
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.
Most software engineers are employed in companies whose product is not software but something else; and their "software products" - which may consume many developers - is not a product, but workflow support for the people making/selling the actual product of the company.
This is only true if you are a software company that makes money selling or servicing software. I work at a mega bank and we produce tons of software. It’s still a cost center, a means to an end.
The only distinction I see is that software developers want to believe they are somehow more special than everybody else.
The only distinction I see is that software developers want to believe they are somehow more special than everybody else.
I mean, everything is a means to an end to make money. Google isn't selling ad tech software, they're selling space on websites to advertise. The tech is just a means to an end for that.
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.
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 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...
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...
C_O's are expensive.
That’s only if you take a naive view of IT (which most people do because it’s the lazy approach). Laptops, servers, networks, email boxes, etc. should all be charged back to the departments those are actually being provided to. When you do that, suddenly IT is making a lot of (internal) money, and the business can see where the costs actually are.
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.
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.
IMO, if you're going to charge everything back to the business units then you also need to provide some kind of consulting-style services, or best practices, or guidebooks, or something.
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.
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.
You make very good points. This kind of system only works with strong support from the CEO, where everyone is firmly “on the same team” and has designated positions to play (e.g. IT has to provide the IT stuff). Once you allow shopping around within the company or externally, you end up in a shitshow.
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.
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.
> should all be charged back to the departments
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.
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.
> 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
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
I did that when I was CIO at a non-tech firm; all IT costs for hardware, software and services (including ISP lines) were apportioned to the various floors and depts by seat basis.
10 years later, my ex-CFO still thanks me for what I did, and wish I was still with the company.
10 years later, my ex-CFO still thanks me for what I did, and wish I was still with the company.
> Laptops, servers, networks, email boxes, etc. should all be charged back to the departments those are actually being provided to
Wait there are companies that don't do that?
Wait there are companies that don't do that?
Pretty much most of them. Anytime you hear people complaining about how IT is nothing but a huge expense (which is by far the biggest complaint made by business people about IT), they’re in a company like this.
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.
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 it’s a bit more nuanced than that.
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.
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.
security; worker health & safety; responsible waste disposal, etc... are inevitably costs through the lens of a quarterly financial summary.
They are, as are salaries. Let me propose it this way, how much do you think the company should spend on responsible waste disposal? 10 dollars? 10 thousand dollars? 10 million dollars? 10 billion dollars? Why do you pick the number you did? What is the benefit to the company of making the investment? Those answers should be the start of the conversation on whether to make the investment.
IT is just a cost... it doesn't create anything, doesn't produce anything, ROI is zero...
...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.
...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.
IT reporting to a CFO or a comptroller has been common in my experience.
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.
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.
I think it's usually the other way around. Bean counters drive IT professionals around.
Conway's Law Revisited: If finance dictates your organizational structure, then finance is developing your software.
Seems very familiar.
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.
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.
Wasn't if finance that decided that IT should be cost center for every company?
I think this holds true mostly for B2B SAAS platforms but not for the rest.
I think this is mostly true for B2B SAAS startups but not for the rest.
Looking at Marx's quote on relations of production, could the money flow INSIDE a company be another topic that is worth exploration? From my simple understanding, in Marx's theory it was social aspect that mattered most. Do we still face such problems as it was in 19th century? I'm curious whether it would be a viable company where the surplus-value is distributed among workers and I have a fixed transparent salary as CEO and how it will survive the stage I and scale to stage II, IIIa, IIIb.
IT and Finance report to CEO. If you have clueless boomer CEO who doesnt understand what is digital transformation, then nothing will help
If the CEO doesn't listen to anyone who works for them, you're going to have many problems. If not, you might want to work on your communications strategy: in particular, ask whether the problem is that you failed to communicate the business benefits from a proposed modernization plan or are just repeating consultant babble.
IT and Finance are just executing CEO's strategy and vision.
A lot depends on hiring - whether CEO/Board is capable of hiring competent CFO and CIO. WIth CFO it is easier, because finance has been around since money was invented and a lot of hard problems have been solved in finance and there is vast theoretical body of knowledge backing it up. a lot of it is straightforward.
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
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
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.