Identiteitscrisissen zijn een verrassend vaak voorkomende uitdaging in datateams. Zijn we data engineers? Zijn we analytics ingenieurs? Wie weet. De verantwoordelijkheden van een team groeien organisch met het Data Platform waaraan ze werken, en ze komen vaak niet perfect overeen met een industriestandaard.
Existentiële angst heeft ons weliswaar heel wat meesterwerken in de kunst en literatuur opgeleverd, maar helpt je niet om de data intelligence-strategie van je dromen te implementeren.
Ik weet dat het duister klinkt, maar hé, goed nieuws, we zijn hier om te helpen! Ik zal in dit artikel de methode uitleggen die we hebben bedacht om deze problemen het hoofd te bieden en je eigen data-zelf te vinden, op een goedkopere en minder tijdrovende manier dan drie maanden backpacken!
Als eerste stap moeten we goed begrijpen voor welke uitdaging we staan, en welke beweegredenen het rechtvaardigen om ons in te spannen om het team beter te begrijpen en het bij de juiste naam te noemen.
Laten we eens kijken naar de negatieve gevolgen die het kiezen van het verkeerde label kan hebben voor jouw team:
- Als je een nieuw lid probeert aan te werven, zullen zowel jij als de recruiter veel sollicitaties ontvangen van personen die niet aan de criteria voldoen en zullen ze moeite hebben om iemand te vinden die de functie kan invullen Dit is tijdverlies van beide kanten en verslechtert de relatie tussen de aanwervende manager en de recruiter.
- Als je niet weet wat de zeldzaamste skill is voor die functieomschrijving, zul je die niet het juiste gewicht geven bij het kiezen van een nieuwe teamlid. Als je een Data Engineer die Kubernetes kent nodig hebt en weet te vinden, moet je misschien twee keer nadenken voordat je hem laat gaan.
- De kans om de verkeerde persoon aan te nemen zal groter zijn. Ze kunnen erachter komen dat de baan niet was wat ze verwachtten en vertrekken na een duur wervings- en inwerkproces. Of ze kunnen blijven en kiezen voor stille uittreding.
- Andere teams zullen niet duidelijk begrijpen wat de verantwoordelijkheden van je team zijn en wat ze van hen kunnen verwachten. Jouw team zal niet worden toegevoegd aan de juiste vergaderingen, beslissingen zullen worden genomen zonder hen erbij te betrekken.
- Het zal voor de teamleden moeilijker zijn om te begrijpen in welke richting ze zich moeten verbeteren.
Nu je ziet waarom en hoe dit heel erg fout kan gaan, kunnen we het gaan oplossen. Maar hoe?
De rolvergelijkingstabel
Hoe gaan we dit probleem aanpakken? Met een van de oudste trucs uit het ingenieursboek, ouder zelfs dan de rekenliniaal, een referentietabel.
We willen hier drie problemen oplossen:
- Wat is de beste beschrijving van wat mijn team momenteel doet?
- Wat zijn de technische vaardigheden die in mijn team aanwezig zijn, maar die ongebruikelijk zijn bij professionals met dezelfde functieomschrijving?
- Als ik iemand aanneem met een specifieke functieomschrijving, wat mag ik dan verwachten dat hij of zij kent en in welke mate?
De tabel met technische vaardigheden is bedoeld om jou te helpen bij die valkuilen. In de eerste kolom vind je een lijst van typische technische vaardigheden op het gebied van data, en in de andere kolommen geven we het niveau van de vaardigheid aan die gewoonlijk bij een specifieke functie hoort: ++ voor diepgaande kennis of dagelijkse betrokkenheid, + basiskennis of incidentele betrokkenheid, en een lege plek voor vaardigheden die geen verband houden met die functietitel. Wij hebben bewust gekozen voor symbolen in plaats van meer gedetailleerde beschrijvingen, om de complexiteit van de methode te minimaliseren.
We laten een lege kolom open voor jou om te vullen met het vaardigheidsniveau van je team.
De tabel wordt geacht te worden gebruikt zoals hieronder:
- Kopieer de tabel in een tekstverwerker (zonder omslag)
- Vul de kolom in met de mate van kennis of betrokkenheid van je team bij een specifieke technologie
- Verwijder de rijen die je niet hebt ingevuld, om alleen de technologie in de stack in overweging te nemen.
- Vergelijk de kolom van je team met de andere: kies de gegevensrol die het dichtst bij je team ligt
- Als je merkt dat je niet kunt kiezen tussen meerdere rollen, dan zit je team er precies tussenin.
- Ontdek welke skills problemen veroorzaken
- De technische skills die beschikbaar zijn in je team, maar die niet voorkomen in de rol die je hebt gekozen, zijn de vaardigheden die moeilijk zullen worden. Dus nu weet je het.
- De technische skills die gemarkeerd zijn met een * symbool zijn over het algemeen ongewoon.
- De technische skills die niet op de lijst staan, zijn over het algemeen ongewoon in de datamarkt.
Aannames voor de tabel
- Wij gaan uit van een omgeving waarin de teams groot genoeg zijn om de rollen zo duidelijk mogelijk te scheiden (bv. een grote bedrijfsomgeving). In kleinere bedrijven overlappen de rollen elkaar, maar door ze in de tabel te scheiden, kun je beter begrijpen hoe ze te combineren;
- We nemen aan dat de basiskennis van Python en Git voor iedereen fundamenteel is, dus die nemen we niet op in de tabel.
| Tech skills / Rollen | Data Engineer | Analytics Engineer | Data Analyst | Data Scientist | ML Engineer | Cloud/DevOps Engineer | Your team |
|---|---|---|---|---|---|---|---|
| AWS/Azure/GCP (General platform knowledge) | ++ | + | + | + | + | ++ | |
| Bash | + | + | + | ++ | |||
| Business knowledge | + | ++ | + | + | |||
| CI/CD pipelines (GitHub, Gitlab, Concourse, ArgoCD) | + | + | + | ++ | |||
| Cloud storage solutions | ++ | + | |||||
| Cloud infrastructure | + | ++ | |||||
| Dashboarding (Tableau/PowerBI) / Data Visualization | ++ | ++ | + | ||||
| Data modeling | + | ++ | + | ||||
| Dbt | + | ++ | + | ||||
| Deployment of ML models as webapps (R-Shiny, Flask) | + | + | ++ | ||||
| Docker | + | + | + | ++ | |||
| ELT/ETL pipelines | ++ | + | + | + | |||
| Exploratory data analysis | + | ++ | + | ||||
| Git (administration) | + | ++ | |||||
| Golang* | + | ||||||
| Hadoop* | ++ | + | + | ||||
| Implementation of business rules in SQL | + | ++ | ++ | + | + | ||
| Infrastructure as code (Terraform/Ansible/Chef) | + | ++ | |||||
| Kafka/Data Streaming* | ++ | + | + | ||||
| Kubernetes | ++ | ||||||
| Machine Learning Models | + | ++ | ++ | ||||
| Pandas/Numpy | + | + | ++ | ++ | ++ | ||
| Reporting | ++ | + | + | ||||
| SQL | ++ | ++ | ++ | + | + | ||
| Scala* | ++ | + | + | ||||
| Snowflake/DWH | + | ++ | + | + | + | ||
| Spark | ++ | + | ++ | ++ |
Wil je de inhoud van de tabel kopiëren en/of bewerken? Klik dan hier.
Voorbeeld
Met al die regels en tabellen lijkt deze methode ingewikkelder dan dat het daadwerkelijk is. Laten we een praktisch voorbeeld nemen om je een idee te geven van wat je hiermee kunt doen.
Bij ons bedrijf X hebben we een Data Engineering team. We willen de capaciteit vergroten, dus besluiten we een nieuwe eenheid aan te nemen. We willen de vaardigheidstabel gebruiken om beter zicht te krijgen op het wervingsproces. Daartoe kopiëren we de hele tabel, vullen de kolom voor ons team in, maken de waarden in de kolommen die overeenkomen vet en sorteren de rijen vervolgens op de inhoud van de teamkolom, aflopend:
| Skills / Roles | Data Engineer | Analytics Engineer | Data Analyst | Data Scientist | ML Engineer | Cloud/DevOps Engineer | Your Team |
|---|---|---|---|---|---|---|---|
| CI/CD pipelines (GitHub, Gitlab, Concourse, ArgoCD) | + | + | + | ++ | ++ | ||
| Infrastructure as code (Terraform/Ansible/Chef) | + | ++ | ++ | ||||
| AWS/Azure/GCP (General platform knowledge) | ++ | + | + | ++ | ++ | ||
| Cloud storage solutions | ++ | + | ++ | ||||
| Cloud infrastructure | + | ++ | + | ||||
| Kafka/Data Streaming* | ++ | + | + | ++ | |||
| Kubernetes | ++ | ++ | |||||
| ELT/ETL pipelines | ++ | + | + | + | + | ||
| Bash | + | + | + | + | + | ||
| Dbt | + | ++ | + | + | |||
| Docker | + | + | + | + | + | ||
| Git (administration) | + | ++ | + | ||||
| SQL | + | ++ | ++ | + | + | + | |
| Snowflake/DWH | + | ++ | + | + | + | + | |
| Spark | + | + | ++ | ++ | + | ||
| Golang* | + | + |
Je ziet hier meteen een probleem: ons team deelt competenties met zowel Data Engineering als Cloud/DevOps Engineering. Welke moeten we kiezen?
We stellen bewust geen numerieke regel op om te beslissen: dit is een hulpmiddel om een duidelijker perspectief op de situatie te geven, en het kan de hiring manager niet vervangen bij het nemen van deze beslissing.
In ons geval weten we dat het team al gevestigd is als Data Engineering-team, dat de leden blij zijn met die titel, en dat de + vaardigheden overeenkomen met wat we van een Data Engineering-team zouden verwachten.
We zien echter ook dat ons team vaardigheden heeft die ongebruikelijk zijn voor Data Engineers:
- Diepgaande kennis van Kubernetes
- Diepgaande kennis van CI/CD
- Diepgaande kennis van Infrastructure as code
- Bekendheid met Golang (op zich al ongewoon)
Onder de data engineering skills wordt Kafka (gemarkeerd met ++) als zeldzaam beschouwd.
Dit betekent dat:
- Ik op zoek moet naar een Data Engineer
- De kennis van Kafka is minder beschikbaar, maar als iemand deze kennis heeft, zal het een Data Engineer zijn, die een grotere kans heeft om ook aan de andere vereiste vaardigheden te voldoen.
- De kennis van Kubernetes, CI/CD en Golang zal zeldzaam zijn in combinatie met de andere Data Engineering vaardigheden, en dit maakt het vrij moeilijk om de positie in te vullen.
- Misschien moet ik een compromis sluiten en iemand kiezen die slechts gedeeltelijk aan het profiel voldoet of die minder bekwaam is, of het team reorganiseren – bijvoorbeeld door er een Cloud/DevOps Engineer aan toe te voegen.
Ziezo. Het ziet er nu duidelijker uit, hè?
What’s next?
Ik hoop dat dit artikel het wat gemakkelijker maakt om je volgende teamlid aan te werven en aan anderen uit te leggen waarom je deze beslissing maakt. Begrijp alsjeblieft dat dit met opzet een vereenvoudiging is van een zeer complex scenario. Als je verder wilt sparren of andere suggesties hebt, neem dan contact met mij op.
Veel succes met de zoektocht!