Viele Organisationen sind Übergang zu DevOps , eine Softwarepraxis, bei der Entwickler ihren Code sowohl schreiben als auch bedienen. Dieser Übergang wird oft durch die digitale Transformation und die Notwendigkeit schnellerer Innovationen bei gleichzeitiger ständiger Erreichbarkeit rund um die Uhr vorangetrieben. Doch 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 man ein vielfältiges und integratives Umfeld aufbauen und fördern Und das sehe ich bei PagerDuty, wo nicht nur unser Entwicklungsteam DevOps praktiziert, sondern wo die Prinzipien und Praktiken von DevOps auch 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. Investitionen in Automatisierung, Prozesse und Werkzeuge

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

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 funktionierende „Build it / Own it“-Modell. Man kann niemandem das Gefühl geben, Eigentümer seines Codes zu sein, wenn er nicht über den Zugriff oder die Tools verfügt, um sowohl neue wertvolle Funktionen hinzuzufügen als auch Probleme zu beheben.

Dasselbe Konzept lässt sich auch auf die Einstellung einer vielfältigen Belegschaft und eine andere Art von Pipeline anwenden: die Recruiting-Pipeline. Unternehmen haben viele Personalverantwortliche, und alle diese Manager wünschen sich ein vielfältiges Team. Und warum auch nicht? Jeder Manager möchte das bestmögliche Team haben, und Studien haben gezeigt, dass Vielfältige Teams erzielen bessere Leistungen .

PagerDuty ermutigt seine Personalverantwortlichen, proaktiv ihre Netzwerke auszubauen und Menschen aus unterrepräsentierten Gruppen einzubeziehen. Wir sind uns jedoch auch bewusst, dass die Sicherstellung eines vielfältigen Bewerberpools zusätzlichen Aufwand erfordert. Daher haben wir in Tools und Prozesse investiert, die den Aufbau einer vielfältigen Bewerberpipeline automatisieren:

• Wir lassen alle unsere Stellenbeschreibungen über Textio laufen, um sicherzustellen, dass sie keine inhärente Voreingenommenheit enthalten.
• Wir fordern von unseren internen und externen Personalvermittlern, einen vielfältigen Kandidatenpool bereitzustellen. Wir arbeiten nicht mit externen Personalvermittlern zusammen, die sich nicht dazu verpflichten.
• Wir arbeiten mit zahlreichen Organisationen zusammen, wie zum Beispiel Code2040 , Hackbright-Akademie , HITEC, Weg nach vorn , 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 unterschiedlichem Hintergrund 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 Bewerber für Einstiegspositionen aus.

2. Ziele und Maßnahmen

Das zweite Prinzip besteht darin, Ziele zu haben und den Fortschritt zu messen, während man auf deren Erreichung hinarbeitet. In der DevOps-Welt verlangen Unternehmen von ihren Ingenieuren, Software sowohl zu entwickeln als auch zu betreiben. Das bedeutet, dass sie Bereitschaftsdienst leisten müssen (wahrscheinlich eine Woche pro sechs oder sieben) und während dieser Woche jederzeit bereit sein müssen, in ihrem Leben unterbrochen zu werden. Aufgrund dieser Praxis misst die Messung der Zeit, die das Team für „Unterbrechen“ der Arbeit ist wichtig. Wenn es zu viel von diese Art von Arbeit , Ingenieure werden unter Verlust von Freizeit oder Schlaf, niedriger Arbeitsmoral, hoher Fluktuation und verminderter Innovationsfähigkeit leiden.

Eine bewährte Methode zur effektiven Verwaltung unterbrochener Arbeit besteht darin, betriebliche Auslastungsziele festzulegen und diese regelmäßig zu melden. Bei PagerDuty teilen wir bei jedem Sprint-Review die Bereitschaftsauslastung des Teams mit und besprechen deren Entwicklung im Zeitverlauf. Wir halten Bereitschaftsübergabemeetings ab, damit die Teams diese Probleme vertiefen und herausfinden können, wo Investitionen zur Auslastungsreduzierung erforderlich sind. Und wir entwickeln Produkte, die unseren Kunden helfen, Unterbrechungen zu bewältigen und Einblick in die Teamgesundheit zu erhalten.

Dasselbe Konzept gilt für Ihre Ziele in Bezug auf Inklusion, Vielfalt und Zugehörigkeit – Ihre Ziele müssen leicht messbar und sichtbar sein. Bei PagerDuty setzen wir Diversitätsziele und messen diese im Rahmen unseres vierteljährlichen Geschäftsprüfungsprozesses, genau wie wir Umsätze 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 gezielt darum bemüht, die Diversität im Team insgesamt zu verbessern. Einer unserer Schwerpunkte war die Erhöhung des Frauenanteils. Jedes Jahr setzen wir uns ein konkretes Ziel für den Frauenanteil, messen dieses, überprüfen die Fortschritte vierteljährlich und erreichen es. Solche Veränderungen brauchen Zeit, und unsere Zahlen entsprechen noch nicht unserem Ziel. Da wir jedoch weiterhin Programme zur Förderung eines vielfältigen Kandidatenpools nutzen, stellen wir in einem Verhältnis ein, das die Bevölkerung besser widerspiegelt, und verbessern kontinuierlich unsere allgemeine Diversität.

3. Kontinuierliches Lernen und Verbesserung

Das bringt mich zum dritten DevOps-Prinzip: kontinuierliches Lernen und Verbesserung. Im Alltag wie auch bei DevOps werden Sie Fehler machen. Wichtig ist jedoch, wie Sie auf Fehler reagieren und eine Kultur des kontinuierlichen Lernens fördern. Mein Lieblingsbeispiel für die Umsetzung in der Softwareentwicklung ist schuldlose Obduktionen , die bei jedem größeren Vorfall durchgeführt werden sollte.

Es gibt einige Elemente in einer Post-Mortem-Analyse ohne Schuldzuweisungen, die entscheidend dafür sind, dass das Unternehmen lernt und sich verbessert:

• Sie sollten, nun ja, schuldlos sein. Das bedeutet, dass die Ursache eines Vorfalls niemals eine Person sein sollte. Wenn jemand eine Handlung vorgenommen hat, die zu einem Vorfall geführt hat, welche Kontrollen oder Leitplanken fehlten, die diese Handlung ermöglichten? Wenn sichergestellt wird, dass niemals eine Einzelperson beschuldigt wird, wird sichergestellt, dass die Mitarbeiter die Situation offen und ehrlich einschätzen.
• Das Team sollte Vorfälle als Lernmöglichkeiten betrachten. Mithilfe von Postmortem-Analysen können Sie 1) Ihren Reaktionsprozess auswerten, um festzustellen, ob das Team bei 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 idealerweise auch mit Ihren Kunden geteilt werden. Nicht jeder praktiziert dies, aber wenn Sie es tun, zeigen Sie Ihren Kunden, dass Sie jede Störung ernst nehmen und Maßnahmen ergriffen haben, um sicherzustellen, dass das gleiche Problem nicht noch einmal auftritt. Ein Fehler kann jedem passieren, aber es gibt keine Entschuldigung für wiederholte Vorfälle.

Die schuldlose Postmortem-Analyse 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 Mitarbeiterversammlung der PagerDuty Company. Wir kommunizierten Details zu unserer bevorstehenden Jahreskonferenz, dem PagerDuty Summit. Wir hatten fünf Hauptrednerinnen, darunter zwei Frauen. Eine davon war unsere CEO, Jennifer Tejada, und die zweite hatte ihre Teilnahme noch nicht zugesagt. Jemand erstellte eine Folie, auf der unsere CEO (da jeder in unserem Unternehmen wusste, wer sie war) und die zweite Rednerin, die ihre Teilnahme noch nicht zugesagt hatte, nicht erwähnt wurden. Stattdessen erschienen drei weiße 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 Rednerteam zusammenzustellen (nicht nur für die Hauptreden, sondern um sicherzustellen, dass wir in allen Bereichen Vielfalt hatten), verärgert über den Vorwurf, dass sie nicht den richtigen Fokus auf Vielfalt legten.

Was haben wir gelernt?

Wir haben gelernt, dass sich Mitarbeiter, denen Diversität und Inklusion am Herzen liegen, bei der Fokussierung und dem Aufbau eines Programms auf Diversität und Inklusion selbst für PagerDuty entschieden haben und bei Unstimmigkeiten zu Recht Verbesserungen forderten. Wir haben gelernt, dass die Optik wichtig ist und dass man ihr auf allen Ebenen Beachtung schenken muss. Und wir haben gelernt, dass es keine gute Idee ist, Absichten zu unterstellen (z. B. dass den Organisatoren Diversität auf unserer Konferenz egal ist oder dass jeder weiß, dass die Organisatoren hart daran arbeiten, ein vielfältiges Rednerpanel zusammenzustellen) – und dass man den Motivationen gegenüber unvoreingenommen bleiben und gleichzeitig hinterfragen sollte, was falsch erscheint. All dies wurde natürlich im Rahmen der Nachbesprechung besprochen und dokumentiert!

4. Individuelle Ermächtigung

Dies bringt mich zum letzten zentralen DevOps-Prinzip, das wahrscheinlich mein Lieblingsprinzip ist: die Ermächtigung des Einzelnen. Traditionelle Organisationen arbeiten nach dem Prinzip der Befehls- und Kontrollgewalt, bei dem die Entscheidungen an der Spitze getroffen und nach unten weitergegeben werden. In der Entwicklungswelt würde dies beispielsweise bedeuten, dass Code-Releases die Genehmigung des Vizepräsidenten erfordern, was eine kontinuierliche Bereitstellung schwierig, wenn nicht gar unmöglich macht.

DevOps-Prinzipien gehen zu Recht davon aus, dass die Personen, die am nächsten am Code arbeiten, auch das beste Wissen darüber haben. Und wenn man sie unterstützt, anstatt sie zu behindern, können sie schneller Innovationen entwickeln und Probleme beheben. Denn bei Problemen können die Personen, die mit dem Code arbeiten, bessere Entscheidungen treffen als jede Führungskraft, unabhängig von deren Kompetenz. Dies spiegelt sich in bewährten Incident-Response-Prozessen wider: Die Beteiligten werden während eines Vorfalls proaktiv auf dem Laufenden gehalten, aber davon abgehalten, eine laufende Incident-Response zu stören.

Wie hängt also individuelle Ermächtigung mit Vielfalt, Inklusion und Zugehörigkeit zusammen? Das Unternehmen kann Programme einführen, aber die alleinige Steuerung von Programmen von oben reicht nicht aus, um Veränderungen zu fördern. 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 männerdominierte Funktion. Diese Mitarbeitergruppe hat Gastgeber einer Reihe von Panels mit Frauen auf allen Vertriebsebenen, um über ihre Erfahrungen zu sprechen und Ratschläge auszutauschen. Sie dienen Frauen am Anfang ihrer Vertriebskarriere als großartige Vorbilder.

Darüber hinaus haben wir vor etwa anderthalb Jahren neue Unternehmenswerte eingeführt. Diese waren Top-down-Initiativen und fanden bei den Mitarbeitern einfach keinen Anklang. Deshalb haben wir uns neu aufgesetzt und mehrere Mitarbeiter-Fokusgruppen durchgeführt, um ihre Erkenntnisse zu den wichtigsten Aspekten zu sammeln. Das Ergebnis sind neue Unternehmenswerte, die die Mitarbeiter wirklich ansprechen (und die meiner Meinung nach sehr „PagerDuty“ sind). Alex Solomon, unser Mitgrü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. Es erfordert die Abstimmung von Prozessen, Tools, Kultur und Organisation, damit alles zusammenarbeitet. Denken Sie daran: Es geht nicht darum, den Prozess abzuschließen. Fehler werden immer passieren. Wir werden immer neue Technologien entwickeln und bessere Prozesse implementieren müssen. Der Schlüssel zum Erfolg liegt darin, mit jeder Iteration und jedem Versuch Fortschritte zu machen und, wenn dies nicht gelingt, aus den Fehlern zu lernen.

Die Förderung einer Kultur der Vielfalt, Inklusion und Zugehörigkeit ist nicht anders, und die Orientierung an den folgenden DevOps-Grundprinzipien wird dabei hilfreich sein.

• Der Wandel muss 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 Schuldzuweisungen, wie Sie sich schlagen.
• Und schließlich sollten Sie Ihren Erfolg oder Misserfolg auf dem Weg dorthin mit der Einstellung messen, dass der einzige wahre Misserfolg der ist, aus dem Sie nicht lernen und keine Schritte zur Verbesserung unternehmen – dies ist eine Reise.