Teamkommunikation (det betyder mer än dina verktyg)
Sedan de anlitade ett par entreprenörer är en fråga som andra ställer:
o Hur är det att gå från att arbeta med projekt själv till att arbeta med projekt med ett team?
Eller, enklare, hur är det att ha entreprenörer? Det korta svaret är att jag gräver det eftersom det ger några fördelar:
- vi måste ha en skarp arbetsfördelning,
- verksamheten kan ta sig an fler projekt,
- vi kan samarbeta om saker (vilket är något jag saknar med att flyga solo),
- och mer.
Den andra sidan av detta är dock att jag känner att jag måste lära mig hur det är att starta ett företag igen.
Som att börja med ett tomt blad.
Detta är på inget sätt en dålig sak. Det är tvärtom. Men när du går från att arbeta med projekt på egen hand och utveckla ditt setup, då är det en period av anpassning som händer.
Jag upplever fortfarande detta och jobbar igenom det. Det kräver både samtal med ditt team och lite introspektion för att avgöra om det du gör fortfarande är rätt för ditt sätt att arbeta eller om du bör anpassa det.
Teamkommunikation
Uppenbarligen är just detta ämne brett och jag – tillsammans med många av er – skulle kunna prata om en mängd olika saker när det gäller att driva ett företag.
Men för idag är det enda jag vill prata om den roll som teamkommunikation, inte dina mjukvaruutvecklingsverktyg, spelar för att leverera lösningar till andra.
Dina verktyg spelar roll (men inte lika mycket)
Till exempel har jag arbetat på en plats där de ger dig en maskin med en viss uppsättning verktyg och säger "Det här är vad vi använder för att bygga våra projekt."
Visst, det kräver att du lär dig det, men en del av mig gillade detta då det tar bort en huvudvärk som kommer med att komma på vad jag ska använda. Det hindrade mig också från att behöva ta de besluten på egen hand.
Å andra sidan gjorde det det också svårare att introducera ett nytt verktyg eftersom det skulle störa arbetsflödet för en hel avdelning. När man är ett litet team är det dock lite lättare att anpassa sig.
Visual Studio Code har blivit min favorit-IDE.
För det första, när du arbetar för dig själv har du förmodligen din favorit:
- GÅR
- källkontrollsystem,
- bygga verktyg,
- distributionsverktyg,
- värdmiljö,
- och så vidare.
Men när du tar med andra i mixen, tar du med dig exakt samma saker förutom att det är på deras villkor. Nu har du i uppdrag att bestämma om du ska hålla fast vid det du har, utvärdera vad de har, få dem att adoptera dina verktyg, adoptera deras verktyg, blanda ihop de två eller börja om.
Detta är inte ett trivialt sätt, särskilt när ni arbetar med varandra för att lösa en lösning för en kund. Jag skulle kunna skriva mycket mer om detta. Och missförstå mig rätt: Jag tycker att det är ett ämne som borde diskuteras och det är något som jag tycker är viktigt.
Men det finns något som står över allt detta som aldrig bör underskattas, och det är processen för teamkommunikation.
Kommunikation är viktigt (och betyder mer)
Jag pratar inte om att se till att kolla in folks humör varje dag (även om det är viktigt), och jag pratar inte om att chatta i text eller Slack eller IRC bara för att du ska känna dig produktiv.
Teamkommunikation är mer än Slack.
Jag pratar om att fullt ut kommunicera krav.
Exempel: Säg att jag pratar med en kund, accepterar ett kontrakt och är sedan redo att gå vidare. Jag vet vad de vill ha, de befintliga designerna och hur något ska fungera. Sedan tar jag in en lagkamrat och jag säger "Hej, låt oss börja."
Problemet här är tydligt, eller hur? Han/hon har ingen aning om vad det är vi är ute efter.
Och det spelar ingen roll hur mycket du beskriver stegen i ditt projektledningsverktyg eller chattar om hur något ska fungera.
Dessutom kan du ha den snyggaste och mest effektiva verktygsinställningen som möjligt, men om ditt team inte är tydligt med kraven i projektet spelar inget av det någon roll.
När du bestämmer dig för att anlita någon för att hjälpa dig med projekt, och när du bestämmer dig för att börja samarbeta om lösningen, lägg diskussionen om verktyg och första diskussionskrav.
Detta kan inte underskattas.
Om du känner till kraven och din lagkamrat inte gör det, eller om kraven inte är tydligt kommunicerade av en eller annan anledning, kommer den rätta lösningen inte att levereras. Och detta är uppenbarligen kostsamt.
Dessutom, om du slutar tro att du har samma idéer i åtanke och slutar med att implementera något helt annat, så har du ytterligare en uppsättning problem att ta itu med.
När det gäller min verksamhet är jag framförallt intresserad av att utveckla relationer med de personer som jag arbetar med både i mitt team och som anställer oss.
Men om de interna diskussionerna kring lösningarna vi arbetar med inte är på samma sida, spelar inget annat roll – inte ditt verktyg, inte vad du skickar, inte hur snabbt du skickar det, och inte om det bara blir gjort.
Det kommer mera
Så i ett framtida inlägg kommer jag att dela med mig av några idéer från personliga erfarenheter hittills – både misstag och vinster – i hopp om att du kan undvika vad det än är som du kan möta när du väljer att utöka ditt team.
Missförstå mig inte: Det är en fantastisk sak att göra (och jag älskar det), men det kräver justeringar på nivåer som jag inte var helt förberedd på.
Under tiden, om du har saker att bidra med till det här inlägget får du gärna göra det i kommentarerna. Jag är alltid sugen på att höra hur frilansare och de som också är egenföretagare eller som leder team hanterar just detta ämne.