Där samarbete misslyckas kring data (och 4 tips för att fixa det)

Återutgiven av Platon

anhängare: 0

Där samarbete misslyckas kring data (och 4 tips för att åtgärda det)
Bild av creativeart på Freepik

Datateam arbetar alltmer som mjukvaruteknikteam och anammar ingenjörs- och utvecklingsverktyg för att hantera sitt arbete. Dessa sträcker sig från versionskontrollsystem som Github, till att använda agila metoder som Kanban och Scrum, och inkluderar ceremonier som daglig standup, sprintåtaganden och sprintdemos. Specialbyggda lösningar (som dbt för datamodellering, testning och integration) har kommit ut på marknaden och stödjer det mjukvarutekniska tankesättet. Dessa lösningar driver stora, distribuerade datateam att göra sitt bästa arbete.

Men när det kommer till samarbete mellan datateam och resten av verksamheten finns det fortfarande mycket utrymme för innovation.

Även de mest framåtsträvande datadrivna organisationerna förlitar sig fortfarande på standardverktyg och metoder för samarbete (t.ex. Slack, e-post eller regelbundet schemalagda möten) för att hantera kommunikationen mellan sina datateam och affärsintressenter. När allt kommer omkring, varför inte? Borde inte datateamet och dess arbetsflöden likna andra funktioner i organisationen? Detta argument och beteende fungerar när interaktionerna är relativt generiska till sin natur. Men i situationer där teamdynamiken är mer komplex (och data är mer central för alla viktiga samtal och beslut), är detta beroende av generiska lösningar otillräckligt.

När data blir mer central för affärsverksamheten behöver datateammedlemmar ofta bära flera hattar. I vissa fall måste de fungera som produktchefer genom att förstå affärsanvändarnas behov, så att de kan utveckla dataplattformen. I andra fall måste de hantera ad hoc-förfrågningar i en supportkapacitet. I ytterligare andra situationer måste de ta med nya användare och hjälpa dem att engagera sig med de datatillgångar som är tillgängliga för dem.

Generiska samarbetsverktyg och traditionella metoder för att hantera arbete går snabbt sönder i dessa scenarier. Produktteam och supportteam har specialbyggda verktyg för att hantera sitt arbete. Behöver inte datateam också en lösning för att bäst hantera intressentförfrågningar? Eller verktyg för att hantera deras supportdokumentation, eller utbildning av slutanvändare? De bästa datateamen finner sig ofta kämpa med den här delen av sitt arbetsflöde och slutar med att anta lösningar som är byggda för andra (i det här fallet produkt- och supportteam).

Eftersom det mesta dataarbetet och interaktionerna är internt kan det vara svårt för team att hitta rätt sätt att arbeta med affärsintressenter utan att skapa förvirring och stöta på besvärligheten.

Om du undersöker samarbetsproblemen mellan datateam och andra kommer du säkert att hitta informationsasymmetrier mellan byggare och konsumenter av datatillgångar. Å ena sidan har du databyggare med djup kunskap om underliggande data, hur man manipulerar och analyserar den och hur man kontextualiserar den inom en större mängd datatillgångar. Å andra sidan har du datakonsumenter, som vanligtvis är domänexperter med rik kunskap om själva verksamheten, vilket kan vara avgörande för att tillhandahålla ett bredare sammanhang, förstå data och utveckla dataplattformen.

Ta Jane, till exempel. Hon gick precis med i ett Fortune 500-företag som försäljningschef och ledde ett distribuerat team på 15 säljare utspridda över sydost. Den andra dagen av sitt nya jobb vidarebefordras hon ett mejl från en kollega med flera länkar till olika resurser: ett kalkylblad med pipelineinformation, olika rapporter i Salesforce och en handfull dashboards om individuell prestation i företagets BI-lösning. Efter att ha ägnat några minuter åt att titta på uppgifterna inser hon att hon inte har någon aning om vad hon egentligen tittar på och vad det betyder. Hon skickar ett meddelande till sin försäljningschef och ber om hjälp, som slingrar in sin partner i datateamet som byggde de flesta av dessa resurser. Dataanalytikern läser mejlet, suckar och ägnar sedan nästa timme åt att skriva ett svar. De skapar en biljett på sin JIRA-tavla för att "omvärdera dokumentation."

Grundorsaken bakom dessa typer av datasamarbetsproblem är informationsasymmetrier mellan byggare och konsumenter, vilket gör alla frustrerade och olyckliga.

Tragiskt nog är de personer som oftast påverkas av denna dynamik junioranställda eller mellanchefer i frontlinjen, eftersom de vanligtvis har mindre makt i organisationen och det minsta sammanhanget för att förstå de beslut som fattas kring data. Utan intensiv utbildning är dessa anställda sårbara för typer av kommunikationsproblem som beror på informationsasymmetrier. De är också benägna att falla offer för "squeaky wheel syndrome", där chefer och ledande ledningsgruppmedlemmars röster naturligtvis hörs högst av datateam (och därför prioriteras deras önskemål och behov framför andras.)

För att få en bättre avkastning på investeringen från de massiva investeringarna i dataverktyg och team måste vi angripa dessa informationsasymmetrier i hjärtat av våra problem. Att komma till noll är kanske ett ambitiöst mål, men datateam bör ständigt sträva efter att överbrygga detta gap genom metoder, partnerskap och verktyg. Om du gör det tar du bort friktion, ökar transparensen och förtroendet och låter alla få ut mer av företagets dataerbjudanden.

Här är 4 proaktiva tips för dataledare som vill minska informationsasymmetrier och uppnå bättre samarbete i sina organisationer:

Anpassa organisations- och teamstrukturer med verksamhetens behov. Detta inkluderar inte bara rapporteringsmodeller, utan även datateamroller och funktioner. Vi börjar redan se fler jobbannonser för roller som "data produktchef" eller "data scrum master." Dessa nya funktioner kommer att hjälpa datateam att hantera samarbetsutmaningar som i slutet av dagen vanligtvis handlar om människor och processer kontra underliggande tekniska problem.
Överväg att investera i en matrismodell där medlemmar av ditt team – eller i vissa fall hela poddar – är anpassade till specifika affärsenheter. Detta kommer att möjliggöra anpassning av långsiktiga datainitiativ till omedelbara affärsbehov, främja kunskapsdelning, såväl som närmare, samarbetsrelationer mellan analytiker och de som de stöder dagligen.
Börja smått och bygg vidare på din framgång allt eftersom. De kraften i första intryck kan inte överskattas. Inledande uppfattningar om datateamet är otroligt viktiga för hur deras arbete kommer att tas emot, så tänk på hur det går med nyckelteammedlemmar i förväg. Fokusera genom att bygga starka relationer med 1-2 viktiga mästare i organisationen som kan hjälpa till att sprida ordet om hur fantastisk du är. Expandera därifrån.
Tänk på vilka samarbetsverktyg kan utnyttjas under hela livscykeln för dina datainitiativ och dataprodukter. Tänk till exempel på hur du vill samla dina medarbetare, processer och system för var och en av kategorierna nedan. Ofta kommer det som fungerar för en kategori att misslyckas i andra:
- Samarbete inom datateamet
- Generiskt samarbete med andra anställda utanför ditt team
- Ad hoc-frågor eller begäranden om nya funktioner
- Löpande support för dataprodukter
- Omfattning av nya datainitiativ eller dataprodukter
- Utveckla ditt dataerbjudande baserat på vad som är värdefullt för verksamheten

Innovativa datateam migrerar redan till bästa praxis för mjukvaruteknik och den trenden kommer sannolikt att fortsätta under de kommande åren. När du tittar på att investera i datainfrastruktur för att stödja framtida tillväxt, tänk på verktyg som stöder affärspartnersamarbete.

Nicholas Freund är en erfaren SaaS-industrichef med över ett decenniums erfarenhet av att leda startups fokuserade på produktledd tillväxt. Som grundare och VD för Workstream.io leder Nick en startup-teknik i startfasen som hjälper datateam att hantera kritiska datatillgångar. Innan Workstream arbetade Nick som VP of Operations för BetterCloud, en oberoende mjukvaruleverantör som erbjuder den ledande SaaS Operations Management-lösningen. Tidigare hade Nick ledande ekonomipositioner på Tesla, samtidigt som han tog sin MBA vid Harvard.