Ο Διευθύνων Σύμβουλος της PlanetScale στο Cloud-Prem and Climbing the Engineering Ladder

Ο Sam Lambert είναι Διευθύνων Σύμβουλος της PlanetScale, ένας πάροχος βάσεων δεδομένων χωρίς διακομιστή συμβατή με MySQL. Πριν ενταχθεί στην PlanetScale (τότε ως Chief Product Officer), ήταν Αντιπρόεδρος Μηχανικής στο GitHub.

Σε αυτή τη συνέντευξη, ο Lambert συζητά μια σειρά θεμάτων που σχετίζονται με μοντέλα παράδοσης εγγενούς λογισμικού στο cloud, συμπεριλαμβανομένου του πώς είναι καλό χωρίς διακομιστή, ποιος πρέπει να τρέχει το Kubernetes και την εμφάνιση του "cloud-prem" — ενός μοντέλου ανάπτυξης που συνδυάζει τα δυνατά σημεία του on - Prem λογισμικό και προσφορές SaaS. Μοιράζεται επίσης την εμπειρία του ως μη ιδρυτής Διευθύνων Σύμβουλος και τις συμβουλές του για το πότε και πώς να κάνει τη μετάβαση από τη μηχανική στη διαχείριση.

---

ΜΕΛΛΟΝ: Περιγράψατε τι κάνει το PlanetScale —τουλάχιστον που δεν προσφέρει καθαρά SaaS—υπολογιστικό «cloud-prem». Πώς ορίζετε αυτόν τον όρο;

ΣΑΜ ΛΑΜΠΕΡΤ: Cloud-prem είναι ένα νέο μοντέλο — η εγγενής λύση cloud για on-prem, βασικά. Παραδοσιακά, οι εταιρείες έπρεπε είτε να έχουν ένα κατά την πρεμιέρα λύση ή α σύννεφο παραδοσιακά πολύ δύσκολη λύση. Στο GitHub, είχαμε αυτή την ένταση να τρέχουμε το github.com και επίσης να πουλάμε το GitHub Enterprise ως λύση on-prem. Με το προϊόν cloud, έπρεπε να είμαστε σε θέση να πιέζουμε και να παραδίδουμε συνεχώς. Το να κόψουμε μια έκδοση με βάση αυτό ήταν ένα πραγματικά δύσκολο έργο και η δημιουργία αρχιτεκτονικών και για τους δύο σήμαινε ότι δεν παρέχαμε την on-prem λύση όπως θα μπορούσαμε να κάνουμε. ήταν απλώς πολύ επίπονο να γίνει. 

Όταν ήρθαμε στο PlanetScale, αποφασίσαμε ότι θέλαμε να είμαστε μόνο στο cloud, αλλά, φυσικά, δεν μπορείτε να το κάνετε μόνο με ένα προϊόν βάσης δεδομένων ή ένα προϊόν που έχει αυστηρές απαιτήσεις συμμόρφωσης. Έτσι, με το cloud-prem, ουσιαστικά αναπτύσσουμε το επίπεδο δεδομένων του προϊόντος μας σε ένα VPC που διαχειρίζεται ο χρήστης, όπου χρησιμοποιούν το επίπεδο ελέγχου μας για να το ενορχηστρώσουν και εμείς το διαχειριζόμαστε. Αυτό ουσιαστικά φαίνεται σαν να χρησιμοποιείτε απλώς ένα κανονικό προϊόν SaaS που βασίζεται σε σύννεφο, αλλά τα δεδομένα βρίσκονται στον λογαριασμό σας. Η ομάδα ασφαλείας σας μπορεί να το ελέγξει και αισθάνεται την ασφάλεια και την εμπιστοσύνη να το έχει εντός των ορίων της υποδομής της, χωρίς τα μειονεκτήματα του να χρειάζεται να επιδιορθώσουν, να απελευθερώσουν και να διαχειριστούν οι ίδιοι το λογισμικό on-prem.

Υπάρχει ένα άλλο πρόσθετο πλεονέκτημα, το οποίο είναι, για παράδειγμα, εάν είστε μεγάλος πελάτης με εξαιρετική τιμή διαπραγμάτευσης με την Amazon, μπορείτε να πληρώσετε αυτήν την τιμή και να διατηρήσετε τις δεσμευμένες δαπάνες σας με την Amazon στον λογαριασμό σας.

Τι είδους απώθηση λαμβάνετε; Υπάρχουν μερικά σκληρά SaaS και μαγαζιά on-prem εκεί έξω…

Μπορούμε να σας προσφέρουμε καθαρό SaaS, όπου φιλοξενούμε τα δεδομένα στο λογαριασμό μας και οι άνθρωποι είναι απολύτως εντάξει με αυτό. Η πραγματική απώθηση είναι αν οι άνθρωποι θέλουν απλώς on-prem. Αλλά το μοντέλο cloud-prem αρχίζει πραγματικά να έχει απήχηση. Έχουμε ελεγχόμενες εταιρείες που χρησιμοποιούν το προϊόν επειδή βλέπουν το διπλό όφελος από τη διατήρηση των δεδομένων σε τοπικό επίπεδο, ώστε η ασφάλεια ή η συμμόρφωση να είναι ικανοποιητική, αλλά και να μην χρειάζεται να τα διαχειρίζονται. 

Αυτός είναι ο λόγος για τον οποίο αυτό το μοντέλο είναι τόσο μοναδικά φοβερό και μια πραγματική στιγμή στο χρόνο: Επειδή ξεπερνά το πρόβλημα ότι οι εταιρείες δεν θέλουν να κάνουν on-prem — και είναι ένα παλιό, νεκρό μοντέλο, βασικά — αλλά εξακολουθεί να πληροί κυρίως τις απαιτήσεις ότι on-prem θα.

Αλλά, ναι, συναντάς ακόμα αντίσταση μερικές φορές. Υπάρχουν ορισμένες εταιρείες που απλώς δεν εμπιστεύονται το λογισμικό SaaS, αλλά το cloud το καταργεί γρήγορα. Όπως, δεν μπορείτε να αποφασίσετε πότε ή πώς η Amazon ενημερώνει το S3 και κάνει το S3 καλύτερο, απλώς συμβαίνει. Έχει να κάνει με την οικοδόμηση εμπιστοσύνης με πολλούς πελάτες ότι είστε η καλύτερη εταιρεία για να διαχειριστείτε μια συγκεκριμένη δουλειά για αυτούς και να τους βοηθήσετε να νιώσουν πιο άνετα με αυτό. 

Δεν μπορείτε να δημιουργήσετε την καλύτερη εμπειρία προγραμματιστή όταν αποστέλλετε λογισμικό on-prem. Δεν μπορείς να βελτιώνεσαι συνεχώς. Δεν μπορείτε να διαχειριστείτε την ποιότητα, τη διαθεσιμότητα, τον χρόνο λειτουργίας — όλα αυτά είναι μέρος της εμπειρίας.

Οι προγραμματιστές μπορεί να έχουν αρκετά γνώμη σχετικά με τις βάσεις δεδομένων που χρησιμοποιούν. Πώς μιλάει το μοντέλο ανάπτυξης cloud-prem στην εμπειρία προγραμματιστή;

Είναι περισσότερο σαν το μοντέλο ανάπτυξης να αφαιρεί τους αποκλειστές. Δεν μπορείτε να δημιουργήσετε την καλύτερη εμπειρία προγραμματιστή όταν αποστέλλετε λογισμικό on-prem. Δεν μπορείς να βελτιώνεσαι συνεχώς. Δεν μπορείτε να διαχειριστείτε την ποιότητα, τη διαθεσιμότητα, τον χρόνο λειτουργίας — όλα αυτά είναι μέρος της εμπειρίας. Εάν δεν διαχειρίζεστε μόνοι σας την υπηρεσία, είναι πολύ δύσκολο να δημιουργήσετε ένα τόσο υψηλό επίπεδο εμπειρίας. 

Ένας σημαντικός αποκλεισμός μόνο για SaaS, φυσικά, είναι η ανάγκη ορισμένων χρηστών να διατηρούν τα δεδομένα υπό τον έλεγχό τους. Ένας σημαντικός αποκλεισμός για on-prem μπορεί να είναι η επεκτασιμότητα. Και έτσι το μοντέλο cloud-prem μοιάζει περισσότερο με έναν μηχανισμό για να απαλλαγούμε από αυτούς τους αποκλειστές και να δώσουμε σε όλους το καλύτερο και των δύο κόσμων.

Ποιος είναι ο ρόλος του Kubernetes στο μοντέλο ανάπτυξης; Και ποιος πιστεύετε ότι θα πρέπει να είναι ο ρόλος του Kubernetes συνολικά για κάτι σαν μια ανάπτυξη cloud-prem;

Το Kubernetes μας επιτρέπει να αναπτυχθούμε σε περιβάλλοντα πελατών με πολύ τυποποιημένο τρόπο και μοιάζει με το σύμπλεγμα Kubernetes που εκτελούμε εσωτερικά. Αρχιτεκτονικά, βασιζόμαστε επίσης στο Vitess, το οποίο τρέχει στο Kubernetes και αναπτύχθηκε στο Borg, τον προκάτοχο του Kubernetes στην Google. Έτσι, εγγενώς, είναι πολύ αυτοθεραπευτικό. Εάν χάσετε λοβούς ή χάσετε την υποδομή, αυτό θεραπεύεται λίγο πολύ. Τα failovers δεν είναι κάτι που πρέπει να εξετάσετε χειροκίνητα.

Στο μοντέλο μας, οι χρήστες δεν χρειάζεται να εκτελούν τα συμπλέγματα Kubernetes που αναπτύσσουμε. Δεν εφαρμόζουμε το μοντέλο της ανάπτυξης σε ένα υπάρχον σύμπλεγμα Kubernetes, το οποίο κάνουν ορισμένοι on-prem προμηθευτές ως τρόπο προσπάθειας να το διευκολύνουν. Είμαι δύσπιστος αν είναι πιο εύκολο, ειλικρινά.

Οι περισσότεροι άνθρωποι δεν χρειάζεται να τρέχουν το Kubernetes. Είναι ένα εξαιρετικό backend για τους παρόχους υποδομών, αλλά Δεν νομίζω ότι είναι απαραίτητα ο σωστός μηχανισμός ανάπτυξης για τις περισσότερες εταιρείες. Νομίζω ότι πολλοί άνθρωποι έχουν ακολουθήσει αυτόν τον δρόμο και βρήκαν λίγη ή καθόλου αξία από το να το κάνουν.

Εάν ανεβάσατε ένα αρχείο στο Dropbox και σας ρωτούσαν, "Πόσοι διακομιστές θα θέλατε να το διατηρήσουμε ενεργό ώστε να παραμένει εξαιρετικά διαθέσιμο;" Θα λέγατε, «Δεν είναι αυτό που πληρώνω εσείς Για?"

Υπάρχει κάποιο επίπεδο κλίμακας όπου αρχίζει να βγάζει νόημα, κατά τη γνώμη σας; Ή μια συγκεκριμένη περίπτωση χρήσης, όπως η λειτουργία μιας ομάδας εσωτερικής πλατφόρμας;

Εάν κάνετε αυτό που κάνουμε, όπου θέλετε να απλοποιήσετε την υποδομή και να έχετε κάτι που είναι ευέλικτο όπως το Kubernetes, τότε είναι υπέροχο. Αλλά αυτό το επίπεδο ευελιξίας είναι τόσο ανοιχτό που αν χτίζετε, ας πούμε, μια εταιρεία ηλεκτρονικού εμπορίου που προσπαθεί να φιλοξενήσει έναν ιστότοπο, δεν χρειάζεστε το Kubernetes στο backend για να το κάνετε αυτό. 

Έχει υιοθετηθεί πολύ ευρέως και νομίζω ότι πολλοί άνθρωποι προσπαθούν να δημιουργήσουν αυτές τις εσωτερικές πλατφόρμες και βλέπουν το Kubernetes ως έναν τρόπο να έχουν απλή εσωτερική υποδομή. Απλώς δεν είναι έτσι. δεν πάει αρκετά μακριά με την εμπειρία του τελικού χρήστη. Οι άνθρωποι πρέπει να χρησιμοποιούν το σύννεφο για ποιο σκοπό είναι καλύτερο για, και αφήνοντας τα σύννεφα και τους ανθρώπους σαν εμάς να τρέχουν το Kubernetes ως ένας τρόπος απλοποίησης we κάνει. 

Αλλά σίγουρα υπάρχει ένα σημείο όπου ένας οργανισμός έχει αρκετά μεγάλο αποτύπωμα για να δικαιολογήσει την εσωτερική λειτουργία κάτι σαν το Kubernetes, σωστά; Όπως κάνατε στο GitHub;

Εάν έχετε πολλούς οικοδεσπότες για διαχείριση — και μιλάμε για χιλιάδες μηχανήματα, που δεν είναι πολλές εταιρείες — και θέλετε υποδομή που να είναι λίγο πιο αυτοθεραπεύσιμη ή να αξιοποιήσει έναν μεγάλο στόλο μηχανών, σας βοηθά να έχετε την ευελιξία να χειρίζεσαι αυτά τα πράγματα. 

Νομίζω ότι το ερώτημα για κάθε εταιρεία, ανεξάρτητα από την τεχνική επιλογή, θα πρέπει να είναι: Αυτό διαφοροποιεί τους πελάτες μας; Υπάρχει μια ιστορία ή απαίτηση τελικού χρήστη που βελτιώνεται με τη λειτουργία και τη διαχείριση αυτής της υποδομής; Και αν η απάντηση είναι Όχι., τότε δεν πρέπει να το κάνετε με καμία τεχνολογία.

Όπως, ουσιαστικά κανείς τώρα δεν μπορεί να δικαιολογήσει τη λειτουργία του δικού του Git hosting. Είναι απλώς τρελό να μην ξοδεύετε το γελοία χαμηλό χρηματικό ποσό για να το GitHub ή το GitLab να το κάνει για εσάς. Είναι ένα ξεκάθαρο επιχείρημα. δεν υπάρχει κανένα πλεονέκτημα να το κάνεις μόνος σου. Καθώς η τεχνολογία χωρίς διακομιστή και γενικά βελτιώνεται, αυτή η γραμμή κινείται παντού για όλους. Απλώς δεν πρόκειται να δημιουργήσετε μια ομάδα εσωτερικής βάσης δεδομένων ή ομάδα λειτουργιών που να είναι καλύτερη από ό,τι σε παρόχους υπηρεσιών όπως εμείς. 

Και ακόμα κι αν το κάνατε, πώς θα το ήξεραν οι χρήστες; Τι θα έκανε για τη βάση χρηστών σας; Πολύ λίγο — στο 99.9 τοις εκατό των περιπτώσεων, δεν τους ενδιαφέρει η στοίβα τεχνολογίας σας. Κάθε εταιρεία θα πρέπει λίγο πολύ να κάνει πράγματα που κινούν τη βελόνα για τους δικούς της χρήστες και να αξιοποιούν όσο περισσότερη διαχειριζόμενη υποδομή μπορούν.

Η ασφάλεια είναι ένα πρόβλημα εμπειρίας χρήστη και είναι πολύ θεμελιώδες. Είναι δύσκολο να είσαι ασφαλής αν δυσκολεύεις τους χρήστες σου να κάνουν το σωστό.

Πώς βλέπετε να εξελίσσονται οι ανησυχίες για την ασφάλεια και το απόρρητο των δεδομένων, ειδικά για τους παρόχους SaaS;

Όλοι νοιάζονται για την ασφάλεια. Είναι κάτι που πρέπει να λάβουμε εξαιρετικά σοβαρά υπόψη ως εταιρεία που φιλοξενεί δεδομένα ανθρώπων. Μια τάση που βλέπω είναι αυτή Οι εταιρείες προχωρούν για τις πιστοποιήσεις συμμόρφωσής τους πολύ νωρίτερα από ό,τι στο παρελθόν. Τώρα πρέπει να αποκτήσεις Πιστοποίηση SOC 2 σχεδόν αμέσως, διαφορετικά δεν θα μπορείτε να παίξετε. (Αν θέλετε λίγο διάβασμα, το Fly.io έγραψε ένα ανάρτηση ιστολογίου στο SOC 2 αυτό αξίζει να το εξετάσετε.)

Και, γενικά, οι εταιρείες ενδιαφέρονται πολύ για ορισμένες δυνατότητες που είναι πλέον επιτραπέζια στοιχήματα, όπως ο έλεγχος ταυτότητας μίας σύνδεσης, η καταγραφή ελέγχου και τα κατάλληλα ανακλητά διακριτικά πρόσβασης.

Για παράδειγμα, τώρα, εάν ελέγξετε κατά λάθος τα διαπιστευτήρια της βάσης δεδομένων σας σε ένα δημόσιο αποθετήριο GitHub, τα ανακαλούμε αμέσως, ώστε οι χρήστες να μην έχουν πρόσβαση στη βάση δεδομένων σας. Αυτό είναι το πράγμα που συνέβαινε παλαιότερα - οι άνθρωποι έσπρωχναν τα διαπιστευτήριά τους AWS σε ένα αποθετήριο ανοιχτού κώδικα και στη συνέχεια ο λογαριασμός τους ξαφνικά χρησιμοποιείται για εξόρυξη Bitcoin και έχουν εξαντλήσει δεκάδες χιλιάδες δολάρια σε λογαριασμούς, ή τα δεδομένα τους είναι εκεί έξω στο διαδίκτυο

Τελικά, η θετική μου άποψη είναι ότι η ασφάλεια είναι ένα πρόβλημα εμπειρίας χρήστη και είναι πολύ θεμελιώδες. Είναι δύσκολο να είσαι ασφαλής αν δυσκολεύεις τους χρήστες σου να κάνουν το σωστό. Εάν ορίσετε την ασφάλεια ως μη προεπιλογή και κάτι που οι άνθρωποι πρέπει να σκεφτούν και να διαμορφώσουν, είναι πιο πιθανό να κάνουν λάθη. Έτσι, για παράδειγμα, δεν μπορείτε να συνδεθείτε στο PlanetScale με μη κρυπτογραφημένο τρόπο — εσείς δεν μπορεί να. Οι άνθρωποι το θέλουν αλλιώς γιατί θέλουν να είναι τεμπέληδες ή θέλουν να κάνουν πράγματα με συγκεκριμένους τρόπους. Απλώς δεν το κάνουμε δυνατό. Το αποτέλεσμα είναι ότι κανείς δεν μπορεί να ανακατέψει και να στείλει τα δεδομένα του σε απλό κείμενο στο διαδίκτυο. Αυτό, πάλι, είναι μέρος της εμπειρίας χρήστη. 

Για κάθε [υπηρεσία παροχής cloud] — και υπάρχουν εκατοντάδες στο Amazon — υπάρχουν πέντε καυτές νέες νεοφυείς επιχειρήσεις που ανταγωνίζονται εναντίον της. Και θα είναι πολύ δύσκολο να νοιάζεστε για τόσους πολλούς χρήστες και θήκες χρήσης και να συνεχίζετε να κλιμακώνεται.

Ανέφερες προηγουμένως χωρίς διακομιστή. Ποιος είναι ο ορισμός της λειτουργίας χωρίς διακομιστή;

Ο τρόπος που το περιγράφω είναι ότι τα καλά προϊόντα χωρίς διακομιστή πρέπει να εκθέτουν μόνο αυτό που εσείς απολύτως χρειάζεται έλεγχος για να γίνουν τα πράγματα. Εάν ανεβάσατε ένα αρχείο στο Dropbox και σας ρωτούσαν, "Πόσοι διακομιστές θα θέλατε να το διατηρήσουμε ενεργό ώστε να παραμένει εξαιρετικά διαθέσιμο;" Θα λέγατε, «Δεν είναι αυτό που πληρώνω εσείς Για?" Είναι αυτή η υπόσχεση του σύννεφου; Το cloud θα πρέπει να είναι πολύ περισσότερα από την απλή προσθήκη vCPU και μνήμης, αλλά στο cloud. 

Ο διακομιστής δεν λέει, «Ποια είναι η μονάδα αξίας για το χρήστη? Τι κάνει το χρήστη θέλω να κάνω?" Και δεν τους αναγκάζει να κάνουν κάτι περισσότερο από αυτό. Επομένως, για μένα, είναι μια αισιόδοξη κίνηση που πηγαίνει προς την απλότητα και τον καλύτερο σχεδιασμό προϊόντων. 

Πώς θα αξιολογούσατε τη σχέση μεταξύ της εταιρείας σας και των παρόχων cloud αυτή τη στιγμή; Είναι το "frenemies" μια δίκαιη περιγραφή;

Είναι ενδιαφέρον, γιατί ανταγωνιζόμαστε με κάποιους τρόπους, αλλά φέρνουμε επίσης πολύ περισσότερη χρήση στην πλατφόρμα τους. Για πελάτες που χρησιμοποιούν τη διαχειριζόμενη, cloud-prem έκδοση μας, συνεργαζόμαστε με τους αντιπροσώπους της Amazon, ώστε οι χρήστες να μην φύγουν για να πάνε στην Google. παραμένουν στο Amazon και χρησιμοποιούν το λογισμικό μας. Έτσι, οι επαναλήψεις εξακολουθούν να καταναλώνουν πολύ, έχουμε την άποψή μας για όλη αυτή τη συμφωνία και είναι υπέροχο. Νομίζω ότι σιγά σιγά θα πάνε πίσω και θα έχουν εταιρείες σαν εμάς να είναι η εμπειρία του τελικού χρήστη. Και τελικά εξακολουθούν να κερδίζουν, επειδή εξακολουθούν να πωλούν διακομιστές σε όλο και μεγαλύτερους όγκους. 

Αλλά βρισκόμαστε σε αυτήν την ενδιαφέρουσα μεσαία φάση, όπου δεν είναι απλώς μεγάλοι λιανοπωλητές. Εξακολουθούν να μας ανταγωνίζονται με ορισμένα προϊόντα, αλλά γίνεται πολύ πιο δύσκολο γιατί, τώρα, για κάθε μία από τις υπηρεσίες τους - και υπάρχουν εκατοντάδες στο Amazon - υπάρχουν πέντε καυτές νέες νεοφυείς επιχειρήσεις που ανταγωνίζονται εναντίον της. Και θα είναι πολύ δύσκολο να νοιάζεστε για τόσους πολλούς χρήστες και θήκες χρήσης και να συνεχίζετε να κλιμακώνεται.

Εάν είστε ο τύπος του μάνατζερ που δεν προσπαθεί να ανεβαίνει τη σκάλα όλη την ώρα — αλλά απλώς ολοκληρώνει αυτό που λέτε ότι πρόκειται να κάνετε, και είστε συλλογικοί ενώ το κάνετε και βοηθάτε τους ανθρώπους να κερδίζουν και πιέζετε άνθρωποι προς τα εμπρός — φυσικά θα μεταφερθείτε σε μεγαλύτερα δωμάτια.

Άσχετο: Δεν ήσουν αρχικά ο Διευθύνων Σύμβουλος της PlanetScale. Πώς προέκυψε η μετάβασή σας από CPO σε Διευθύνοντα Σύμβουλο;

Όταν μπήκα, η εταιρεία έκανε τα πράγματα λίγο διαφορετικά. Κάναμε hosted Vitess, το οποίο είναι το παλιό προϊόν που είχαμε. Αποφάσισα ότι ήθελα να δημιουργήσω ένα καταπληκτικό προϊόν βάσης δεδομένων που είχε τον πυρήνα του το Vitess, όπου το Vitess ήταν η υποκείμενη μηχανή, αλλά δεν ήταν το τελικό προϊόν. Έτσι, κάπως πετάξαμε το παλιό προϊόν και κατασκευάσαμε αυτό το νέο, και έγινε πολύ επιτυχημένο. Και μετά προσέλαβα πολλούς ανθρώπους από την προηγούμενη εταιρεία μου, το GitHub, και ανθρώπους που γνώριζα καλά. 

Σε εκείνο το σημείο, μεγάλο μέρος της εταιρείας και της κουλτούρας ήταν άνθρωποι που είχαν έρθει να δουλέψουν μαζί μου —για να συνεργαστούν ξανά— έτσι μια διπλή αλλαγή της κουλτούρας και του προϊόντος ήρθε μέσα από αυτό που ήθελα να κάνω. Το τελευταίο λογικό πράγμα ήταν να ευθυγραμμιστούν τα πάντα κάτω από αυτό το όραμα. Γι' αυτό έγινα Διευθύνων Σύμβουλος.

Ήταν μια απλή μετάβαση που έγινε και ξεσκονίστηκε πολύ πολύ γρήγορα. Θέλω να πω, οι ιδρυτές μας είναι υπέροχοι. Ξεκίνησαν αυτήν την εταιρεία, έχτισαν την εταιρεία και μετά την παρέδωσαν όπως πολλοί ιδρυτές. Κάποιες εταιρείες θα έπρεπε να το είχαν κάνει νωρίτερα.

Ανεβήκατε επίσης τη σκάλα στο GitHub αρκετά γρήγορα, από το DBA σε αντιπρόεδρο της μηχανικής. Ποια είναι η συμβουλή σας για την επιτυχή πραγματοποίηση αυτών των τύπων μεταβάσεων, καθώς και για να αποφασίσετε εάν η μετάβαση στη διοίκηση είναι η σωστή;

Πρωτα απο ολα, εάν είστε σε μια εταιρεία που απαιτεί να γίνετε διευθυντής για να έχετε οποιαδήποτε επιρροή, τότε είστε σε λάθος εταιρεία. Νομίζω ότι πολλοί άνθρωποι αφήνουν έναν μεμονωμένο ρόλο συνεισφέρον για να πάνε και να γίνουν μάνατζερ απλώς και μόνο για να παραμείνουν στην αίθουσα, κάτι που είναι τρομερό. 

Η συμβουλή μου είναι να γίνετε διευθυντής εάν νοιάζεστε βαθιά για τους ανθρώπους και νοιάζεστε για τα αποτελέσματα που μπορούν να επιτύχουν οι σπουδαίοι άνθρωποι. Μπορείτε να πάτε πολύ μακριά από την άλλη πλευρά, όπου είστε απλώς διευθυντής ανθρώπων και δεν σας ενδιαφέρει τόσο πολύ η δουλειά. Νομίζω ότι τελικά θέλεις να δεις να χτίζονται σπουδαία πράγματα, και αυτό το κάνεις μέσω της σπουδαίας κουλτούρας και της ενδυνάμωσης των ανθρώπων. Έτσι, εάν νοιάζεστε για αυτά τα πράγματα και μπορείτε να τα φτιάξετε, γίνετε διευθυντής.

Πραγματικά με ένοιαζαν αυτά τα πράγματα. Μπήκα στο GitHub ως μηχανικός και είχα αντίκτυπο εκεί και μου άρεσε. Και ήξερα ότι για να κλιμακώσουμε, για να συνεχίσουμε να κάνουμε σπουδαία μηχανική, χρειαζόμασταν εξαιρετική διαχείριση. Ήθελα να οικοδομήσω μια κουλτούρα υψηλών επιδόσεων με σπουδαίους μηχανικούς. Άρχισα λοιπόν να το κάνω αυτό και είχαμε πολλές αλλαγές. Η εταιρεία μεγάλωσε, αλλά απλώς δούλεψα πολύ σταθερά με ανθρώπους που ήξερα ότι έκαναν καλά πράγματα και απλώς μεγάλωσα από εκεί. 

Πάντα σου ζητείται να κάνεις περισσότερα. Εάν είστε ο τύπος του μάνατζερ που δεν προσπαθεί να ανεβαίνει τη σκάλα όλη την ώρα — αλλά απλώς ολοκληρώνει αυτό που λέτε ότι πρόκειται να κάνετε, και είστε συλλογικοί ενώ το κάνετε και βοηθάτε τους ανθρώπους να κερδίζουν και πιέζετε άνθρωποι προς τα εμπρός — φυσικά θα μεταφερθείτε σε μεγαλύτερα δωμάτια. Αυτό ακριβώς συνέβη σε μια χρονική περίοδο. Και τελικά, ναι, διηύθυνα μια μεγάλη ομάδα εκεί ως αντιπρόεδρος επειδή απλώς έκανα πάντα ακριβώς ό,τι ήταν απαραίτητο για την επιχείρηση και κολλούσα σε αυτό και δούλευα σκληρά και ενδυνάμωσα τους ανθρώπους. 

Και το πράγμα για το οποίο είμαι πιο περήφανος είναι πόσοι άνθρωποι ήρθαν από το GitHub στο PlanetScale επειδή το γνώριζαν αυτό. Ξέρεις τι εννοώ? Δεν το έκαναν έχουν προς την. Αυτό ήταν, για μένα, ένα σημάδι ότι είχα δείξει ότι μπορούσα να κάνω με συνέπεια αυτό που έλεγα ότι θα κάνω ως ηγέτης. Ο κόσμος ήρθε για αυτό.

Επιπλέον: Πολύ συχνά, οι μάνατζερ καταστρέφουν εταιρείες. Γράψαμε α μανιφέστο διαχείρισης Αυτό δείχνει πώς νιώθουμε για αυτόν τον ρόλο.

Εάν δεν μπορείτε να διαχειριστείτε την ιδέα ότι τα λάθη σας θα μπλέξουν με την καριέρα των ανθρώπων και ότι οι άνθρωποι εξαρτώνται πραγματικά από εσάς, τότε [η διαχείριση] δεν είναι για εσάς. 

Εάν είστε IC και θέλετε να μεταβείτε στη διαχείριση, ποιο είναι το πρώτο βήμα;

Νομίζω ότι πρέπει να αρχίσετε να μαθαίνετε να σκέφτεστε κοινωνιολογικά για τη δυναμική της ομάδας και των ανθρώπων γύρω σας και πώς μπορείτε να επηρεάσετε τον τρόπο με τον οποίο οι άνθρωποι συνεργάζονται ως ομάδα. Γίνοντας α τεχνολογικό προβάδισμαΤο , για παράδειγμα, έχει πολύ περισσότερη κοινωνική δυναμική από το να γράφει απλώς τον καλύτερο κώδικα. Πρέπει να σκεφτείτε πράγματα από τα οποία εξαρτιόμαστε, τους ανθρώπους από τους οποίους βασιζόμαστε και πώς διαμορφώνουμε τον οργανισμό μας ώστε να αντικατοπτρίζει τη δουλειά που πρόκειται να κάνουμε — χωρίς να χρειάζεται να μπείτε στις σκέψεις και τα συναισθήματα των ανθρώπων και να τα διαχειριστείτε πραγματικά . Οπότε ένας καλός τρόπος είναι να προσπαθήστε να ηγηθείτε ενός έργου που έχει πολλή διαλειτουργική δουλειά και εξαρτήσεις, και απαιτεί άτομα που λειτουργούν καλά μαζί, για να δείτε αν έχετε την ικανότητα να εμπνεύσετε τους ανθρώπους να κάνουν τη δουλειά τους ως ομάδα. 

Εάν μπορείτε να το κάνετε αυτό με επιτυχία, τότε μπορείτε να αρχίσετε να μαθαίνετε τις δεξιότητες που χρειάζονται για να εργαστείτε πραγματικά καλά με τους ανθρώπους και να είστε ο μάνατζέρ τους. Γιατί αυτός είναι ένας δύσκολος ρόλος. είναι ένας ρόλος δουλείας. Οι άνθρωποι βάζουν την καριέρα τους στα χέρια σας και αυτό είναι κάτι που πρέπει να το πάρετε πολύ σοβαρά. Εάν δεν μπορείτε να διαχειριστείτε την ιδέα ότι τα λάθη σας θα μπλέξουν με την καριέρα των ανθρώπων και ότι οι άνθρωποι εξαρτώνται πραγματικά από εσάς, τότε δεν είναι για εσάς. 

Εάν πιστεύετε ότι μπορείτε να το κάνετε και θέλετε να βοηθήσετε τους ανθρώπους να γίνουν καλύτερες εκδοχές του εαυτού τους, ψάξτε.

Δημοσιεύτηκε στις 2 Αυγούστου 2022