Problem with selling developer tools is that devs have no purchasing authority(twitter.com)
twitter.com
Problem with selling developer tools is that devs have no purchasing authority
https://twitter.com/d_feldman/status/1779203622351339955
188 comments
Excel is ubiquitous because literally anyone can use it. Unlike a database, there is a direct visual representation of what you’re building. It is included in all m365 licenses and has been relatively cheap for a perpetual license for years.
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??
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??
Yes I have been on the senior management team of several companies and have worked with sales. Your lazy stereotype is as bad a suggesting programmers all sit in dark rooms with starwars T shirts and Body Odour issues.
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.
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.
> because corporate IT were too pig ignorant to help them
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.
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.
IT is a cost center so management geduces their budget as much as they think they dare. When IT struggles to afford a good backu, system they can't afford to figure how to support whatever tool will help you.
[deleted]
> Yes I have been on the senior management team of several companies and have worked with sales. Your lazy stereotype is as bad a suggesting programmers all sit in dark rooms with starwars T shirts and Body Odour issues.
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.
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.
>Excel is ubiquitous because literally anyone can use it. Unlike a database, there is a direct visual representation of what you’re building.
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.
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.
Excel is so ubiquitous because it is the only IDE/Programming Language/Database Environment business users can run in a restricted corporate IT environment.
And the self service coding platforms I have seen provided by corporate IT are wonderfully inadequate and useless. Corporate IT looks at the average business user who admittedly can't code even if their life depended on it and thinks "that's my client". Except that 99% of the end user automation is done by the 5th percentile of business users (the "spreadsheet monkey" of the team, I was proudly one!), those are their real client, and they are way more sophisticated, and that's only increasing as kids pretty much all get exposed to coding in school and college.
In a lot of companies, web sits under marketing...
Pretty much. Companies won't approve buying an individual book, but they will approve a subscription to a learning platform.
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.
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.
Back in the day at Hughes Aircraft, and later, at least for a while, at Boeing, we had a "Library", though which anyone could request a book. If the library did not have it, they would purchase a copy, and "loan" it to the requestor indefinitely. If another request for the same book came in, the original requestor would be asked to "return" it to the library. The library also maintained subscriptions to all relevant technical journals and standards publications.
This system was awesome because book purchases did not require management approval, so there were no denials and little delay involved.
This system was awesome because book purchases did not require management approval, so there were no denials and little delay involved.
A learning platform that costs the same as a book per month per employee, and doesn’t have the book on it.
You weren't listening. It's one platform, which means that the guy that costs the company $200K annually who approves expenditures wasn't overworked and could eliminate a bunch of waste across twenty teams.
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".
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".
My experience is that while sales can have good tools at department level, they do not have a lot of buying power
However it looks like marketing people have a lot of buying power, probably since their job involves buying a lot of random things.
However it looks like marketing people have a lot of buying power, probably since their job involves buying a lot of random things.
Even as a boss getting tools approved can be a hassle to sell to higher ups. 80/mo per user is practically free compared to payroll but is aways a hurdle.
> 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'
... 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
... 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
All of which is true. I used to run a smallish IT team. The problem comes with the failure to offer an alternative to solve the issue the person has.
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?
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?
If you have to fight for a 50$ book, you‘re probably just at the wrong place.
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...
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...
This is just an example of predatory pricing models and dark patterns.
There is reason many SaaS companies usually have no prepaid or fixed cost roof pay options. They are scammers.
There is reason many SaaS companies usually have no prepaid or fixed cost roof pay options. They are scammers.
How does anything think setting up a system where you can get billed for clicking a link is a good idea? Along with no sensible monthly limit on the credit card. The whole setup is beyond ridiculous, and it's hard to believe this is how "devs having no purchase authority stories usually start".
I work in a small company and we use a few services that bill for active users, and sync with g suite. It reduces the overhead of admin for me significantly as it means I know we're only paying for people who use the service that month.
> 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.
> 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.
A $10,000 invoice also means that procurement gets involved on the buyer side and sales on the seller side.
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.
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.
After the fact. That doesn't change thr
E fact that a card with a $500 limit can generate a $10k invoice, which you need to go to your manager to tell them about.
[deleted]
Aren't this sort of dark patterns exactly what are expected from growth hacking and getting numbers look good? Whole sub-set of companies are incentivised to use these tactics...
Billing by active users is quite common.
Developers (or anyone) buying tools can often also be a sort of local optimization, at the expense of the larger organization. For instance fragmentation, so that you can't find things through a single search anymore, or need to log into different teams' tools separately. Not to mention the compliance nightmare if you want to be SOC compliant while teams are all managing their own tools full of company IP.
Buying books and other learning resources is great, though.
Buying books and other learning resources is great, though.
I've been a decision maker on $100M+ of engineering hardware/software/services spend per quarter and here's my perspective on this problem:
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.
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.
#7 Is usually not so black and white. This is most difficult when the buying product is already in-house and you are looking to replace it or add new functionality.
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.
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.
Thank you. I know enough to appreciate that list was built on some hard lessons.
Thanks so much for the list!
It depends on the company. One company I worked for had a policy of "Just buy what you need that makes your work easier: books, licenses, and even hardware. Management time spent on decisions is too expensive, so we default to instant approval." Did developers go on a buying spree? No, the same amount of stuff was bought as before the policy. And it did make life easier.
Actually, it's just considering books, licences and hardware as disposables like pen and papers... and it can usually be true for some "small" local software (like an IDE, provided that either you trust the devs with admin rights or that corp IT can allow software installation). You can give either a "small" bugdet for everybody (and you wont be a software the same year that you buy a new laptop) or managed by the team/department
But it doesn't work when you need corp IT for corp IT integration
But it doesn't work when you need corp IT for corp IT integration
Large expenses like laptops could just be treated the same way accounting will treat them: if you spend $2100 on a laptop that's counted as $700 spent now, $700 in a year, and $700 the year after.
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.
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.
I really like that idea and I don't want to suggest that it can't ever work, but the sudden purchase frenzy that did not happen is far from the only failure mode. Leave it running a decade or two and things might look very different. Slow, invisible expenses creep and in the end you have a culture where those who spend a little slower than others are shamed into buying stuff just to make the others not look wasteful. There are many subtle mechanism at play that all facilitate expenses creep and there needs to be something pushing in the opposite direction. I'd rate it an unsolved problem.
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)
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)
> "leave it running a decade or two"
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.
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.
> Management time spent on decisions is too expensive, so we default to instant approval.
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.
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.
My current company just has a few HR type people that take care of purchases like that. I literally email them a link to hardware or software I need and they get it delivered to me. This is the best way I've seen it done. I don't have to know anything about the order/deliver process the company uses.
Similar experience. Everyone got a credit card and was encouraged to use it.
Netflix?
Don’t hire idiots and assholes and this policy becomes pretty self policing.
This is the reason bureaucracy exists, the more people at a company the higher probably one of those idiots or assholes slipped through the cracks, at large companies you just have to assume they got in
This rarely works as it requires a strong personality to set the standard. That's a lot of trust in developers otherwise.
I only had this issue the one time while I was an employee: I wanted a Thinkpad, but management insisted I got a shitty Dell. In the end, they got me a Thinkpad.
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.
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.
Corporate life...
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.
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.
Companies like Dell hit every market segment from 150$ crap laptops through 4 hour on-site service support. It's all down to the support contract your organization has and which product segment they're buying from.
Anecdata yada yada, but both colleagues of mine with a Dell XPS had trouble with them. This is Dell's top of the line productivity laptop segment. Yeah we got top of the line service. But the damn things still broke down in the first place. Critically, I recall one of them blue screened in the middle of some important infra changes and triggered an outage...
Same story with Precision and XPS. $3k laptops last 9 months if you're lucky. I literally have a pile of dead ones now. They don't even bother with servicing them.
This isn't everyone's experience - I've got two precision laptops - they are 12 and 10 years old and have never shown so much as a sniffle of a problem, neither has my Latitude laptop that I lug around for personal use. Maybe I just got lucky ?
You got lucky. We had about 1000 of them as a sample size.
Also yours are much older models. It's the new ones.
Also yours are much older models. It's the new ones.
Why is this company still in business…? Is everyone else worse?
If you have to ask, then you don’t have authority.
You can have authority while still having someone be accountable to the org. We had a situation where we were paying for three different presentation tools and two whiteboarding tools for a team of 30 people because two people had minor preferences.
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)
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)
Generally, nobody has authority. Even the highest executive has to fight procurement in a big corp. Own a VC-backed startup, the investors want you to get prior agreement on 'large' purchases. Maybe if you are the sole owner of a small firm without a purchasing department.
Politics always has people insert themselves in the flow of money.
Politics always has people insert themselves in the flow of money.
It depends on how strictly the request is scrutinized. I can spend exactly 0€ myself. But when I request a new machine, the order is placed immediately.
On the other hand I requested three months access to frontend masters which was promptly denied citing I should use our Udemy subscription.
On the other hand I requested three months access to frontend masters which was promptly denied citing I should use our Udemy subscription.
Ha. I used to work in a sales-oriented subsidiary of an engineering company.
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.
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.
So much this. At one of the big tech companies, we needed a hard drive for something. It was going to be easier to buy a $5K drive array and shuck the drives than expense $200 on a single HDD. Trying to buy stuff 'outside your lane' was crazy.
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.
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.
I purchase my own software licences and claim it on tax.
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.
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.
> I purchase my own software licences and claim it on tax
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
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
I've been doing the same things for many years at this point
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
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
In many companies you’re in big trouble if you get caught doing that
> … claim it on tax.
How does a U.S. employee (exempt, W2 form) do this?
How does a U.S. employee (exempt, W2 form) do this?
And how do you get above the standard deduction...
Jetbrains is like $200 / year. Only $27,500 more to go!
You dont (unless you’re 1099)
If you qualify for itemized deductions, which you do if you have a mortgage, you can claim things you need for professional development, etc. Subscriptions are a good catch-all. The IRS meant magazine subscriptions, but...
Only a few categories of people get to claim professional development expenses as a tax deduction [0], mostly self-employed.
> 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.
[0] https://www.irs.gov/taxtopics/tc513
> 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.
[0] https://www.irs.gov/taxtopics/tc513
There’s no but - if you do this and get audited, it’s not going to fly
Unless you can put on azure/AWS/Google cloud.
I can't buy a pencil without approval, but I can spend thousands in our cloud without asking anyone.
I can't buy a pencil without approval, but I can spend thousands in our cloud without asking anyone.
And there's the magic of the Amazon marketplace. Let's you buy non-AWS services while still ending up on the AWS bill and contributing to any potential spending commitment the company has.
Does Amazon allow competing services to be sold on AWS marketplace ?
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 ...
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 ...
I've never been on the seller side, so I don't know exactly what policies there are around what products can be sold. But to give an example, Datadog is available on the AWS marketplace, which offers a competing product to CloudWatch. I do believe you have to deliver your service via AWS somehow, such as via an AMI or container image etc but the service itself doesn't have to be on AWS as far as I know.
Doesn’t actually work because purchasing on marketplace is still restricted.
Indeed. I asked a dev to set up an ftp server. He was a decent Linux admin and had done this plenty of times on a £10 vps. This time he chose an AWS service that cost over a grand a month. It caused me lots of trouble when I got my credit card bill, and we were already well into the next month of charges. After that I had to take tighter control.
Same and it's going to be a huge, uphill slog to get the right people to consider localstack. But if we purchase a corporate license the savings would instantly pay for it so I feel compelled to try even though it is isn't really my day job to do so.
You can buy LocalStack on the AWS market place if you want to hide it in your infra bill ;-)
To be fair, that's only because nobody has figured out how to integrate "terraform apply" with SAP approval workflows.
A business model based on engineers as the decision makers is perfectly possible. But it is confined to tools where an engineer can make a local optimisation without direct impact beyond that scope. IDEs are the best example. Engs in a company can be allowed to make whatever personal IDE decision that makes each one of them more productive, and the global impact of aggregating those individual decisions will be ok. Jetbrains is a testament to this.
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.
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.
Here's my puchasing power: "Boss, if we buy this developer tool it will save X hours of developer time." ... where X is large compared to the price of the tool. It works well enough that we use it often enough for Boss to be skeptical.
And skeptical they should be. Overestimating benefits, whether it's for a tool or something like a re- architecture, is right up there with underestimating effort, probably highly related...
Doesn't mean there aren't worthwhile tools, because there are, but they're few and fast between.
Doesn't mean there aren't worthwhile tools, because there are, but they're few and fast between.
How much time before you boss says: "OK, during the last 3 months you told me that all these tool would save you in total 1 dev/year... so I will reduce your team by 1 dev but keep the work and deadlines" ? ;-)
I had this happen. I was on a team that was overloaded by work generated by another team, that had the tools and capabilities to automate the work, but chose not to, because they didn’t have to deal with it. Spending time on their work meant other important tasks went undone, or were half assed.
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.
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.
“Developer time is not a KPI and we pay you the same whether you work 160, 180 or 200 hours a month”
Selling dev-tools to devs is like selling toys to kids - you target the parents (or the paying CxOs in the company). One should learn from the likes of Slack, Postman, etc. -- make it the de-facto tools for the devs/users and make them happy, then they go and ask their parents/approvers to buy them.
That's how you make parents feel good about themselves, that they did something useful, while their kids are unhappy with shit pseudo-toys they got. That's how amateurs and people who mistake priorities in edutainment do things.
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.
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.
> 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.
Perhaps the reason why this doesn't work with devs is that typical devs are much worse marketers than typical kids. :-)
> 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. :-)
That’s right you have to impress both the devs and the “parents” and they usually appreciate wildly different things. That’s why devtool space is hard
Correct - and this can be extended into any ML/AI team within a company too. The folks wanting to build something advanced or innovative will never have the authority themselves to get the tooling they need. Writing from experience here, my team wanted to get a application (or even a trial of a particular application) that would help with LLM hosting and model building, and it had to go up to SVP level to get sign-off.
If your management doesn't get you the stuff you need to be productive your company is a failure. Move somewhere else.
Depends on the tool. I've seen engineers ask for an IDA license to try to debug a pretty simple memory overrun crash. The manager rightfully told that engineer to go use Visual Studio first.
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.
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.
My own stance as a lead is that it costs more than 50€ just discussing the thing, so we might as well just buy it.
Sure, but in the parent example it's more like a 2k-3k license, which makes sense only if you're going to use it regularly.
50€ can be literally less than 30 minutes of discussion over the item being bought.
A discussion involves two people, so halve that. A then consider the opportunity cost. A relatively rare 50€ purchase likely isn’t worth any discussion.
IDA costs thousands of dollars per seat
> Maybe not a red one, but at least mauve.
You mean mauve, as in "the universally recognised colour for danger"? ;-)
You mean mauve, as in "the universally recognised colour for danger"? ;-)
[deleted]
The problem is who decides what really matters? Every department is biased towards their own needs. Upper management is usually clueless when it comes to technical needs, even if they've done the job before - because it was probably 10+ years ago.
The individuals decide what matters to them. If the company thinks their employees are too incompetent to know what they need it's time to move on.
Most programmers are notoriously bad about estimating anything - ship dates, time to investigate bugs, time to close bugs, time to implement features, complexity, etc, etc. I wouldn't blindly believe a programmer about a tool increasing productivity by __ %. I would listen to their argument first, and look at their experience. I would believe them if they have made good decisions in the past, or if they were a senior/experienced person who understands these nuances. In any case, I hope you agree that there is a spectrum. Because disagreement is not about "incompetence".
Unfortunately, you just described 99% of employers. "Just quit" isn't an answer when there are no meaningful alternatives. Business views SWE/tech as a cost of doing business rather than an investment.
That really depends on how much money they are happily paying you to be unproductive.
Most companies in fact are. Just look at the survival rate.
I have never even heard of a company where a single person on the level of an engineer was able to spend 100k without getting approval.
Just ask for example sales persons on engineer level how easy it is to get 50€ for something they think will have a huge impact on closing a deal. They have the exact same problems.
According to our corporate portal, I have $100k of signing authority. Meanwhile, I can’t get approval for spend about $2k on flight and hotel to go to a conference that would be valuable for me. I’m going to end up paying out of pocket. I have co-workers who are afraid to order a new mouse when their current one is broken.
In my experience it's not about purchasing authority. Otherwise free software should be available without issue. But in large companies IT won't let you install things on your own devices.
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.
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.
I always liked the Sublime Text model. You pay once, and keep your licence no matter where you work. Same with my keyboard. I like to own my tools.
Everywhere I've worked the managers liked Sublimes model too. To the point where at one place we built a few plugins for Sublime because so many of the engineers were using it. It was cheap enough that reimbursing engineers for the license was easy to get approved and everyone liked being able to hold onto their individual license after.
Jetbrains tools are the same; you can buy personal subscription, and use the tools no matter where you work.
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.
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.
Keep in mind you can't use personal license at work.
You can, if you paid for it yourself. As long as the employer doesn't "pay, reimburse, or in any way finance your personal license".
To elaborate, yes, Jetbrains allows for this, but the employer might not. At my company, personal licensed software are up for individual approval.
LINQPad's model is similar but it didn't stop my last company refusing to allow me to use my personal copy due to "licensing". Some companies (read: managers) just can't be f'd reading a brief web page and applying 10 seconds of thought even if it means there's a chance a developer might be more productive, or god forbid, happier.
Create a developer tool that "makes easier" purchasing developer tools.
edit: popped as joke idea, but thinking about it might make sense if both developers and developer tools have this pain rn.
edit: popped as joke idea, but thinking about it might make sense if both developers and developer tools have this pain rn.
"Problem with selling developer tools is that devs have no purchasing authority"
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.
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.
So true. Getting a Copilot subscription for $10/mo was an uphill battle. My daily supply of coffee alone costs the company more that that.
Maybe I'm a dinosaur, but I wouldn't just approve an individual Copilot subscription either. The problem isn't the money, it's the copyright and whether trade secrets are being leaked. Those things can surely be solved, but it's far from trivial.
The general gist I’m getting from this comment section is a general lack of awareness over DLP and security. The thing half these comments are complaining about exist for very good reasons.
Every company I know that balked at using the "enterprise" version of either an OpenAI product or the equivalent Azure Open AI service already uses Microsoft 365, Teams, Azure DevOps, and Azure itself.
"We can't just give some unknown company our data!" screeched management.
"You already have."
"We can't just give some unknown company our data!" screeched management.
"You already have."
Some of the data is covered by the data protection and SLA agreement the company signed. Some of it is not.
Okay imagine you’re an employee. You are ranked against your coworkers based on individual productivity, either explicitly or implicitly.
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?
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?
Buying copilot on my own, using a personal account, would have me fired for violating our data security policies. No need to wait for a layoff.
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.
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.
Its usefulness really depends on what you're writing: typical Kubernetes YAML files get fantastic suggestions, while algo-heavy code not at all.
Can't you rebind the tab key in the VS Code plugin to something else?
Can't you rebind the tab key in the VS Code plugin to something else?
> 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.
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.
I would choose to play it by the book.
You need to present a business case. Offer to give up the coffee.
Still trying to get our team Copilot subscription for 2 months now.
I had to perform due diligence on that. The cost was meaningless.
Wow, they must use expensive coffee beans.
When I was in an office of about 200 people, the facilities manager told me the coffee machine cost him $60k/year. That doesn’t include the coffee people brewed outside of using that machine. That works out to about $25/person/month. That assumes everyone drinks coffee from that machine, which they did not.
I also heard that number at least 10 years ago, so I’m sure that price has only gone up.
I also heard that number at least 10 years ago, so I’m sure that price has only gone up.
Not really.
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.
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.
You guys get coffee? /s
In europe, my work, which has 600 circa devs, cannot use any other browser than Chrome. Have to get multi levels of sign offs to even login in Gmail.
When I raised this issue, they simply buried me in paperwork + got almost no support from co-workers.
When I raised this issue, they simply buried me in paperwork + got almost no support from co-workers.
Hence the common strategy to onboard companies when the company is still small (when developers either have purchasing authority or sit in a room with somebody who has) and try to lock them in forever
A good thing in my opinion. 95% of the tools are worthless. In a lot of cases a personal preference of a dev. Not a shared one. And sometimes sold by a sales representative to a dev. Important to have a guarden.
I would wager that some tools are like gloves or shoes, very important to have a good individual fit, to get best of performance.
It's pretty much like all enterprise software: you sell to the people with the purchasing authority. Meaning sales are often closed on the golf course.
...and get terrible solutions which the people on the golf course don't care about since they don't use them - or if they do they only use the reporting part of the feature set - so that's got to be great but the rest can be shit.
E.g. Atlassian
And kickbacks for the purchaser…
Hasn’t this begun to change though? I did a brief stint at Sinch (the Swedish Twilio) and “developer go-to-market” was an established term there. My impression is that developers have started using so many cloud services and APIs that the old school approach (“nobody in engineering buys anything!”) is starting to crumble.
Author been living under a rock?Engineering/dev first companies been popular since the 2000s. Developer salaries are often the most expensive thing, so everyone in the c-suite cares that their people are more efficient. Developer love is table stakes if you want to be put in front of someone who can purchase.
If only sales were as easy as emailing the CEO or CTO and having them agree to a meeting
If only sales were as easy as emailing the CEO or CTO and having them agree to a meeting
I agree with the point, but isn’t Jetbrains a good example of selling to developers?
If there was a way to get a company licence, I'd have bought it for our dev team.
Er what? https://www.jetbrains.com/business/
The conclusion is correct however the premises are not correct.
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.
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.
No, engineers are full of hubris, and arent rewarded fro bringing value to the company. They are rewarded for "solving problems" as in figuring out puzzles. Buying software isnt a puzzle to solve its just busy work.
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?!?!"
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?!?!"
Typically there is a price limit.
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.
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.
This is why the AWS marketplace is an incredibly powerful tool.
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.
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.
There are tools out there that devs pay for themselves. That's an answer to the paperwork insanity. If the tool is useful enough relative to the price, go with direct to (developer-)consumer.
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.
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.
As a VP of Sales selling dev tools, I noticed:
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.
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.
At my company, I can buy pretty much anything I want. I do buy hardware often. But software dev tools? I am trying hard to think of one and coming up empty.
Save for GitHub/Copilot, ChatGPT and Anthropic subscriptions. Those things are the only software dev tools I have found worth paying for.
Yeah, there are definitely exceptions to this. I had a company credit card for quite a while at a previous company. It did result in a bunch of other devs coming to me to get small things purchased (this was an appropriate use). The number of tiny things that were then not subject to silly red tape just provides supporting data for the original tweet though.
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)
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)
Not entirely correct, I have purchase authority for several million dollars a month in AWS costs.
A new mouse however…
A new mouse however…
[deleted]
You sell to CTO not developer, like you sell to CFO or to head of HR or head of Sales
the other problem is devs are cheap asses
I don't even bother trying to get money back. I buy, for example, GitKraken at any new job I start at.
I've been trying to get Excalidraw+ for my team since October. It's 8€/month/user.
There's plenty of consulting companies where developer = owner.
Also, JetBrains, Ida, Visual Studio Pro, VMware Workstation, Docker Enterprise, Colab Pro, HuggingFace, ... There's lots of paid tools primarily targeting developers.
Also, JetBrains, Ida, Visual Studio Pro, VMware Workstation, Docker Enterprise, Colab Pro, HuggingFace, ... There's lots of paid tools primarily targeting developers.
The tweet says that companies will be more successful if they can find a way to market dev tools to non-devs (coo/cfo) in the organization that have the authority to approve larger purchases and can push these tools down the hierarchy
....hence the great value of open source because a lot of those managers don't give a thought to what you put in your requirements.txt or package.json.
yes and no.
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? ;)
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? ;)
Your department head should have discretionary funds to cover $1000 easily. I understand this tweet is in jest, but cmon.
Monthly reminder that engineering is a cost center, not a profit center.
Except for those weird "software companies" that don't seem to do anything real yet have absolutely all the money.
[deleted]
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'.