Problem with selling developer tools is that devs have no purchasing authority
twitter.com
twitter.com
This is probably why Excel is so ubiquitous. Also that Excel is the most powerful tool that Corporate IT will let you have. Try and get Corporate IT to let you have WSL on your machine if you work in sales or Finance. That is probably why web apps are so popular. Corporate IT have to know about it to block you. A marketing manager can probably put Basecamp on her credit card, but it would be a huge job to get anything self hosted last IT with their policy of 'we are in charge of the computers and we will decide how you run your business'.
As for allowing WSL for sales, have you ever actually worked with someone in sales? At 99% of companies, even the most technically literate sales person can just barely send an email attachment without help. What exactly do you think they’re going to do with WSL??
I have seen sales people create very complex excel models, and use low code tools to build their own pipelines because corporate IT were too pig ignorant to help them. I have seen them use screen recorders to beat the lack of API access. Ihave seen finance people use WSL, Cygwin, Python, Anaconda and more.
Is corporate IT the issue here, or is it that companies aren’t setup in a way for random teams to dedicate time to build and support things for other random teams? The people in corp IT have jobs and deliverables, and none of them are building tools for the sales team.
I wouldn’t expect corp IT to build things for the sales team, anymore than I’d expect the sales team to help corp IT with selling a tool they want to upper management or the rest of the company.
If the sales team needs internal tools, then they need a dedicated dev team to work on those tools. Short of that, they will be stuck doing it themselves with whatever skill sets happen to be on the team at the time.
In my experience, this is not just an issue with the business vs IT. Even within IT, if a team of sys admins needs some tools, they will have to cobble something together the best they can, because there isn’t another team that will do it for them. Once or twice I see where a team with some skills needs some work and starts making offers to help other teams… one team ends up taking all their cycles, then down the road, it’s realized they don’t have a “real” role at the company, so the whole team is laid off, then the team still using their tools is left scrambling to find a replacement that can be supported.
And I’ve been in sales directly for over a decade, not “management that works with sales”. It’s not a lazy stereotype which anyone who has been directly involved would tell you. There are a very, very small number of technical folks that make the jump from SE to sales and retain their technical abilities, but the vast majority of successful sales people are borderline tech illiterate.
Oh no. Excel includes an entire programming language, namely VBA macros and if you give it to engineers they will use it. The reason Excel is ubiquitous is because it is Microsoft and someone is paying. The same is true for Matlab. A company getting Matlab licenses is much, much easier than someone getting a python installation.
It isn't a money problem. It is an Anti-Money prolem. If you can't pay someone you can't use it.
However it looks like marketing people have a lot of buying power, probably since their job involves buying a lot of random things.
It's too much work to approve all these random purchases, but if you don't review them, you end up paying for a bunch of unused subscriptions all over the place as well as people buying a ton of stuff that doesn't really benefit the company that much.
I mean sure, a cynical person might ask why even bother paying that guy when his salary could be divided up into $10K per team for a hundred books a year per team, but that kind of talk gets you dragged in front of HR for a "discussion".
This system was awesome because book purchases did not require management approval, so there were no denials and little delay involved.
... because we are also in charge of:
- the bills for the servers/networks/storage to "self host" your new shiny application
- the installation/upgrade/administration/support of the servers/networks... and of your application (because the finance department doesn't know how to do it)
- the integration of your "self hosted" application into the AD (for the SSO), mail system, slack, backup/restore system (in case of crash or hack)... and the maintenance of all of it
- eventually ensure that the application datas can be exported to other apps or migrated (when the new shiny self hosted app will be less new... and a new new new shiny self hosted app will be bought)
- the cybersecurity of your "self hosted" application... and of the whole corporate IT !!!!! Remember: a single application is enough to compromise the whole corp IT (OK... it can be segmented, 0-trusted, and so... be it increase attack surface and cybersecurity cost anyway)
In fact: BUYING a "self hosted" application is the EASY part, the HARD part is to make it RUN, DAY-TO-DAY, for AS LONG AS REQUIRED for the business (including legal requirements sometimes to keep datas for long time)
OK, when "local IT" ask for application, they usually can manage part of it technically but... either they wont (because they just dont have time! Remember: they want the tools to do their job, but the tool is NOT their job) or they cant (because they're devs and not admin sys/net sys and they dont know)
At most: they can use some "sandbox" unconnected to "corp IT", but then they either need to forget all nice things (like backup systems or AD) or to implement it and maintain it (shadow IT)...
IMHO, that's part of the explanation for the "SaaS" and "Cloud" development: externalizing all of these costs
My algorithm always started with, can we do this with our existing O365 licence. You can't have Trello or Asana, because we have Planner already. You can't have Slack because we have Teams. You can have Basecamp because the manager put a great case of why She couldn't do that on Teams. You can't have Jira because you only want bug tracking and it is too complex for your little team, how about self-hosted Redmine?
That being said, some developers wanted to test Notion internally, so they got an informal account with a credit card. Turns out they built an important overview in it and send the link around, so everyone who wanted to take a look at it (half the company) implicitly created an account and our CFO got hit by a 10k bill next month.
And that‘s how devs having no purchase authority stories usually start...
There is reason many SaaS companies usually have no prepaid or fixed cost roof pay options. They are scammers.
> Along with no sensible monthly limit on the credit card.
A £1000 limit doesn't stop you from generating a £10000 invoice. It just means you need to go higher with your tail between your legs to pay the bill.
Notion doesn't want 1 month of credit card spend tricked out of someone without purchasing authority, they want a site-wide deployment on an annual contract. The invoice is just a tool to ferret out who has authority to have the discussion; nobody expects it'll get paid as presented -- it's just the opening bid. Procurement's opening bid might be a chargeback and a org-wide ban on Notion -- and then you do sales dance.
Buying books and other learning resources is great, though.
1. If you are making developer tools, make sure current/existing developers find it super useful and are strong advocates for your tool.
2. Make sure you don't tick any of the 'veto' boxes – there are a few – opaque contracts, lockins, data security/privacy challenges, sso/auth integration challenges etc.
3. Make sure your pricing makes sense – if it scales linearly with some variable it is likely not going to make sense in some finance spreadsheet. A simple per developer per month fee makes a ton of sense. A site-wide floating seat license makes even more sense. For some, a lumpsum fee for site wide unlimited license makes even more sense. On the last option, you can still charge for your consumables – cloud compute/storage charges you incur – just pass it on as-is. Even better if you can deploy to customer's cloud account directly (that solves for all data privacy/security issues as well).
4. Provide sufficient cost controls – put an upper limit on billing, put an upper limit on usage. don't let anyone turn on any knob that can result in expensive usage charges etc. Also provide sufficient usage reporting facilities.
5. If you do a good job, you can sign multiyear contracts with committed spend. Make sure your service is reliable and you do a quarterly check-in with your large account customers to understand if they are happy or have specific unmet needs.
6. Remember, you can provide and charge for whiteglove professional services (dedicated butts in seat engineers, support etc). This is highly lucrative and also sometimes critical to win and keep certain types of customers. Sometimes your product is controversial inside the customer's company and there maybe detractors who will make your product fail. By having professional services do the initial integration/implementation job you can ensure your product reaches its intended users without much meddling from the IT gatekeepers.
7. Don't bother trying to sell something that a customer strongly believes they can build in-house (even if they are wrong). Even if you win initially, you will lose eventually.
The problem I have with #7 is the ROI on build vs buy. And, at what point do you determine this?
First, buying a product with very high integration cost is still "building". So I need developer time for integration, time that they could spend on something else or the product itself.
Hopefully this would come out during a POC integration, but then we still need developer time to execute.
But it doesn't work when you need corp IT for corp IT integration
Since you don't have to comply with tax codes for internal budgets you could even allow developers to choose (within reason) which deprecation period to use for each item.
Perhaps some generous budget limit, with a clear message that it's not intended to be fully consumed, and a clear rule that a certain percentage of whatever will be left at the end of the year is donated to some universally accepted good cause? Children and cute animals, please not religion. "You can get the book, no problem, but keep in mind that being the book means $5 less ponies!" (just don't make it manatees, you'd risk me working on a chromebook)
What expense policy survives a decade or two completely unreviewed and unexamined? The rest of the bullshit you spewed isn't worth reading after that bizarre hypothetical.
This is the problem. Management inserting themselves into any and every decision. People think management are there to help but they cause more problems than they solve. They are truly incompetent at best and a better idea is to fire a few managers and use their salaries as the discretionary budget. Win-win.
Other than that, whenever I've asked for a book or some tool, I simply got it, even expensive split keyboards.
Now that I'm self employed, I just buy what I need. Which isn't much, really. Very few "developer tools" are useful enough to spend money on, let alone try to integrate them in my workflow. That last part has become much more important to me over the years.
On the other hand I requested three months access to frontend masters which was promptly denied citing I should use our Udemy subscription.
I have to request a limited card for recurring spends, which comes with a "why" box. It makes people think about what they're buying just a tiny bit more. But I've never had a single purchase denied (other than the time I accidentally paid for a personal holiday on my work card because Google pay's default payment card on device and online are linked)
Politics always has people insert themselves in the flow of money.
I got a shitty Dell. It broke. I got another shitty Dell. That broke. I got another shitty Dell. That broke. I got a shitty Dell.
BUT WE ONLY HAVE A CONTRACT WITH DELL. Perhaps you shouldn't have a contract with Dell? Silence. Then the brain gets going.
You realise the best bits of your life are when the Dell breaks because it takes 5 days for them to work out how to send a new one out through the layers of PO and ordering politics which are responsible for the account with Dell in the first place. That is 5 days of bliss where you can't do ANYTHING because of the vicious corporate security policy so you sleep for 5 days, catch up on friends, be a human again.
I love Dell. I don't want a ThinkPad.
But I own a MacBook for my own use.
Also yours are much older models. It's the new ones.
In the early days, I could take people out for a $100 lunch, no problem, but I couldn’t buy a $30 card for my computer.
In the parent corporation, on the other hand, they could fairly easily get a $5,000 test rig, with no issue, but needed to fill out forms in triplicate to take you out to a fast food greasy spoon.
Towards the end of my tenure, you basically couldn’t do anything, at either place, without said forms.
But many successful dev tool companies have made their money by marketing to bosses, as opposed to devs. That goes for many fields; not just tech.
Just got done with an experience where the company I'm at said - you have a corp card - use it - with the EVPs signing off on whatever for that event. Very much not the norm, but it was eye opening that they knew sometimes the red tape needed to be cut. I'm totally expecting to fight with accounting on a simple taxi receipt because it did not say where the pickup/destination was for a $20 fare the next time I do a 'normal' expense.
Because it's a false economy.
I've won awards at work, became indispensable on certain projects, and have been given pay rises, choose the work I want to do, through finding the affordable right tools for the job and purchasing them.
My Jetbrains licenses are a classic example of this. I couldn't imagine refractoring code without it.
If the cost cutting stopped, I'd have more competition in the workplace.
How does a U.S. employee (exempt, W2 form) do this?
> If you qualify for itemized deductions, which you do if you have a mortgage
If you have a sufficiently large and expensive mortgage and/or are filing as an individual. Our interest almost got us over the standard deduction in the first year, but every year since then the standard deduction threshold just gets further and further away.
In theory you could do this via the UK tax system too – there’s a field on the Self Assessment forms that allows you to claim work related expenses that weren't reimbursed by your employer
One of my past employers paid a reduced mileage rate so I used to claim the difference on my tax return.
Quite how it would work for software I’m not sure though i.e. what’s the test for a permissible expense
Most companies refuse to buy the right software for the job and, like you, I'm the most effective person in my team since I can do things quickly and effectively unlike anyone else
I can't buy a pencil without approval, but I can spend thousands in our cloud without asking anyone.
Specifically, if rsync.net service (for instance) were targeted as a non-Amazon backup location, would Amazon allow us to sell our service on AWS marketplace ?
This presumably competes with S3 and other storage options ...
But this is not the same for every tool. The thread author focuses on examples that fall in this second category like Redis, Terraform, AWS, etc. Unlike with IDEs, sprawl resulting from individual decisions in databases, infra management or cloud infra becomes a problem. For both! The company has to maintain a heterogeneous stack. The seller can’t make a meaningful enterprise deal just because some team chose Redis. This means that you will want to do some standardisation. At that point the impact of the choice and the size of the license become big enough that, in the same way as eng leads will want a say, finance will too, for good reason.
And needless to say, the moment finance is in the picture you will have to justify the choice in a language that is challenging for most engineers.
Doesn't mean there aren't worthwhile tools, because there are, but they're few and fast between.
I pulled some data and did some math, and found that we could dedicate 3 people full-time just to working on their junk. My goal with this was to light a fire under them, get that stuff automated, and free up those hours so those people could do more interesting and worthwhile work.
It did light a fire, the stuff did get automated, and the week after victory was declared, 3 people were laid off. I was very upset and yelled at my boss a lot. It sent a very clear message to everyone on the team that automation is the enemy and when they see something they can/should be improved, they’d be smart to keep their mouth shut. That’s exactly what happened. Improvement efforts ground to a halt, as no one would talk about issues or use new tools that were developed.
Pros know that you always target the kids - not just for toys, but for many other categories of wares too. Kids may have no spending authority, but they're much better at marketing to their parents than you can possibly hope for.
Like, there's a reason you see Paw Patrol merch on every other kid everywhere - they release a highly addictive animated show for kids, and kids do the rest.
The reason this doesn't work with devs is because unlike parents of kids, people with spending authority usually don't care, as devs are a cost centre and a number on a chart, not people generating value.
> The reason this doesn't work with devs is because unlike parents of kids, people with spending authority usually don't care, as devs are a cost centre and a number on a chart, not people generating value.
Perhaps the reason why this doesn't work with devs is that typical devs are much worse marketers than typical kids. :-)
Otoh, if management isn't willing to drop $50 on a one time purchase that increases your productivity, it's definitely a flag. Maybe not a red one, but at least mauve.
You mean mauve, as in "the universally recognised colour for danger"? ;-)
The problem isn't money, you can get money at most companies fairly easily. The problem is that you actually need to be allowed to use it, which is far harder and far more costly than the cost of the product.
If you have a subscription for 12 consecutive months, you get perpetual fallback license for version of the tools that were available at the start of the period.
edit: popped as joke idea, but thinking about it might make sense if both developers and developer tools have this pain rn.
Wow, I said almost this exact sentence to my co-founder just a few days ago to explain to him why my no-code serverless platform which allowed me to build our entire startup, bug-free, in record time cannot be anything more than a side project or tool for my own usage and cannot be monetized.
It doesn't matter than I can build something 10x as fast and avoid 99% of bugs. Those with decision ability are brainwashed to think that the way to reduce bugs is TypeScript and the way to build software fast is React.
3 cups a day, 5 days a week, 4 weeks a month = 60 cups of coffee. If we say 15g of beans per cup means you'll use 2 one pound bags in a month which could easily be $20-$40.
I also heard that number at least 10 years ago, so I’m sure that price has only gone up.
You can choose to either spend $10/month to get a big productivity multiplier, or you can play it by the book, not use it, and be the first one out the door the next time the company decides it needs to find efficiencies in a down market. What do you choose?
I have access to it now, but it’s through the company with whatever policies they put in place through Microsoft’s enterprise offering.
Now that I have it, I don’t find it that useful. It has not been the productivity multiplier I was promised. A big part of this could be down to how the plug-in is built in VS Code. The tab key hijacking made me turn off suggestions. Based on the stats, only about 20% of suggestions are accepted. That’s too low a number to take control of a key used as often as tab.
Can't you rebind the tab key in the VS Code plugin to something else?
That was my goal. I figured tab + some modifier would be great. I spent quite a while looking for ways to do it, tried about a dozen, but it doesn’t seem like the feature exists. Eventually I had to just turn it off so I could actually get my work done.
"We can't just give some unknown company our data!" screeched management.
"You already have."
When I raised this issue, they simply buried me in paperwork + got almost no support from co-workers.
If only sales were as easy as emailing the CEO or CTO and having them agree to a meeting
1000 devs buying individually on average tools for 100 USD/month doesn’t make sense in any organization. Controllers will have their say and architecture or CTO should have their say, too. Tool usage corresponds with IT strategy.
Procurement tends to count in large numbers. That’s why a business unit usually decides.
It is up to the devs to raise the Business Case.
IT departments are usually considered Loss Centers. That’s why there is another road block, but not against productivity per se.
They look at a saas product and think "i could build that" and they might be right. But the current engineering culture doesnt look at that situation and go "why the frick would you want to?!?!"
Below the limit, there is an assigned budget for the dev team. You can buy online and the price is visible. Above that sum you must do sales negotiation and the price is not public in the sellers site.
If buying the tools for the whole team costs a few grand, you can buy it online. If the sum is higher the price is negotiated and costs the company at least five figures.
In most engineering departments they control their existing P&L which will include opex AWS spend. Spending within an existing vendor doesn't need budgetary approval as long as the opex doesn't exceed the budget.
It allows flexibility to find savings within the opex budget to spend elsewhere on better tooling.
I know instances of that working for jetbrains, sublime, beyondcompare, matlab and obsidian. I can see web browsers and off site backup fitting that model.
1. As mentioned already, if devs aren't already using it, it's an uphill battle to sell.
2. Having your product as OSS helps since it reduces barrier to entry - devs and being using your product without having to contact sales.
3. Large enterprises, e.g., Fortune 500/Global 2000, spend money to reduce risk, cost and improve productivity (and other reasons) - as long as devs will use the tool. Startups, smaller companies would complain about spending even a dollar (probably because so many tools are OSS)
4. Target the centralized dev intra leadership and team would buy and support other dev tools. A junior sales mistake is giving free sales resources (e.g., demos, trial support) to a distributed team or devs trying your product - they probably will never buy since they didn't have authority, and all you did was provide free OSS support to get them running. Coaching sellers to avoid this is key - steer these types to docs and community.
5. Sell the value of support. Sales will only help if speaking with a qualified opportunity with authority and budget - otherwise good luck in the docs and community. In large enterprises, that is not a strategy.
6. And to the sea of sellers who think they can cram down large contracts - get the initial pilot or purchase successful - help demonstrate metrics of its value - .e.g. productivity etc. and put it in an easy-to-consume way for real decision makers to understand. Then you are more likely to take down larger investments. And yes - even before that initial deal, explain a license model and examples of how this scales to be affordable and not linear. You look like the JV squad if you do otherwise and will not know why they stopped returning your calls. You get one chance to make a viable economic impression if deployed site-wide. Unless you work at massive software companies where you can cram down large purchases due to enterprise agreement quirks and holding customers hostage to agree to software they may or may not use. e.g., company heavily uses one product so vendor stuffs other products in the renewal.
There are also examples like Slack where it becomes a ground up movement that eventually results in the company purchasing the requested tool.
(Context: I was the lead engineer on the company emerging technology team, buying 3D printers, VR headsets, and hackathon supplies and many many things of this nature + travel related expenses)
A new mouse however…
Also, JetBrains, Ida, Visual Studio Pro, VMware Workstation, Docker Enterprise, Colab Pro, HuggingFace, ... There's lots of paid tools primarily targeting developers.
yes, authority is usually with CFO or line managers, how/when and for how much things are APPROVED depending on the company and its policies and NO as it's developers that come and (authoritatively) say "We need you purchase this and that, because ..." and are the ones that evaluate tools and make such requests. Also there's big difference whether we're talking some sw for $100 one time payment or SaaS service for 100K/month, imo.
And then there's of course freelancers and well-off devs that buy things for themselves that make their decisions on their own.
tl;dr; if you think that devs dont have authority, maybe its you or your sales skills/strategy/methods that fail you more? ;)