Viele Organisationen sind Umstellung auf DevOps , eine Softwarepraxis, bei der Entwickler ihren Code sowohl schreiben als auch ausführen. Dieser Übergang wird häufig durch die digitale Transformation und die Notwendigkeit, schneller zu innovieren und dabei rund um die Uhr erreichbar zu sein, vorangetrieben. Aber was hat DevOps mit Vielfalt, Inklusion und Zugehörigkeit zu tun?

Ich glaube, dass die Kernprinzipien und Praktiken von DevOps über die Praktiken der Softwareentwicklung hinausgehen und auf viele Funktionen und Praktiken einer Organisation angewendet werden können, einschließlich der Frage, wie ein vielfältiges und integratives Umfeld aufbauen und fördern . Und ich sehe dies bei PagerDuty, wo nicht nur unser Entwicklungsteam DevOps praktiziert, sondern wo die Prinzipien und Praktiken von DevOps unsere Kultur durchdringen (einer unserer Unternehmensleitlinien lautet beispielsweise „Ack and Own“).

In diesem Blog spreche ich über vier wichtige DevOps-Prinzipien oder -Praktiken und wie sie zum Aufbau einer vielfältigen und integrativen Arbeitsplatzkultur angewendet werden können.

1. In Automatisierung, Prozesse und Werkzeuge investieren

Das erste Prinzip besteht darin, in Tools und Prozesse zu investieren, die die Arbeit automatisieren. Automatisierung bedeutet hier alles, was sich wiederholende oder einfache Arbeiten reduziert, Reibungsverluste verringert und es den Mitarbeitern ermöglicht, sich auf die wertvolle Arbeit zu konzentrieren, die wichtig ist.

In der DevOps-Welt ist die CI/CD-Pipeline ein hervorragendes Beispiel für Automatisierung bei der Softwareentwicklung. Diese Pipeline ermöglicht es Entwicklern, Code zu erstellen und bereitzustellen. Dies ist eine Voraussetzung für das „Build it / Own it“-Modell – Sie können niemandem das Gefühl geben, Eigentümer seines Codes zu sein, wenn er keinen Zugriff oder keine Tools hat, um sowohl neue wertvolle Funktionen hinzuzufügen als auch Dinge zu reparieren, wenn sie nicht funktionieren.

Dasselbe Konzept kann auch auf die Einstellung einer vielfältigen Belegschaft und eine andere Art von Pipeline angewendet werden: die Rekrutierungspipeline. Unternehmen haben viele Personalmanager, und alle diese Manager möchten ein vielfältiges Team haben. Und warum auch nicht? Jeder Manager möchte das bestmögliche Team haben, und Studien haben gezeigt, dass Vielfältig aufgestellte Teams erbringen bessere Leistungen .

PagerDuty ermutigt seine Personalmanager, proaktiv an der Entwicklung ihrer Netzwerke zu arbeiten, um Menschen aus unterrepräsentierten Gruppen einzubeziehen. Wir sind uns jedoch auch bewusst, dass es zusätzliche Anstrengungen erfordern kann, einen vielfältigen Bewerberpool sicherzustellen. Daher haben wir in Tools und Prozesse investiert, die den Aufbau einer vielfältigen Bewerberpipeline automatisieren:

• Wir lassen alle unsere Stellenbeschreibungen durch Textio laufen, um sicherzustellen, dass sie nicht von Natur aus voreingenommen sind.
• Wir verlangen von unseren internen und externen Personalvermittlern, dass sie einen vielfältigen Bewerberpool bereitstellen. Wir arbeiten nicht mit externen Personalvermittlern zusammen, die sich nicht dazu verpflichten.
• Wir arbeiten mit zahlreichen Organisationen zusammen, darunter Code2040 , Hackbright-Akademie , HITEC, Weg nach vorne , Und Brückenschule um Kandidaten für Bereiche wie Engineering und Produkt zu finden, in denen es in vielen Märkten traditionell schwieriger ist, Bewerber mit vielfältigem Spektrum zu finden.

Ein großartiges Ergebnis dieser Praktiken ist, dass über 50 Prozent der Teilnehmer unserer 2018 Ingenieur- und Produktpraktikumsprogramm identifiziert als Frauen und/oder People of Color. Diese Praktikanten machen den Großteil unserer Neueinstellungen aus.

2. Ziele und Maßnahmen

Das zweite Prinzip besteht darin, Ziele zu haben und Ihren Fortschritt zu messen, während Sie auf deren Erreichung hinarbeiten. In der Welt von DevOps verlangen Unternehmen von ihren Ingenieuren, dass sie Software entwickeln und betreiben. Das bedeutet, dass sie auf Abruf bereitstehen müssen (wahrscheinlich eine Woche von sechs oder sieben) und während dieser Woche jederzeit bereit sein müssen, in ihrem Leben unterbrochen zu werden. Aufgrund dieser Praxis ist die Messung der Zeit, die das Team für „Unterbrechen“ der Arbeit ist wichtig. Wenn es zu viel von diese Art von Arbeit , Ingenieure verlieren ihre Freizeit oder schlafen weniger, die Arbeitsmoral ist schlecht, die Fluktuation ist hoch und ihre Innovationsfähigkeit ist eingeschränkt.

Eine bewährte Methode zur effektiven Verwaltung unterbrochener Arbeit besteht darin, betriebliche Belastungsziele festzulegen und regelmäßig darüber zu berichten. Bei PagerDuty teilen wir bei jeder Sprintüberprüfung die Bereitschaftsbelastung des Teams mit und besprechen, wie sie sich im Laufe der Zeit entwickelt. Wir halten Bereitschaftsübergabemeetings für Teams ab, um diese Probleme zu vertiefen und zu verstehen, wo Investitionen zur Reduzierung der Belastung erforderlich sind. Und wir entwickeln Produkte, die unseren Kunden helfen, Unterbrechungen zu verwalten und Einblick in die Gesundheit des Teams zu haben.

Dasselbe Konzept gilt für Ihre Inklusions-, Diversitäts- und Zugehörigkeitsziele – Ihre Ziele müssen leicht messbar und sichtbar sein. Bei PagerDuty setzen wir Diversitätsziele und messen sie im Rahmen unseres vierteljährlichen Geschäftsüberprüfungsprozesses, genau wie wir Verkäufe oder Produktlieferungen messen.

Ein Beispiel: Bevor ich bei PagerDuty anfing, waren alle Führungskräfte im Produktteam Männer und es gab nur wenige Frauen im Team. Wir haben uns konzertiert bemüht, die Vielfalt des Teams allgemein zu verbessern, wobei einer der Schwerpunkte darin bestand, mehr Frauen ins Team zu holen. Jedes Jahr haben wir ein konkretes Ziel für den Frauenanteil gesetzt, es gemessen, den Fortschritt vierteljährlich überprüft und es erreicht. Solche Veränderungen brauchen Zeit und unsere Zahlen sind noch nicht da, wo wir sein wollen – aber da wir weiterhin die Vorteile der Programme nutzen, die eingeführt wurden, um einen vielfältigen Kandidatenpool zu bilden, stellen wir in Verhältnissen ein, die die Bevölkerung besser widerspiegeln, und verbessern kontinuierlich unsere allgemeine Vielfalt.

3. Kontinuierliches Lernen und Verbesserung

Damit komme ich zum dritten DevOps-Prinzip: kontinuierliches Lernen und Verbesserung. Im Leben wie auch bei DevOps werden Sie einige Dinge falsch machen. Aber was wichtig ist, ist, wie Sie auf Fehler reagieren und eine Kultur des kontinuierlichen Lernens fördern. Mein Lieblingsbeispiel für die Umsetzung in der Welt der Softwareentwicklung ist schuldlose Obduktionen , die bei jedem größeren Vorfall durchgeführt werden sollte.

Eine Post-Mortem-Analyse ohne Schuldzuweisungen enthält einige Elemente, die entscheidend dazu beitragen, dass das Unternehmen daraus lernt und sich verbessert:

• Sie sollten, nun ja, schuldlos sein. Dies bedeutet, dass die Ursache eines Vorfalls niemals eine Person sein sollte. Wenn jemand eine Aktion ausgeführt hat, die zu einem Vorfall geführt hat, welche Kontrollen oder Schutzmaßnahmen fehlten, die diese Aktion ermöglichten? Wenn sichergestellt wird, dass niemals einer Einzelperson die Schuld gegeben wird, wird sichergestellt, dass die Leute bei ihrer Einschätzung der Situation offen und ehrlich sind.
• Das Team sollte Vorfälle als Lerngelegenheiten betrachten. Mithilfe von Postmortem-Analysen können Sie 1) Ihren Reaktionsprozess auswerten, um zu sehen, ob das Team während der Reaktion etwas hätte besser machen können, und 2) verhindern, dass sich ein ähnlicher Vorfall in Zukunft wiederholt.
• Die Erkenntnisse sollten nicht nur innerhalb des Teams, sondern im gesamten Unternehmen und im Idealfall auch mit Ihren Kunden geteilt werden. Nicht jeder praktiziert dies, aber wenn Sie es tun, können Ihre Kunden erkennen, dass Sie jede Störung ernst nehmen und dass Sie Maßnahmen ergriffen haben, um sicherzustellen, dass das gleiche Problem nicht erneut auftritt. Ein Fehler kann jedem passieren, aber es gibt keine Entschuldigung für wiederholte Vorfälle.

Die Postmortem-Analyse ohne Schuldzuweisung kann genutzt werden, um auch außerhalb größerer Vorfälle zu lernen. Wie Sie wissen, sind Vielfalt und Inklusion keine einfachen Themen. Ähnlich wie bei DevOps ist es wichtig, im Voraus zu wissen, dass Sie Fehler machen werden.

Ein Beispiel für einen Fehler passierte bei einer Firmenversammlung von PagerDuty . Wir kommunizierten Details zu unserer bevorstehenden Jahreskonferenz, dem PagerDuty Summit. Wir hatten fünf Hauptredner, von denen zwei Frauen waren. Eine war unsere CEO, Jennifer Tejada, und die zweite hatte ihre Teilnahme noch nicht bestätigt. Jemand erstellte eine Folie und ließ dabei unsere CEO (da jeder in unserem Unternehmen wusste, wer sie war) und die zweite Rednerin, die ihre Teilnahme noch nicht bestätigt hatte, aus. Was also auftauchte, waren drei weiße männliche Hauptredner. Wie Sie sich vorstellen können, kam das nicht besonders gut an.

Es wurden einige gezielte Fragen gestellt, wie etwa: „Wie kann ein Unternehmen, das so viel Wert auf eine vielfältige Mitarbeiterbasis legt, keine vielfältigen Hauptredner haben?“ Gleichzeitig war das Team, das Überstunden gemacht hatte, um ein vielfältiges Rednerprogramm zusammenzustellen (nicht nur für die Hauptredner, sondern um sicherzustellen, dass wir in allen Bereichen Vielfalt hatten), verärgert über den Vorwurf, es würde nicht den richtigen Fokus auf Vielfalt legen.

Was haben wir gelernt?

Wir haben gelernt, dass sich Mitarbeiter, denen dies wichtig ist, bei der Fokussierung und dem Aufbau eines Programms rund um Diversität und Inklusion selbst für die Teilnahme an PagerDuty entschieden haben und zu Recht Verbesserungen forderten, wenn ihnen etwas nicht passte. Wir haben gelernt, dass die Optik wichtig ist und dass man ihr auf allen Ebenen Beachtung schenken muss. Und wir haben gelernt, dass Annahmen über Absichten keine gute Idee sind (z. B. dass den Organisatoren die Vielfalt auf unserer Konferenz egal ist oder dass jeder weiß, dass die Organisatoren hart daran arbeiten, ein vielfältiges Rednerpanel zusammenzustellen) – und dass man den Beweggründen gegenüber aufgeschlossen bleiben und dennoch hinterfragen sollte, was falsch erscheint. All dies wurde natürlich im Rahmen des Post-Mortem-Prozesses besprochen und dokumentiert!

4. Individuelle Ermächtigung

Damit komme ich zum letzten DevOps-Grundprinzip, das mir wahrscheinlich am besten gefällt: die Ermächtigung des Einzelnen. Traditionelle Organisationen arbeiten nach dem Prinzip „Befehl und Kontrolle“, wobei die Entscheidungen an der Spitze getroffen und nach unten weitergegeben werden. In der Entwicklungswelt würde das beispielsweise bedeuten, dass Code-Releases die Genehmigung des Vizepräsidenten erfordern würden, was eine kontinuierliche Bereitstellung schwierig, wenn nicht gar unmöglich macht.

DevOps-Prinzipien gehen zu Recht davon aus, dass die Leute, die am nächsten am Code sind, auch am besten darüber Bescheid wissen. Und wenn Sie ihnen die Möglichkeit geben, anstatt sie zu behindern, können sie schneller Innovationen hervorbringen und Probleme beheben. Denn wenn es ein Problem gibt, können die Leute, die mit dem Code zu tun haben, bessere Entscheidungen treffen als jede Führungskraft, unabhängig davon, wie fähig diese Führungskraft ist. Dies spiegelt sich in bewährten Incident-Response-Prozessen wider, bei denen die Beteiligten während eines Vorfalls proaktiv auf dem Laufenden gehalten werden, aber davon abgehalten werden, eine laufende Incident-Response zu stören.

Wie verhält sich also die individuelle Ermächtigung zu Vielfalt, Inklusion und Zugehörigkeit? Das Unternehmen kann Programme einführen, aber es reicht nicht aus, diese nur von oben voranzutreiben, um Veränderungen herbeizuführen. Bisher habe ich hauptsächlich über Vielfalt gesprochen, aber wenn es um Inklusion und Zugehörigkeit geht, sind die Mitarbeiter der Schlüssel – nur jeder Einzelne kann sagen, ob er sich wirklich einbezogen fühlt.

Um die Inklusion bei PagerDuty zu fördern, haben wir eine Reihe von von Mitarbeitern geleiteten Programmen, darunter Mitarbeiterressourcengruppen (ERGs) . ERGs veranstalten Treffen und planen Veranstaltungen, um unterrepräsentierte Bevölkerungsgruppen in der Arbeitswelt und der Gesellschaft zu unterstützen. PagerDuty sponsert die ERGs, aber diese Interessengruppen werden von Mitarbeitern für Mitarbeiter geleitet.

Wir haben auch eine Gruppe „Frauen im Vertrieb“, eine weitere traditionell von Männern dominierte Funktion. Diese Mitarbeitergruppe hat Gastgeber einer Reihe von Podiumsdiskussionen mit Frauen auf allen Vertriebsebenen, um über ihre Erfahrungen zu sprechen und Ratschläge auszutauschen und so als großartige Vorbilder für Frauen zu dienen, die am Anfang ihrer Vertriebskarriere stehen.

Darüber hinaus haben wir vor etwa anderthalb Jahren einige neue Unternehmenswerte eingeführt. Dabei handelte es sich um Top-down-Initiativen, die bei den Mitarbeitern einfach nicht gut ankamen. Also gingen wir noch einmal zurück ans Reißbrett und führten eine Reihe von Fokusgruppen mit Mitarbeitern durch, um ihre Einsichten in die wichtigsten Aspekte zu erfahren. Als Ergebnis führten wir neue Unternehmenswerte ein, die die Mitarbeiter wirklich ansprechen (und die meiner Meinung nach sehr „PagerDuty“ sind). Alex Solomon, unser Mitbegründer und CTO, schreibt darüber Hier .

DevOps in ID&B integrieren

In der Branche ist allgemein bekannt, dass die Umstellung auf DevOps ein schwieriger Prozess ist. Und Sie müssen Ihre Prozesse, Werkzeuge, Kultur und Organisation so aufeinander abstimmen, dass alles zusammenarbeitet. Denken Sie daran, dass es nicht darum geht, Ihren Prozess abzuschließen. Es wird immer Fehler geben. Wir werden immer neuere Technologien entwickeln und bessere Prozesse einführen müssen. Der Schlüssel zum Erfolg liegt darin, mit jeder Iteration und jedem Versuch Fortschritte zu machen und, wenn dies nicht gelingt, aus Ihren Fehlern zu lernen.

Das ist auch bei der Förderung einer Kultur der Vielfalt, Inklusion und Zugehörigkeit nicht anders. Und die folgenden DevOps-Kernprinzipien können dabei hilfreich sein.

• Veränderungen müssen sowohl von oben als auch von unten kommen.
• Investieren Sie in Automatisierung und Werkzeuge, um es einfacher zu machen – die meisten Menschen möchten inklusiv sein und werden eine vielfältige Organisation aufbauen, wenn Sie es ihnen ermöglichen.
• Bewerten Sie kontinuierlich und ohne Schuldgefühle, wie Sie sich schlagen.
• Und schließlich: Messen Sie Ihren Erfolg oder Misserfolg auf dem Weg. Dabei sollten Sie sich immer im Klaren darüber sein, dass der einzige wahre Misserfolg der ist, aus dem Sie nicht lernen und keine Schritte zur Verbesserung unternehmen – dies ist eine Reise.