Fast richtig, aber ich glaube, auch Vertriebs- oder Finanzleute haben kaum solche Kaufbefugnisse. Deshalb nutzen alle die vom Unternehmen erlaubten Tools oder kostenlose Tarife, und am Ende muss man es dem Chef verkaufen.
Man muss damit überzeugen, dass es Zeit spart, Projekte transparenter macht und Freiheiten reduziert.
Das dürfte auch ein wesentlicher Grund sein, warum Excel so weit verbreitet ist. Excel ist zudem das mächtigste Tool, das die Unternehmens-IT zulässt.
Das merkt man, wenn man in Vertrieb oder Finance arbeitet und versucht, die Erlaubnis zu bekommen, WSL auf dem PC zu installieren. Web-Apps sind auch deshalb beliebt, weil die Unternehmens-IT sie kennen muss, um sie blockieren zu können.
Ein Marketingmanager kann Basecamp vielleicht mit der eigenen Karte bezahlen, aber wenn er ein selbst gehostetes Tool einführen will, wird es groß, weil es durch die IT-Richtlinie muss: „Wir verwalten die Computer, und wir entscheiden auch über die Arbeitsweise.“
Excel ist weit verbreitet, weil es buchstäblich jeder benutzen kann. Anders als bei einer Datenbank erscheint das, was man erstellt, in einer direkt sichtbaren visuellen Form.
Es ist in jeder m365-Lizenz enthalten, und Dauerlizenzen waren lange Zeit vergleichsweise günstig.
Wenn jemand vorschlägt, dem Vertrieb WSL zu erlauben, fragt man sich, ob diese Person je mit echten Vertriebsmitarbeitern gearbeitet hat. In 99 % der Unternehmen schaffen selbst technisch versiertere Sales-Leute ohne Hilfe gerade einmal, einen E-Mail-Anhang zu verschicken; was sie mit WSL anfangen sollen, ist mir schleierhaft.
Im Großen und Ganzen stimmt das. Unternehmen genehmigen nicht den Kauf eines einzelnen Buchs, aber sie genehmigen ein Abo für eine Lernplattform.
All diese Kleinkäufe zu genehmigen, ist zu viel Aufwand; prüft man sie nicht, sammeln sich überall ungenutzte Abos an, oder es werden viele Dinge gekauft, die dem Unternehmen wenig bringen.
Meiner Erfahrung nach konnte der Vertrieb zwar gute Tools auf Abteilungsebene haben, hatte aber keine besonders großen Kaufbefugnisse.
Im Marketing hingegen schienen die Kaufbefugnisse recht groß zu sein, vermutlich weil die Arbeit selbst damit zu tun hat, alle möglichen Dinge zu kaufen.
Selbst ein Vorgesetzter muss einen Tool-Kauf oft noch weiter oben verkaufen, um ihn genehmigt zu bekommen, was lästig sein kann. 80 Dollar pro Nutzer und Monat sind im Vergleich zu Personalkosten praktisch kostenlos, aber es bleibt immer eine Hürde.
Der Kauf selbst gehosteter Anwendungen ist schwierig, weil die IT dann für Server-, Netzwerk- und Storage-Kosten, Installation, Upgrades, Betrieb und Support, AD-basiertes Single Sign-on, E-Mail, Slack, Backup und Recovery, Datenexport und Migration sowie Cybersecurity verantwortlich ist.
Wenn auch nur eine Anwendung kompromittiert wird, kann die gesamte Unternehmens-IT gefährdet sein; selbst mit Segmentierung oder Zero Trust steigen Angriffsfläche und Sicherheitskosten.
Tatsächlich ist der Kauf einer selbst gehosteten Anwendung der einfache Teil; schwierig ist, sie über den geschäftlich erforderlichen Zeitraum jeden Tag stabil zu betreiben. In manchen Fällen müssen Daten auch rechtlich lange aufbewahrt werden.
Selbst wenn das Fach-IT-Team das Tool angefordert hat, kann es vielleicht einen Teil der technischen Verwaltung übernehmen, hat aber oft keine Zeit dafür oder besteht aus Entwicklern und nicht aus System- oder Netzwerkadministratoren.
Am Ende nutzt man also eine von der Unternehmens-IT getrennte Sandbox, verzichtet auf Komfortfunktionen wie Backups und AD oder baut und betreibt es als Shadow IT selbst.
Daher sehe ich einen der Gründe für das Wachstum von SaaS und Cloud darin, dass solche Kosten ausgelagert werden.
Wenn man kämpfen muss, um ein 50-Dollar-Buch zu kaufen, hat man sich wahrscheinlich die falsche Firma ausgesucht.
Allerdings haben einige Entwickler, um Notion intern zu testen, mit einer Karte inoffizielle Konten angelegt, dort wichtige Übersichts-Dokumente erstellt und dann Links herumgeschickt.
Die Hälfte der Firma, die sie ansehen wollte, legte stillschweigend Konten an, und im nächsten Monat bekam der CFO eine Rechnung über 10.000 Dollar.
Geschichten darüber, warum Entwickler keine Kaufbefugnisse bekommen sollten, beginnen meistens so.
Das ist lediglich ein Beispiel für ein räuberisches Preismodell und Dark Patterns.
Es gibt einen Grund, warum viele SaaS-Unternehmen Vorauszahlung oder Optionen mit fester Kostenobergrenze nicht wirklich anbieten. Das grenzt an Betrug.
Ich weiß nicht, wer ein System für eine gute Idee hält, bei dem schon das Klicken auf einen Link Kosten auslösen kann. Wenn es auf der Karte dann auch kein vernünftiges monatliches Limit gab, ist das gesamte Setup völlig absurd.
Das als „Beginn der Geschichte, warum Entwickler keine Kaufbefugnisse bekommen“ zu sehen, fällt mir schwer.
Wenn Entwickler oder sonst jemand Tools direkt kauft, ist das oft eine lokale Optimierung auf Kosten der gesamten Organisation.
Zum Beispiel sind Tools dann zersplittert, sodass man Informationen nicht mit einer einzigen Suche findet, oder jedes Team muss sich bei anderen Tools separat anmelden.
Wenn Teams Tools mit geistigem Eigentum des Unternehmens jeweils eigenständig verwalten, wird das bei angestrebter SOC-Compliance zum Albtraum.
Bücher oder Lernmaterialien zu kaufen, finde ich in Ordnung.
Aus der Perspektive von jemandem, der über Engineering-Ausgaben für Hardware, Software und Services von mehr als 100 Millionen Dollar pro Quartal entschieden hat: Wenn man Entwickler-Tools baut, muss man zuerst dafür sorgen, dass die aktuellen Entwickler sie als sehr nützlich empfinden und sich stark dafür einsetzen.
Man darf keine Vetopunkte berühren, etwa undurchsichtige Verträge, Lock-in, Datensicherheit und Datenschutz oder Integration von Single Sign-on und Authentifizierung.
Auch der Preis muss nachvollziehbar sein. Preise, die linear von irgendeiner Variable abhängen, ergeben in Finance-Tabellen wahrscheinlich keinen Sinn. Abrechnung pro Entwickler und Monat ist leicht verständlich, unternehmensweite Floating-Lizenzen sind besser, und manchmal passt eine unternehmensweite unbegrenzte Pauschale noch besser.
Auch beim letzten Modell können Verbrauchskosten wie Cloud-Compute und Storage weitergereicht werden. Wenn man direkt in das Cloud-Konto des Kunden deployen kann, löst das auch Probleme rund um Datensicherheit und Datenschutz.
Man sollte Kostenkontrollen anbieten, etwa Abrechnungsobergrenzen, Nutzungslimits, Beschränkungen für Einstellungen, die teure Nutzung auslösen, und ausreichende Nutzungsberichte.
Wenn man es gut macht, sind auch mehrjährige Verträge mit zugesagten Ausgaben möglich. Man muss die Zuverlässigkeit des Dienstes aufrechterhalten und mit Großkunden quartalsweise Reviews durchführen, um Zufriedenheit und unerfüllte Anforderungen zu verstehen.
Auch hochwertige Professional Services wie dedizierte Engineers und Support kann man anbieten und abrechnen. Das ist profitabel und kann entscheidend sein, um bestimmte Kunden zu gewinnen oder zu halten.
Innerhalb des Kundenunternehmens kann das Produkt umstritten sein, und Gegner können die Einführung scheitern lassen; wenn Professional Services die anfängliche Integration und Implementierung übernehmen, lässt sich die Einmischung der IT-Gatekeeper reduzieren und man erreicht die tatsächlichen Nutzer.
Produkte, von denen der Kunde fest glaubt, er könne sie selbst bauen, sollte man besser nicht mit aller Macht verkaufen. Selbst wenn diese Einschätzung falsch ist und man anfangs gewinnt, verliert man am Ende wahrscheinlich doch.
Punkt 7, selbst bauen oder kaufen, ist normalerweise nicht so schwarz-weiß. Am schwierigsten ist es, wenn es bereits ein internes Produkt gibt und man es ersetzen oder neue Funktionen hinzufügen will.
Die Frage ist, wann man den Return on Investment von Build vs. Buy beurteilt.
Ein Produkt mit sehr hohen Integrationskosten zu kaufen, ist faktisch dasselbe wie es zu bauen. Die Integration erfordert Entwicklerzeit, und diese Zeit hätte man für andere Arbeit oder für das Produkt selbst verwenden können.
Idealerweise zeigt sich das während einer Proof-of-Concept-Integration, aber selbst für diese Phase braucht man Entwicklerzeit.
Das hängt vom Unternehmen ab. Bei einer früheren Firma galt die Regel: „Kauft einfach, was ihr braucht, um euch die Arbeit zu erleichtern – Bücher, Lizenzen, sogar Hardware. Die Verwaltungskosten für die Entscheidung sind teurer, also ist die Voreinstellung sofortige Genehmigung.“
Haben die Entwickler daraufhin einen Kaufrausch ausgelöst? Nein, sie kauften nur etwa so viel wie vor der Regelung. Tatsächlich wurde das Leben dadurch bequemer.
Bücher, Lizenzen und Hardware wurden im Grunde wie Verbrauchsmaterial à la Stifte oder Papier behandelt. Für kleine lokale Software wie IDEs kann das meist passen.
Voraussetzung ist, dass man Entwicklern Adminrechte anvertraut oder die Unternehmens-IT die Installation erlauben kann.
Man kann allen ein kleines Budget geben oder es auf Team- bzw. Abteilungsebene verwalten, aber sobald eine Integration in die Unternehmens-IT nötig wird, funktioniert es nicht mehr gut.
Ich will nicht sagen, dass dieser Ansatz schlecht ist oder gar nicht funktionieren kann, aber ein plötzlicher Kaufrausch ist nicht der einzige Fehlermodus.
Wenn man das 10 oder 20 Jahre laufen lässt, kann es sehr anders aussehen. Langsame, unsichtbare Kostensteigerungen sammeln sich an, und es kann eine Kultur entstehen, in der Leute, die etwas weniger ausgeben, Dinge kaufen müssen, damit andere nicht verschwenderisch wirken.
Es gibt viele subtile Mechanismen, die Kostensteigerungen begünstigen, daher braucht es Vorrichtungen, die in die Gegenrichtung wirken. Ich sehe das als ungelöstes Problem.
Möglich wäre etwa, großzügige Budgetgrenzen zu setzen, aber klar zu sagen, dass sie nicht ausgeschöpft werden sollen, und am Jahresende einen bestimmten Anteil des Restbetrags an einen allgemein akzeptierten guten Zweck zu spenden.
Etwa: „Ihr dürft das Buch kaufen. Denkt nur daran, dass wegen dieses Buchs die Pony-Spende um 5 Dollar sinkt.“ Wenn es um Seekühe ginge, bestünde bei mir die Gefahr, dass ich mit einem Chromebook arbeite.
Das Problem ist, dass Manager sich in jede Entscheidung einmischen. Menschen glauben, Manager seien da, um zu helfen, aber sie schaffen mehr Probleme, als sie lösen.
Im besten Fall sind sie oft inkompetent, und es wäre besser, ein paar Manager zu streichen und deren Gehälter als Ermessensbudget zu verwenden. Alle würden gewinnen.
In meiner aktuellen Firma gibt es ein paar HR-nahe Zuständige, die solche Käufe abwickeln. Man schickt ihnen per E-Mail den Link zur benötigten Hardware oder Software, und sie liefern es einem nach Hause.
Ich muss die Bestell- und Lieferprozesse der Firma nicht kennen; das ist die beste Lösung, die ich bisher gesehen habe.
Ich habe Ähnliches erlebt. Alle bekamen eine Firmenkreditkarte und wurden ermutigt, sie zu benutzen.
Als Angestellter hatte ich dieses Problem einmal. Ich wollte ein ThinkPad, aber die Geschäftsführung bestand auf einem miserablen Dell; am Ende bekam ich dann doch ein ThinkPad.
Ansonsten bekam ich Bücher oder Tools einfach, wenn ich sie anfragte, auch eine teure geteilte Tastatur war möglich.
Seit ich selbstständig bin, kaufe ich einfach, was ich brauche. Tatsächlich brauche ich gar nicht viel.
Es gibt nicht viele „Entwickler-Tools“, die nützlich genug sind, um Geld dafür auszugeben, und noch weniger, die wertvoll genug sind, um sie in meinen Workflow zu integrieren. Mit der Zeit ist dieser letzte Punkt immer wichtiger geworden.
So ist das Unternehmensleben eben.
Ich bekam einen miesen Dell, er ging kaputt, ich bekam wieder einen miesen Dell, er ging wieder kaputt, und dann bekam ich wieder einen Dell.
Wenn sie sagen: „Wir haben nur mit Dell einen Vertrag“, und man fragt, ob sie vielleicht von Anfang an keinen Vertrag mit Dell hätten abschließen sollen, folgt Schweigen, und erst dann fangen die Köpfe an zu arbeiten.
Man erkennt, dass die Momente, in denen der Dell kaputt ist, die besten des Lebens sind. Bis neue Ausrüstung verschickt wird, dauert es fünf Tage durch Schichten aus Bestellanforderungen und Bestellpolitik, und in diesen fünf Tagen kann man wegen der drakonischen Sicherheitsrichtlinien des Unternehmens nichts tun.
Also schläft man fünf Tage lang, meldet sich bei Freunden und wird wieder ein Mensch.
Ich liebe Dell. Ich will kein ThinkPad.
Privat nutze ich ein MacBook.
Wenn man fragen muss, hat man keine Befugnis.
Früher habe ich bei einer vertriebsorientierten Tochterfirma eines Ingenieurunternehmens gearbeitet.
Anfangs konnte ich problemlos ein Mittagessen für 100 Dollar spendieren, aber keine 30-Dollar-Karte für meinen Computer kaufen.
Umgekehrt konnte man bei der Muttergesellschaft problemlos Testgeräte für 5.000 Dollar kaufen, musste aber drei Formulare ausfüllen, um jemanden in ein Fast-Food-Restaurant mitzunehmen.
Gegen Ende meiner Zeit konnte man auf beiden Seiten ohne dieses Formular praktisch gar nichts mehr tun.
Viele erfolgreiche Entwickler-Tool-Firmen haben ihr Geld damit verdient, nicht an Entwickler, sondern an deren Vorgesetzte zu vermarkten. Das gilt nicht nur für Technik, sondern auch für viele andere Bereiche.
Das kann ich sehr gut nachvollziehen. Bei einem großen Technologieunternehmen brauchte ich für eine Aufgabe eine Festplatte, und es war einfacher, ein 5.000-Dollar-Drive-Array zu kaufen und die Platte auszubauen, als 200 Dollar für eine einzelne HDD abzurechnen.
Dinge außerhalb des eigenen Zuständigkeitsbereichs zu kaufen, war absurd kompliziert.
Kürzlich sagte das Unternehmen: „Ihr habt eine Firmenkreditkarte, also benutzt sie“, und Event-bezogene Kosten wurden von EVPs genehmigt. Das war nicht üblich, aber es war beeindruckend, dass sie wussten, dass man manchmal Bürokratie abschneiden muss.
Beim nächsten normalen Spesenfall werde ich wahrscheinlich mit der Buchhaltung streiten, weil auf einer Taxiquittung über 20 Dollar Start- und Zielort fehlen.
Softwarelizenzen kaufe ich selbst und setze sie von der Steuer ab. So vermeidet man Scheineinsparungen.
Weil ich passende, günstige Tools gefunden und selbst gekauft habe, habe ich bei der Arbeit Auszeichnungen bekommen, wurde in bestimmten Projekten unersetzlich, erhielt Gehaltserhöhungen und konnte mir aussuchen, woran ich arbeiten wollte.
Meine JetBrains-Lizenz ist das Paradebeispiel. Code-Refactoring ohne sie kann ich mir kaum vorstellen.
Wenn die Kostensparerei der Unternehmen aufhört, werde ich mehr Konkurrenz am Arbeitsplatz haben.
Theoretisch ist das auch im britischen Steuersystem möglich. Im Self-Assessment-Formular gibt es einen Abschnitt, um berufsbedingte Ausgaben geltend zu machen, die der Arbeitgeber nicht erstattet hat.
Ein früherer Arbeitgeber zahlte eine niedrige Kilometerpauschale, daher machte ich die Differenz in der Steuererklärung geltend.
Bei Software bin ich mir nicht sicher, wie die Kriterien für abzugsfähige Kosten angewendet würden.
Ich mache das seit Jahren genauso.
Weil die meisten Unternehmen nicht die richtige Software für die jeweilige Arbeit kaufen, bin ich im Team die effektivste Person geworden. Anders als die anderen kann ich Dinge schnell und effizient erledigen.
In vielen Unternehmen bekommt man großen Ärger, wenn man dabei erwischt wird.
Ich frage mich, wie W2-Angestellte in den USA, die nicht stundenweise bezahlt werden, das „von der Steuer absetzen“ machen.
Mich würde interessieren, was es sonst noch für Beispiele gibt.
Wenn es auf Azure, AWS oder Google Cloud hochgeladen werden kann, sieht die Sache anders aus.
Nicht einmal einen Bleistift kann man ohne Genehmigung kaufen, aber in der Cloud des Unternehmens kann man ohne Nachfrage Tausende Dollar ausgeben.
Hier liegt die Magie des Amazon Marketplace. Man kann dort auch Services kaufen, die nicht von AWS stammen, sie landen aber trotzdem auf der AWS-Rechnung und zählen auch zu den Ausgabenverpflichtungen des Unternehmens.
Stimmt. Wir hatten einen Entwickler gebeten, einen FTP-Server einzurichten. Er war ein ordentlicher Linux-Administrator und hatte so etwas schon mehrfach auf einem VPS für 10 Pfund gemacht.
Diesmal wählte er jedoch einen AWS-Service, der über 1.000 Pfund im Monat kostete. Als die Kreditkartenabrechnung kam, wurde das zu einem großen Problem, und die Kosten für den nächsten Monat waren bereits erheblich angelaufen.
Danach mussten wir die Kontrolle deutlich verschärfen.
Bei mir ist es ähnlich. Die richtigen Leute dazu zu bringen, sich localstack anzusehen, wird wohl ein großer und mühsamer Kampf.
Aber wenn wir eine Unternehmenslizenz kaufen, amortisiert sie sich allein durch die Einsparungen sofort, daher fühle ich mich gedrängt, es zu versuchen, auch wenn es nicht mein eigentlicher Job ist.
Fairerweise muss man sagen: Das liegt daran, dass noch niemand herausgefunden hat, wie man terraform apply in den SAP-Genehmigungsworkflow integriert.
Ein Geschäftsmodell, bei dem Engineers die Entscheider sind, ist durchaus möglich. Es ist allerdings auf Tools beschränkt, mit denen Engineers ohne direkte Auswirkungen außerhalb ihres Bereichs lokale Optimierung betreiben können.
IDEs sind das beste Beispiel. Wenn man den Engineers im Unternehmen erlaubt, individuelle IDE-Entscheidungen zur Steigerung ihrer eigenen Produktivität zu treffen, kann die globale Wirkung all dieser Entscheidungen zusammengenommen akzeptabel sein. Jetbrains zeigt das.
Aber nicht jedes Tool ist so. Der Originalbeitrag behandelt Beispiele aus der zweiten Kategorie, wie Redis, Terraform und AWS.
Anders als bei IDEs wird es problematisch, wenn sich individuelle Entscheidungen bei Datenbanken, Infrastrukturmanagement und Cloud-Infrastruktur ausbreiten. Das Unternehmen muss dann einen heterogenen Stack pflegen, und der Anbieter kann nicht allein deshalb einen sinnvollen Enterprise-Vertrag abschließen, weil irgendein Team Redis gewählt hat.
Deshalb wird ein gewisses Maß an Standardisierung nötig. An diesem Punkt werden die Auswirkungen der Wahl und der Lizenzumfang größer, sodass nicht nur Engineering-Leads, sondern auch Finance ein Mitspracherecht haben will. Und das aus gutem Grund.
Und sobald Finance dazukommt, muss man die Wahl in einer Sprache rechtfertigen, die den meisten Engineers schwerfällt.
Meine Einkaufsbefugnis funktioniert ungefähr so: Ich sage meinem Chef: „Wenn wir dieses Developer-Tool kaufen, können wir X Stunden Entwicklerzeit sparen.“
X muss dabei im Verhältnis zum Preis des Tools groß genug sein. Diese Methode funktioniert ziemlich gut, und weil ich sie oft nutze, betrachtet mein Chef sie inzwischen skeptisch.
Skepsis ist berechtigt. Den Nutzen von Tools oder Redesigns zu überschätzen, ist genauso verbreitet wie den Aufwand zu unterschätzen, und beides hängt wahrscheinlich stark zusammen.
Das heißt nicht, dass es keine wertvollen Tools gibt. Es gibt sie, aber sie sind sehr selten.
Ich frage mich, wie lange es dauert, bis der Chef sagt: „Wenn man alle Tools zusammenzählt, die du in den letzten drei Monaten vorgeschlagen hast, sollten sie ein Entwicklerjahr einsparen. Also streiche ich eine Entwicklerstelle im Team, und Aufgaben sowie Zeitplan bleiben unverändert.“
Als Antwort könnte kommen: „Entwicklerzeit ist kein KPI, und das Gehalt ist dasselbe, egal ob jemand 160, 180 oder 200 Stunden im Monat arbeitet.“
1 Kommentare
Meinungen auf Hacker News
Fast richtig, aber ich glaube, auch Vertriebs- oder Finanzleute haben kaum solche Kaufbefugnisse. Deshalb nutzen alle die vom Unternehmen erlaubten Tools oder kostenlose Tarife, und am Ende muss man es dem Chef verkaufen.
Man muss damit überzeugen, dass es Zeit spart, Projekte transparenter macht und Freiheiten reduziert.
Das dürfte auch ein wesentlicher Grund sein, warum Excel so weit verbreitet ist. Excel ist zudem das mächtigste Tool, das die Unternehmens-IT zulässt.
Das merkt man, wenn man in Vertrieb oder Finance arbeitet und versucht, die Erlaubnis zu bekommen, WSL auf dem PC zu installieren. Web-Apps sind auch deshalb beliebt, weil die Unternehmens-IT sie kennen muss, um sie blockieren zu können.
Ein Marketingmanager kann Basecamp vielleicht mit der eigenen Karte bezahlen, aber wenn er ein selbst gehostetes Tool einführen will, wird es groß, weil es durch die IT-Richtlinie muss: „Wir verwalten die Computer, und wir entscheiden auch über die Arbeitsweise.“
Es ist in jeder m365-Lizenz enthalten, und Dauerlizenzen waren lange Zeit vergleichsweise günstig.
Wenn jemand vorschlägt, dem Vertrieb WSL zu erlauben, fragt man sich, ob diese Person je mit echten Vertriebsmitarbeitern gearbeitet hat. In 99 % der Unternehmen schaffen selbst technisch versiertere Sales-Leute ohne Hilfe gerade einmal, einen E-Mail-Anhang zu verschicken; was sie mit WSL anfangen sollen, ist mir schleierhaft.
All diese Kleinkäufe zu genehmigen, ist zu viel Aufwand; prüft man sie nicht, sammeln sich überall ungenutzte Abos an, oder es werden viele Dinge gekauft, die dem Unternehmen wenig bringen.
Im Marketing hingegen schienen die Kaufbefugnisse recht groß zu sein, vermutlich weil die Arbeit selbst damit zu tun hat, alle möglichen Dinge zu kaufen.
Wenn auch nur eine Anwendung kompromittiert wird, kann die gesamte Unternehmens-IT gefährdet sein; selbst mit Segmentierung oder Zero Trust steigen Angriffsfläche und Sicherheitskosten.
Tatsächlich ist der Kauf einer selbst gehosteten Anwendung der einfache Teil; schwierig ist, sie über den geschäftlich erforderlichen Zeitraum jeden Tag stabil zu betreiben. In manchen Fällen müssen Daten auch rechtlich lange aufbewahrt werden.
Selbst wenn das Fach-IT-Team das Tool angefordert hat, kann es vielleicht einen Teil der technischen Verwaltung übernehmen, hat aber oft keine Zeit dafür oder besteht aus Entwicklern und nicht aus System- oder Netzwerkadministratoren.
Am Ende nutzt man also eine von der Unternehmens-IT getrennte Sandbox, verzichtet auf Komfortfunktionen wie Backups und AD oder baut und betreibt es als Shadow IT selbst.
Daher sehe ich einen der Gründe für das Wachstum von SaaS und Cloud darin, dass solche Kosten ausgelagert werden.
Wenn man kämpfen muss, um ein 50-Dollar-Buch zu kaufen, hat man sich wahrscheinlich die falsche Firma ausgesucht.
Allerdings haben einige Entwickler, um Notion intern zu testen, mit einer Karte inoffizielle Konten angelegt, dort wichtige Übersichts-Dokumente erstellt und dann Links herumgeschickt.
Die Hälfte der Firma, die sie ansehen wollte, legte stillschweigend Konten an, und im nächsten Monat bekam der CFO eine Rechnung über 10.000 Dollar.
Geschichten darüber, warum Entwickler keine Kaufbefugnisse bekommen sollten, beginnen meistens so.
Es gibt einen Grund, warum viele SaaS-Unternehmen Vorauszahlung oder Optionen mit fester Kostenobergrenze nicht wirklich anbieten. Das grenzt an Betrug.
Das als „Beginn der Geschichte, warum Entwickler keine Kaufbefugnisse bekommen“ zu sehen, fällt mir schwer.
Zum Beispiel sind Tools dann zersplittert, sodass man Informationen nicht mit einer einzigen Suche findet, oder jedes Team muss sich bei anderen Tools separat anmelden.
Wenn Teams Tools mit geistigem Eigentum des Unternehmens jeweils eigenständig verwalten, wird das bei angestrebter SOC-Compliance zum Albtraum.
Bücher oder Lernmaterialien zu kaufen, finde ich in Ordnung.
Aus der Perspektive von jemandem, der über Engineering-Ausgaben für Hardware, Software und Services von mehr als 100 Millionen Dollar pro Quartal entschieden hat: Wenn man Entwickler-Tools baut, muss man zuerst dafür sorgen, dass die aktuellen Entwickler sie als sehr nützlich empfinden und sich stark dafür einsetzen.
Man darf keine Vetopunkte berühren, etwa undurchsichtige Verträge, Lock-in, Datensicherheit und Datenschutz oder Integration von Single Sign-on und Authentifizierung.
Auch der Preis muss nachvollziehbar sein. Preise, die linear von irgendeiner Variable abhängen, ergeben in Finance-Tabellen wahrscheinlich keinen Sinn. Abrechnung pro Entwickler und Monat ist leicht verständlich, unternehmensweite Floating-Lizenzen sind besser, und manchmal passt eine unternehmensweite unbegrenzte Pauschale noch besser.
Auch beim letzten Modell können Verbrauchskosten wie Cloud-Compute und Storage weitergereicht werden. Wenn man direkt in das Cloud-Konto des Kunden deployen kann, löst das auch Probleme rund um Datensicherheit und Datenschutz.
Man sollte Kostenkontrollen anbieten, etwa Abrechnungsobergrenzen, Nutzungslimits, Beschränkungen für Einstellungen, die teure Nutzung auslösen, und ausreichende Nutzungsberichte.
Wenn man es gut macht, sind auch mehrjährige Verträge mit zugesagten Ausgaben möglich. Man muss die Zuverlässigkeit des Dienstes aufrechterhalten und mit Großkunden quartalsweise Reviews durchführen, um Zufriedenheit und unerfüllte Anforderungen zu verstehen.
Auch hochwertige Professional Services wie dedizierte Engineers und Support kann man anbieten und abrechnen. Das ist profitabel und kann entscheidend sein, um bestimmte Kunden zu gewinnen oder zu halten.
Innerhalb des Kundenunternehmens kann das Produkt umstritten sein, und Gegner können die Einführung scheitern lassen; wenn Professional Services die anfängliche Integration und Implementierung übernehmen, lässt sich die Einmischung der IT-Gatekeeper reduzieren und man erreicht die tatsächlichen Nutzer.
Produkte, von denen der Kunde fest glaubt, er könne sie selbst bauen, sollte man besser nicht mit aller Macht verkaufen. Selbst wenn diese Einschätzung falsch ist und man anfangs gewinnt, verliert man am Ende wahrscheinlich doch.
Die Frage ist, wann man den Return on Investment von Build vs. Buy beurteilt.
Ein Produkt mit sehr hohen Integrationskosten zu kaufen, ist faktisch dasselbe wie es zu bauen. Die Integration erfordert Entwicklerzeit, und diese Zeit hätte man für andere Arbeit oder für das Produkt selbst verwenden können.
Idealerweise zeigt sich das während einer Proof-of-Concept-Integration, aber selbst für diese Phase braucht man Entwicklerzeit.
Das hängt vom Unternehmen ab. Bei einer früheren Firma galt die Regel: „Kauft einfach, was ihr braucht, um euch die Arbeit zu erleichtern – Bücher, Lizenzen, sogar Hardware. Die Verwaltungskosten für die Entscheidung sind teurer, also ist die Voreinstellung sofortige Genehmigung.“
Haben die Entwickler daraufhin einen Kaufrausch ausgelöst? Nein, sie kauften nur etwa so viel wie vor der Regelung. Tatsächlich wurde das Leben dadurch bequemer.
Voraussetzung ist, dass man Entwicklern Adminrechte anvertraut oder die Unternehmens-IT die Installation erlauben kann.
Man kann allen ein kleines Budget geben oder es auf Team- bzw. Abteilungsebene verwalten, aber sobald eine Integration in die Unternehmens-IT nötig wird, funktioniert es nicht mehr gut.
Wenn man das 10 oder 20 Jahre laufen lässt, kann es sehr anders aussehen. Langsame, unsichtbare Kostensteigerungen sammeln sich an, und es kann eine Kultur entstehen, in der Leute, die etwas weniger ausgeben, Dinge kaufen müssen, damit andere nicht verschwenderisch wirken.
Es gibt viele subtile Mechanismen, die Kostensteigerungen begünstigen, daher braucht es Vorrichtungen, die in die Gegenrichtung wirken. Ich sehe das als ungelöstes Problem.
Möglich wäre etwa, großzügige Budgetgrenzen zu setzen, aber klar zu sagen, dass sie nicht ausgeschöpft werden sollen, und am Jahresende einen bestimmten Anteil des Restbetrags an einen allgemein akzeptierten guten Zweck zu spenden.
Etwa: „Ihr dürft das Buch kaufen. Denkt nur daran, dass wegen dieses Buchs die Pony-Spende um 5 Dollar sinkt.“ Wenn es um Seekühe ginge, bestünde bei mir die Gefahr, dass ich mit einem Chromebook arbeite.
Im besten Fall sind sie oft inkompetent, und es wäre besser, ein paar Manager zu streichen und deren Gehälter als Ermessensbudget zu verwenden. Alle würden gewinnen.
Ich muss die Bestell- und Lieferprozesse der Firma nicht kennen; das ist die beste Lösung, die ich bisher gesehen habe.
Als Angestellter hatte ich dieses Problem einmal. Ich wollte ein ThinkPad, aber die Geschäftsführung bestand auf einem miserablen Dell; am Ende bekam ich dann doch ein ThinkPad.
Ansonsten bekam ich Bücher oder Tools einfach, wenn ich sie anfragte, auch eine teure geteilte Tastatur war möglich.
Seit ich selbstständig bin, kaufe ich einfach, was ich brauche. Tatsächlich brauche ich gar nicht viel.
Es gibt nicht viele „Entwickler-Tools“, die nützlich genug sind, um Geld dafür auszugeben, und noch weniger, die wertvoll genug sind, um sie in meinen Workflow zu integrieren. Mit der Zeit ist dieser letzte Punkt immer wichtiger geworden.
Ich bekam einen miesen Dell, er ging kaputt, ich bekam wieder einen miesen Dell, er ging wieder kaputt, und dann bekam ich wieder einen Dell.
Wenn sie sagen: „Wir haben nur mit Dell einen Vertrag“, und man fragt, ob sie vielleicht von Anfang an keinen Vertrag mit Dell hätten abschließen sollen, folgt Schweigen, und erst dann fangen die Köpfe an zu arbeiten.
Man erkennt, dass die Momente, in denen der Dell kaputt ist, die besten des Lebens sind. Bis neue Ausrüstung verschickt wird, dauert es fünf Tage durch Schichten aus Bestellanforderungen und Bestellpolitik, und in diesen fünf Tagen kann man wegen der drakonischen Sicherheitsrichtlinien des Unternehmens nichts tun.
Also schläft man fünf Tage lang, meldet sich bei Freunden und wird wieder ein Mensch.
Ich liebe Dell. Ich will kein ThinkPad.
Privat nutze ich ein MacBook.
Früher habe ich bei einer vertriebsorientierten Tochterfirma eines Ingenieurunternehmens gearbeitet.
Anfangs konnte ich problemlos ein Mittagessen für 100 Dollar spendieren, aber keine 30-Dollar-Karte für meinen Computer kaufen.
Umgekehrt konnte man bei der Muttergesellschaft problemlos Testgeräte für 5.000 Dollar kaufen, musste aber drei Formulare ausfüllen, um jemanden in ein Fast-Food-Restaurant mitzunehmen.
Gegen Ende meiner Zeit konnte man auf beiden Seiten ohne dieses Formular praktisch gar nichts mehr tun.
Viele erfolgreiche Entwickler-Tool-Firmen haben ihr Geld damit verdient, nicht an Entwickler, sondern an deren Vorgesetzte zu vermarkten. Das gilt nicht nur für Technik, sondern auch für viele andere Bereiche.
Dinge außerhalb des eigenen Zuständigkeitsbereichs zu kaufen, war absurd kompliziert.
Kürzlich sagte das Unternehmen: „Ihr habt eine Firmenkreditkarte, also benutzt sie“, und Event-bezogene Kosten wurden von EVPs genehmigt. Das war nicht üblich, aber es war beeindruckend, dass sie wussten, dass man manchmal Bürokratie abschneiden muss.
Beim nächsten normalen Spesenfall werde ich wahrscheinlich mit der Buchhaltung streiten, weil auf einer Taxiquittung über 20 Dollar Start- und Zielort fehlen.
Softwarelizenzen kaufe ich selbst und setze sie von der Steuer ab. So vermeidet man Scheineinsparungen.
Weil ich passende, günstige Tools gefunden und selbst gekauft habe, habe ich bei der Arbeit Auszeichnungen bekommen, wurde in bestimmten Projekten unersetzlich, erhielt Gehaltserhöhungen und konnte mir aussuchen, woran ich arbeiten wollte.
Meine JetBrains-Lizenz ist das Paradebeispiel. Code-Refactoring ohne sie kann ich mir kaum vorstellen.
Wenn die Kostensparerei der Unternehmen aufhört, werde ich mehr Konkurrenz am Arbeitsplatz haben.
Ein früherer Arbeitgeber zahlte eine niedrige Kilometerpauschale, daher machte ich die Differenz in der Steuererklärung geltend.
Bei Software bin ich mir nicht sicher, wie die Kriterien für abzugsfähige Kosten angewendet würden.
Weil die meisten Unternehmen nicht die richtige Software für die jeweilige Arbeit kaufen, bin ich im Team die effektivste Person geworden. Anders als die anderen kann ich Dinge schnell und effizient erledigen.
Wenn es auf Azure, AWS oder Google Cloud hochgeladen werden kann, sieht die Sache anders aus.
Nicht einmal einen Bleistift kann man ohne Genehmigung kaufen, aber in der Cloud des Unternehmens kann man ohne Nachfrage Tausende Dollar ausgeben.
Diesmal wählte er jedoch einen AWS-Service, der über 1.000 Pfund im Monat kostete. Als die Kreditkartenabrechnung kam, wurde das zu einem großen Problem, und die Kosten für den nächsten Monat waren bereits erheblich angelaufen.
Danach mussten wir die Kontrolle deutlich verschärfen.
Aber wenn wir eine Unternehmenslizenz kaufen, amortisiert sie sich allein durch die Einsparungen sofort, daher fühle ich mich gedrängt, es zu versuchen, auch wenn es nicht mein eigentlicher Job ist.
terraform applyin den SAP-Genehmigungsworkflow integriert.Ein Geschäftsmodell, bei dem Engineers die Entscheider sind, ist durchaus möglich. Es ist allerdings auf Tools beschränkt, mit denen Engineers ohne direkte Auswirkungen außerhalb ihres Bereichs lokale Optimierung betreiben können.
IDEs sind das beste Beispiel. Wenn man den Engineers im Unternehmen erlaubt, individuelle IDE-Entscheidungen zur Steigerung ihrer eigenen Produktivität zu treffen, kann die globale Wirkung all dieser Entscheidungen zusammengenommen akzeptabel sein. Jetbrains zeigt das.
Aber nicht jedes Tool ist so. Der Originalbeitrag behandelt Beispiele aus der zweiten Kategorie, wie Redis, Terraform und AWS.
Anders als bei IDEs wird es problematisch, wenn sich individuelle Entscheidungen bei Datenbanken, Infrastrukturmanagement und Cloud-Infrastruktur ausbreiten. Das Unternehmen muss dann einen heterogenen Stack pflegen, und der Anbieter kann nicht allein deshalb einen sinnvollen Enterprise-Vertrag abschließen, weil irgendein Team Redis gewählt hat.
Deshalb wird ein gewisses Maß an Standardisierung nötig. An diesem Punkt werden die Auswirkungen der Wahl und der Lizenzumfang größer, sodass nicht nur Engineering-Leads, sondern auch Finance ein Mitspracherecht haben will. Und das aus gutem Grund.
Und sobald Finance dazukommt, muss man die Wahl in einer Sprache rechtfertigen, die den meisten Engineers schwerfällt.
Meine Einkaufsbefugnis funktioniert ungefähr so: Ich sage meinem Chef: „Wenn wir dieses Developer-Tool kaufen, können wir X Stunden Entwicklerzeit sparen.“
X muss dabei im Verhältnis zum Preis des Tools groß genug sein. Diese Methode funktioniert ziemlich gut, und weil ich sie oft nutze, betrachtet mein Chef sie inzwischen skeptisch.
Das heißt nicht, dass es keine wertvollen Tools gibt. Es gibt sie, aber sie sind sehr selten.