When you join Octopus, you get a great laptop and your choice from a range of docks, monitors, webcams, and input devices. You also get a home office allowance, which lets you upgrade your space and get 50% back. You may want a sit/stand desk, an awesome chair, and portrait lighting so everyone can see how delighted you are when they demo their cool new feature.
What we ask in return is that you set yourself up to do your best work. Invest in your brain, bytes, back, and buns, as Scott Hanselman put it. The essential idea behind this is that when you win, Octopus wins. We all win!
Yet you can throw a soggy cat at a conference, and the chances are it will splash someone from an organization with a completely different approach to developer experience. One that doesn’t value the sustainable delivery of their people’s best work. Why is that?
A fork stuck in the road
As we’ve seen in the software industry, silos are the source of all kinds of chaos. DevOps was created when someone realized the scale of the problem caused by having two teams with conflicting goals working on opposite sides of the same problem. Leaders whipped developers up for feature throughput and wanted to hold operations teams to account for reliability.
In hindsight, it’s obvious that this isn’t going to work, but we did it for decades. You can get halfway to DevOps just by aligning the goals. When both teams share the same target, they’ll work out how to get you the rest of the way.
If we zoom out on our organization, we’re likely to find a similar silo/goal conflict between engineering managers and the finance team. We ask the engineering manager to build a high-performing team, while we direct finance to spend as little money as possible. This structural incentive problem leads developers to get laptops and tools that someone has negotiated to be “good enough,” and trust me, they aren’t.
When you look at developer experience through a FinBoss lens, where finance and engineering managers align around the return on investment, you’ll find the optimal spend on developer tools shifts right rapidly.
FinCost organizations reduce costs through standardization, commoditization, and by delaying kit refreshes for as long as possible. They often spend less than $1,000 on a laptop without realizing the true cost of an under-spec’d machine. Meanwhile, FinBoss organizations are seeking the $30,000 annual return on a $3,000 investment.
To achieve this ROI, finance and engineering leadership work together to design policies that allow engineers to choose from a set of well-designed options. The combination of investment in great tools and individual choice in building the right setup is the path to success.
Tiny visible costs
FinCost organizations are driving decisions based on small, visible costs. Where there’s a paper trail, there are savings to make: the purchase of a laptop, the training budget, and the conference invoice. These are part of the legible model, so there is no guesswork or experimental method needed to cost them. The numbers are right there on the page.
Once you’re managing costs, it’s not uncommon to dial up the control, too. You limit options, standardize across the organization, and negotiate in bulk on everything to drive costs even lower. Compared to competitors, you could be spending 75% less on laptops, and just look at the savings from those pesky licenses and SaaS tools various teams were using. Hooray.
Instead of letting engineers attend conferences they find relevant to their work, the organization negotiates a bulk purchase for a single conference. Instead of teams buzzing with diverse ideas and approaches, they all sit and watch the same talk. It’s cheaper that way.
A wooden fence encloses my garden. A fence lasts a long time if you give it a protective coat of wood preserver every once in a while. A tin of wood preserve costs about $20 and a few hours of mindful application each year. Over 5 years, I can save $100 by skipping the treatment. If I do this, my fence lasts about 10 years instead of 30.
The cost of a tin of wood preserver is immediate and visible. The cost of replacing the fence is far higher, but it won’t be visible for years. Additionally, if the fence provides value beyond privacy, like keeping a goat out of my vegetable garden, the cost of the fence failing could be the cost of my whole crop, which is even less legible to my cost control mindset.
If you’re creating software, it’s likely to be more valuable than a fence. In fact, it should be giving you returns multiple times your investment. It’s like a golden goose. You feed it well, and you get regular, valuable deliveries. If you had a golden goose, you wouldn’t try to save on food costs if it reduced the flow of golden eggs.
The same logic plays out with training. A FinCost organization cuts the training budget because the line item is visible and the return isn’t. Individual engineers stop attending relevant courses, and teams miss out on the steady accumulation of skill that comes from ongoing, targeted learning. Nobody raises a purchase order for “capability that didn’t grow this year.”
Then something goes wrong. Delivery is slow, the codebase is a mess, or a competitor pulls ahead. Someone decides the answer is transformation, and that means Scaled Agile, or whatever flavor of desperation is in fashion in exec suites at the time.
So the whole department gets booked onto an external SAFe course. Not one or two people who need it. Everyone. The invoice lands, and it’s eye-watering: many times what a thoughtful, ongoing training program would have cost across the same period. The organization that was too cautious to spend $500 on a course people wanted just spent $50,000 on one nobody asked for.
This is the hidden tax of FinCost thinking. Small, visible costs get cut. The problems that those small costs would have prevented quietly compound. Eventually, the pressure releases all at once, in an expensive, rushed, and hard-to-argue-against way, because now there’s a crisis with a visible price tag.
The tin of wood preserver was the right investment all along.
The invisible people-hours
Developers work around 40 hours a week. Stripe’s Developer Coefficient found that productivity friction can eat up roughly half of those hours. That’s the time that evaporates before a single line of useful code is written. Across the global developer workforce, Stripe put a number on that loss: $300 billion. It’s worth noting that only $85 billion of this is attributable to bad code. The rest is pure friction: slow tools, broken environments, waiting for builds, wrestling with under-spec’d machines. Productivity means more than writing code faster.
That friction has a texture. It’s a developer losing flow because their laptop is thrashing memory, and they’ve lost the thread of what they were thinking.
It’s waiting 10 minutes for a build that would have completed in 2 minutes on a faster machine. It’s the workarounds you built because the approved tool wasn’t good enough, which obliterates hours of your week for maintenance. It’s the skilled engineers who start looking for a new role because the environment makes them feel like you don’t take their work seriously.
None of this appears on a purchase order. None of it shows up in a variance report. It just quietly drains the value your software could be creating.
There’s also an upside case, not just a loss case. Software that ships faster captures more market share. Developers who stay in flow write better code with fewer bugs, which means less rework and fewer incidents. A high-performing team attracts other high performers. The return on investing in developer experience isn’t just “we lose less time”; it’s sales opportunities, reduced churn, higher product quality, and a compounding advantage over competitors who are still buying $800 laptops and calling it responsible.
When you focus on cost control, there’s a ceiling on how much you can save. When you look for return on investment, there’s no equivalent ceiling on how much you can gain.
The CFO lens
When I asked Sammy, our CFO, about why we invest in people, powerful machines, and great tools, he said: “At Octopus, we think about equipment as a productivity tool. Developers are one of our most expensive and constrained resources. If spending a few extra thousand dollars on a fast machine and proper screen space saves time, reduces cognitive load, or keeps someone in flow more often, it pays for itself very quickly.”
That means our finance team doesn’t ask “What’s the cheapest laptop we can buy?” Instead, they ask, “What setup helps this person do their best work?” From a finance perspective, this is about a high-ROI spend, not indulgence.
Octopus is running the FinBoss playbook, which aligns finance and leadership in empowering employees to do their best work. That means expanding what you’re willing to measure so that you can balance the visible costs with traditionally invisible returns.
The responsibility for providing this environment for employees rests with all leaders, including Sammy, and is part of the deal employees have with the company; we’ll give you the best environment and tools if you give us the greatest work of your career.
The reckoning
If we’ve ever met, I’ve likely mentioned DORA’s research. I’m a super-fan of their State of DevOps reports, because they provide us techniques, practices, and outcomes that are all linked through complex relationships. The model shows that transformational leadership, lean product management, and Continuous Delivery drive software delivery performance and organizational outcomes.
While many of the capabilities in the DORA model are technical, many others relate to leadership. Particularly relevant to developer experience are generative organizational culture, transformational leadership, empowering teams to choose tools, team experimentation, and a learning culture. You can read about these and more on the DORA website. Together, they back up the FinBoss concept with tens of thousands of survey samples that support the case.
The question is: Which organization are you now, and which do you want to be? Is it FinCost, operating myopically against the bottom line, or FinBoss, sharing the responsibility for developer experience and employee productivity? The fork in the road was never a choice. We know FinCost is a dead end, and the benefits of FinBoss aren’t soft claims; they’re measurable outcomes.
Happy deployments!
]]>
