Så navigerar du den känsliga konsten att inte veta allt som teknisk projektledare

Läs transkriptet:

Vi testar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte har rätt 100 % av tiden.

Galen Low: SaaS. SOC2. ADA. Jenkins. Du trodde att det var texter till en Charlie XCX-låt. Det visar sig att de inte är det. Och av uttrycket i din kunds ansikte att döma borde du förmodligen ha känt till det – eller åtminstone känt någon i ditt team som gjorde det. Men innan du lägger dina sporrar på hyllan och överger drömmen om att bli en respekterad ledare inom teknisk projektledning, fortsätt lyssna.

Vi ska undersöka hur teknisk du behöver vara som teknisk projektledare år 2025 – och hur teamledare kan stötta och utveckla högpresterande projektledare utan att skicka dem för att doktorera i DevOps.

Hej allihop, tack för att ni lyssnar. Jag heter Galen Low och arbetar med The Digital Project Manager. Vi är en gemenskap av digitala yrkesverksamma med uppdraget att hjälpa varandra att bli kunniga, självsäkra och uppkopplade, så att vi kan förstärka värdet av projektledning i en digital värld. Om du vill höra mer om det kan du gå till thedpm.com/membership.

Okej, i dag pratar vi om att vägleda, handleda och leda ett team av tekniska projektledare för att hitta rätt balans mellan tekniska färdigheter och social kompetens, samt hjälpa dem att utvecklas professionellt i en miljö där de behöver veta tillräckligt men helt enkelt inte kan veta allt om den teknik som deras team arbetar med.

Med mig i dag har jag Kayla Keizer, teamledare och senior teknisk projektledare på Plank, en digital byrå som specialiserar sig på webb- och IT-projekt för kunder inom konst och kultur, ideell verksamhet och utbildning.

Kay, tack så mycket för att du är här i dag.

Kayla Keizer: Tack för att du bjöd in mig.

Galen Low: Jag missade nästan din Costa Rica-bakgrund. Kom du tillbaka från Costa Rica i dag, i går?

Kayla Keizer: I dag, i morse.

Galen Low: Jag blev så entusiastisk. Jag bokade om det här på fel sätt, för vi kunde ha haft en djungel eller en strand i bakgrunden.

Kayla Keizer: Ja, det hade vi kunnat. Det är fortfarande grönt bakom mig, men det hade varit riktig natur bakom mig, djungeln.

Galen Low: Om du lyssnar på den här podden och inte tittar på den, föreställ dig bara underbar natur bakom Kay just nu.

Jag tänkte att vi kanske kunde kasta oss rakt in och börja med frågan som alla vill ha svar på, vilket jag tror är: kan man fortsätta utvecklas som teknisk projektledare utan teknisk utbildning? Eller kommer man att stöta på en vägg om man är en teknisk projektledare som inte kan felsöka Python, hantera Git, navigera i Laravel eller konfigurera ett CDN i AWS?

Vad tänker du om det?

Kayla Keizer: Jag tänker att du är en del av ett team av tekniska experter vars jobb i slutändan är att felsöka och konfigurera AWS. Så det är definitivt inte ditt ansvar att utföra det faktiska arbetet steg för steg, men det är alltid bra att förstå eller ha grundläggande kunskap om konceptet.

Om någon nämner Python och du inte har någon aning om vad det är, är det inte så bra. Men det är inget du måste gå i skolan för eller få särskild utbildning i. Du kan googla och få en bra förståelse eller grund. Du kan fråga dina teammedlemmar: ”Hej, har du något emot att lägga lite mer tid på att ge mig mer sammanhang kring det här, så att jag är bättre förberedd när vi pratar om det eller när vi skriver krav och jag kan ge dig den information vi behöver?”

Det du verkligen behöver veta är att förstå koncepten och också förstå: vilka frågor behöver jag ställa för att ge utvecklingsteamet, designern eller innehållsteamet den information de behöver för att faktiskt göra det som ska göras?

Galen Low: Pang. Jag älskar det. Jag älskar att det inte handlar om att du måste veta allt och skaffa formell utbildning i det. Konsten är faktiskt att ställa rätt fråga, att ha förmågan att ställa den och sedan också ställa rätt frågor så att du kan vara översättaren, den kanal genom vilken en del av den här informationen överförs mellan ditt team och dina intressenter. Jag tycker att det är så bra.

Jag undrar om vi kunde zooma ut lite, för tidigare i din karriär hamnade du i en roll som teknisk projektledare. Och jag vill inte lägga ord i din mun, men jag tror att det var under en period då du inte själv kände dig särskilt teknisk, och det var verkligen tekniskt. Du och jag pratade om det bakom scenen.

Det handlade om telekom, som är fullt av akronymer, tekniker och alla möjliga koncept som är ganska specifika för den branschen. Och nu har du följt den vägen och leder ett team av tekniska projektledare på Plank.

Vilket var det första stora hindret du ställdes inför som icke-teknisk projektledare när du ledde ett projektteam av tekniska specialister, och hur övervann du det?

Kayla Keizer: Jag tror att man måste övervinna sig själv lite. Som du sa var jag mitt i det. Jag arbetade med människor som hade varit på företaget i 10, 15, till och med 20 år.

De hade inte bara teknisk expertis, utan också en historia och bakgrund kring nätverkets grund. Jag var koordinator vid den tiden och arbetade också nära direktören. Jag hjälpte honom mycket. Återigen arbetade jag med direktören, som hade 25 års erfarenhet, och försökte förstå allt.

Men det som hjälpte mig att ta mig igenom det var att man inte kan undvika saker. Man måste komma över sig själv lite. Och ja, det är skrämmande. Och ja, man vet inte. Men man kommer inte att veta förrän man ställer frågorna, dyker djupt in i det och omfamnar utmaningen. Jag tycker att när man omfamnar saker börjar de gå mycket smidigare än när man tänker: ”Åh, det här är så dåligt. Jag vill inte göra det här.” Och så skjuter man upp det, är osäker och lägger all den negativa energin på det. Då kommer det alltid att kännas svårt. Det kommer alltid att kännas som att du sitter fast i lera och försöker ta dig därifrån. Så jag tror verkligen att det handlar om inställning och om att fejka självförtroende om man måste.

Galen Low: Jag gillar idén att vi så ofta skapar våra egna hinder genom att fastna i våra egna tankar. Medan det som faktiskt för saken framåt är att ha inställningen: ”Du vet vad, jag måste göra det här.” Och ja, kanske fejka det lite, men fejka det utifrån att vara tillräckligt självsäker för att våga fråga – även just nu, att vara självsäker och lura dig själv att du faktiskt kan det här.

Men framför allt att faktiskt komma fram till, som du säger, vad man ska fråga.

Kayla Keizer: Och att ställa frågor självsäkert. Du ska inte vara i bakgrunden. Du ska inte vara timid. Du ska inte komma till den du behöver fråga med rädsla och oro, för det kommer de att märka. Om du sitter i ett kundmöte kommer kunden att zooma in och förstå att du inte känner dig säker på det du pratar om.

Så det är det jag menar när jag säger att man ska fejka självförtroendet. Även om du inte vet är det okej, men var åtminstone rak, ärlig och självsäker. Människor tenderar att fokusera på det, eller så tappar de förtroendet om de känner: ”De är inte ens säkra på sig själva. Hur ska jag då kunna lita på dem?”

Det är det jag menar. Och för att återknyta till hur man kommer över det: när du har kommit över dina mentala hinder måste du luta dig mot dina styrkor. Min styrka var att jag är väldigt bra på dokumentation. Jag är väldigt bra på att förstå teknisk information när den förklaras för mig och sedan omvandla den till något för en kund, skriva en uppgift eller formulera krav.

Du behöver inte vara teknisk för att dokumentera och ställa frågor.

Galen Low: Nu gillar jag verkligen det, för även om man ser det som en bokstavlig översättarroll – som när man arbetar som översättare i FN:s generalförsamling – betyder det inte att man måste veta hur man leder ett land.

Men din färdighet, det du vill att människor ska kunna lita på dig för, är att få budskapet att landa på ett annat språk på andra sidan. Och jag tycker att det är en så stark och värdefull roll i teknikvärlden, IT-världen och den digitala världen, där det är just det du vill att människor ska kunna lita på dig för.

Inte din förmåga att koda, felsöka eller driftsätta programvara, utan att veta hur det görs och åtminstone kunna driva den dialogen och samordna allt så att det faktiskt blir gjort på ett meningsfullt och kompetent sätt.

Kayla Keizer: Ja.

Galen Low: Kan jag sätta dig på prov?

Kayla Keizer: Vadå?

Galen Low: Kan jag fråga vilken din läskigaste ”dumma” fråga var att ställa inom telekomvärlden?

Kayla Keizer: Jag vet inte om det var en specifik fråga, men jag erkänner att jag inte ställde tillräckligt många frågor i början. Och jag kanske överskattade mina kunskaper.

Galen Low: Okej, ja. Du fejkar verkligen hårt.

Kayla Keizer: Ja, och de bad mig om någon sorts rapport. Jag gick iväg och gjorde rapporten efter bästa förmåga, ställde inga extra frågor och frågade inte hur de ville ha den eller vilken data som skulle ingå.

Jag tänkte bara: ”Ja, det kan jag göra.” Jag gjorde rapporten, gav den till direktören och han sa: ”Nej, det här var inte vad jag bad om.” Jag tänkte: ”Åh.” Och han frågade: ”Varför ställde du inte fler kvalificerande frågor om du var osäker?” Och jag tänkte: ”Åh. Jag antar att jag hade kunnat göra det.”

Galen Low: Först och främst applåderar jag det, för det är ganska modigt. Du gick in i det med inställningen att du faktiskt visste vad du skulle göra. Och ja, det kanske inte träffade rätt, men när det gäller att inte fastna i sina egna tankar och faktiskt gå och göra något tycker jag att det är en ganska modig inställning.

Att gå in i en bransch och vara ny i en roll och känna: ”Ja, jag har koll på det här.” Men rättvisans skull: kvalificerande frågor och förtydligande frågor är aldrig fel att ställa när man befinner sig i en miljö där saker görs på ett visst sätt, särskilt i vissa branscher.

Kayla Keizer: Och det förväntades att man skulle ställa frågor. Folk förväntar sig att man ställer fler förtydligande frågor. Så för mig var det en stor lärdom. Nu tänker jag: fråga, fråga.

Galen Low: Nu är det en del av ditt varumärke, faktiskt. Och ja, jag gillar det som en hörnsten i ditt arbetssätt: inte bara att du inte kan veta allt, utan att du förmodligen inte vet de flesta saker på något vis, i någon form, eller hur?

Jag förolämpar inte intelligensen hos någon som lyssnar eller tittar, men det finns helt enkelt så mycket att veta. Hur skulle någon kunna veta allt? Värdet ligger i att ta reda på saker. Jag läste filmvetenskap på universitetet. Jag brukar skämta om att jag inte riktigt lärde mig något värdefullt, men jag lärde mig definitivt att hantera människor och samarbeta, hur man hittar ett svar om man inte vet svaret och sedan hur man formar det till en tanke som man kan omsätta i handling.

Och jag tror att det inte bara gäller personer som har gått på universitet, utan alla. Det är en färdighet som är värd att finslipa i vår tid, helt enkelt eftersom det finns för mycket att veta.

Kayla Keizer: Och du tar upp en mycket viktig poäng. Jag tror att vi ibland underskattar våra mjuka färdigheter.

Om organisationen ville ha en teknisk projektledare med ingenjörsbakgrund hade de anställt en sådan person. Om du är en icke-teknisk projektledare i en teknisk roll är det förmodligen för att du har stark social kompetens. Du är organiserad. De ser värdet i det som ligger utanför den tekniska expertis du bidrar med. Du kan prata med kunder, prata med teamet och motivera teamet, vilket är oerhört viktigt som projektledare – att kunna motivera och leda utan att ha formellt chefsansvar.

Galen Low: Jag tycker att det är en väldigt viktig poäng, för i många av de samtal jag har med människor i min gemenskap är inramningen nästan: ”Vad saknar jag? Vilka färdigheter saknar jag som jag behöver skaffa för att bli teknisk projektledare?” Det läggs inte tillräckligt stor vikt vid att om du ens överväger den rollen har du redan vissa av de här mjuka färdigheterna och kan förmodligen utveckla dem ytterligare. Det är egentligen kärnan i rollen: ledarskapet och kommunikationen.

Kayla Keizer: Ja. Och jag måste säga att jag precis har avslutat en rekrytering. En av sakerna jag letade efter var personer som kunde förklara hur de gick till väga för att hitta information och som kunde förklara hur de lärde sig saker. Jag sökte en projektledare med teknisk inriktning och ställde frågan: ”Vilken metod använder du för att lära dig nya koncept?” De kunde svara och förklara hur de skulle hitta informationen, och det är värdefullt. Du behöver inte veta allt, men om du har en metod och kan förklara din metod för att hitta informationen är det guld värt.

Galen Low: Vad är ditt favoritsvar på det? Eller kanske snarare: hur brukar du själv gå till väga för att hitta svar, särskilt när du och ditt team arbetar med projekt som rör cybersäkerhet, data, integritet och tillgänglighet? Vad är ett bra svar på frågan om hur man tar reda på något man inte vet?

Kayla Keizer: Jag är alltid väldigt nyfiken och försöker alltid göra min egen research som första steg, åtminstone för att få definitioner. Kunna termerna, helt enkelt. Sedan är jag väldigt personlig av mig, så jag tar reda på vem som är expert i teamet och frågar den personen: ”Hej, vill du sätta dig ner med mig i 30 minuter och gå igenom några saker? Kan du hjälpa mig så att jag vet exakt vad du behöver när vi är i nästa kundmöte eller när jag skriver nästa uppgift åt dig?”

Och självklart kommer de att vilja ta sig tid, eftersom du presenterar det som: ”Hur kan jag bli bättre så att jag kan hjälpa dig i slutändan?” Det är värdet för dem. För mig har det fungerat att göra lite research själv och sedan be experterna om hjälp. Du behöver inte titta på 30 timmar av YouTube-videor.

Galen Low: Det är det som är så bra, eller hur? Jag känner vissa personer som säger: ”Jag måste lära mig cybersäkerhet”, som exempel. Och sedan går de nästan så långt att de skulle kunna genomföra en SOC2-efterlevnadsrevision. Då tänker jag: ”Jag tror att du gick lite för långt.” Medan jag verkligen gillar din modell eftersom den är väldigt praktisk.

När det gäller ett projekt för projekt har du inte 30 timmar att sätta dig ner och titta på YouTube. Men det är en mycket kraftfull utbildningsmodell: läs lite på egen hand, var nyfiken på egen hand och prata med någon som vet. Och jag älskar nyansen i att det också finns något i det för dem.

Det är inte bara något du kan använda strategiskt för att bygga förtroende med teamet, eftersom du är nyfiken på vad de gör. Och ärligt talat har projektledare – även tekniska sådana – ett dåligt rykte om sig att bara piska på. ”Jag bryr mig inte om vad som måste göras, du måste göra det senast det här datumet. Prata inte med mig om alla de här akronymerna.”

Att i stället komma in och säga: ”Kan du berätta vad den här akronymen betyder? Det kommer att hjälpa mig.” Och sedan kommer det att hjälpa dem också. Jag tycker att det är ett väldigt kraftfullt värdeerbjudande.

Kayla Keizer: Ja, för det handlar inte bara om att bygga relationer med kunder, utan också om att bygga relationer med teamet. Helt rätt.

Galen Low: Ja, det är som att slå två flugor i en smäll, för att använda en PETA-metafor.

Du sa något tidigare som jag tänkte att vi kunde gå djupare in på. Det handlade inte bara om att förbereda sig inför ett möte tillsammans med teamet, utan ibland om situationer i realtid, under ett möte med kunden. Jag är nyfiken på vad du råder dem att göra om de får en teknisk fråga från en kund eller teammedlem i en sådan situation, men inte vet svaret.

Kayla Keizer: Jag säger alltid till dem att det är okej att säga att man inte vet svaret. Men jag ser till att de vet vem som har svaret. Därför är det viktigt att förstå koncepten och förstå vem som gör vad i teamet: vad är ett frontendproblem, vad är ett backendproblem och vad är ett SEO-problem?

När kunden frågar något som du kanske inte kan svara på kan du säga: ”Du vet vad, jag vet inte. Min person för X, Y och Z i teamet har den informationen. Jag skriver ner det nu och återkommer förmodligen med ett svar inom de närmaste 24 timmarna.” Oroa dig inte, det visar mycket självförtroende. De får en tidsram för när de får informationen och vet vem som har den.

Varför skulle de då bli irriterade över att du inte har svaret just i det ögonblicket?

Galen Low: Och det lyfter faktiskt värdet i din roll. Återigen kan du använda det som en kombination: ”Jag vet inte svaret, men jag vet hur allt fungerar här. Jag känner teamet och vet vem jag ska fråga, eftersom jag förstod din fråga.”

”Jag vet bara inte svaret på den. Mitt jobb är att koppla dig till svaret. Det är en del av det jag gör här – att översätta det åt dig.” Och samtidigt undviker du att förstärka föreställningen att du är mer teknisk än du är eller att du är en allvetande källa för allt.

Det skapar annars en märklig förväntan på vad din roll är. Missförstå mig inte, men har du någon i teamet som är ingenjör eller utvecklare, eller någon som kom in i projektledning från en mer teknisk bakgrund i stället för tvärtom?

Kayla Keizer: Inte direkt. Vi har några som sysslar lite med det, men de är väldigt fokuserade på sin del som utvecklare och på teknisk erfarenhet. Men jag känner att om man kommer från en ingenjörsbakgrund och går in i projektledarvärlden kan man hamna i fällan att inte ställa tillräckligt många frågor och anta kraven eftersom man har för mycket kunskap, nästan. Då styr man oavsiktligt kunden eller projektet i en riktning som kanske inte var rätt, eftersom man gjorde ett antagande i stället för att ställa en fråga. Så jag tror att det kan finnas utmaningar och fallgropar med att ha en teknisk bakgrund och försöka gå över till projektledning.

Ibland kommer jag på mig själv med att göra det, eftersom jag nu vet tillräckligt för att vara farlig. Ibland försöker jag därför, utan att ens inse det, ställa en fråga som styr samtalet i en viss riktning. Då kan en av teammedlemmarna i samtalet säga: ”Åh nej, vi borde inte uttrycka det så.” Då tänker jag: ”Okej, jag förstår.”

Galen Low: Det är en så intressant vändning, för där går kaninhålet, eller åtminstone den typiska vägen från projektledningssidan in i en mer teknisk projektledarroll. Man börjar med att i princip inte kunna någonting och känner sig som en bedragare, utan självförtroende och som om man missar något.

Sedan tar man sig till en punkt där man tänker: ”Jag har faktiskt lärt mig mycket. Jag tror att jag vet svaret nu.” Och ibland kanske det inte är rätt sätt att närma sig saken. Att veta tillräckligt för att vara farlig kan faktiskt bli ett problem på vissa sätt.

Kayla Keizer: Ja.

Galen Low: Hur gör du för att hejda dig när du tänker: ”Jag tror att jag vet svaret, men jag borde nog inte svara, eftersom den här personen borde svara eller eftersom jag borde hämta svaret från dem”?

Kayla Keizer: För mig märks det när jag behöver ge en mer omfattande eller detaljerad förklaring. Jag kan säga: ”Nej, det du ber om är dålig UX.”

Jag kan inte förklara varför det är dålig UX, men jag vet att det är dålig UX. I det ögonblicket tänker jag: ”Okej, nu måste jag fråga eller ta in en av teammedlemmarna.” Jag kan inte ge mer än ett ja- eller nej-svar vid det här laget.

Galen Low: Jag älskar den metoden. ”Jag har en åsikt. Jag kan ge dig ett ja- eller nej-svar, men jag kan inte förklara varför.” Okej, då lämnar jag över den.

Kayla Keizer: Precis.

Galen Low: Vi har pratat en del om mjuka färdigheter, men jag tänkte ändå ställa frågan: är en tekniskt utbildad projektledare kanske bättre lämpad för rollen som teknisk projektledare än en icke-teknisk projektledare?

Men framför allt tror jag att jag behöver fråga: när en projektledare inte är teknisk, vilket värde tillför personen? Vi kan formulera om frågan, eftersom vi har pratat om mjuka färdigheter och liknande. Hur skulle du beskriva det om du försökte få ett jobb som teknisk projektledare men inte har alla plattformscertifieringar och inte kan alla akronymer?

Kayla Keizer: Om du är på en intervju måste du göra din hemläxa och förstå branschen och den teknik som företaget arbetar med. Även om du inte har en djup förståelse har du gjort din research, förberett dig och kan åtminstone prata på en övergripande nivå om vissa koncept.

Du kan också prata om hur du skulle kunna gå djupare eller hur du skulle gå till väga för att lära dig mer, så att du kan underlätta för teamet ännu bättre. För min egen del har det också varit värdefullt att kunna följa processer. Som vi pratade om när det gäller mjuka färdigheter: som projektledare bidrar du också med struktur till projektet.

Vi ser det hela tiden. Det finns inga projektledare inblandade, allt drar åt alla håll och ingenting blir gjort. Att vara en förespråkare för process och förstå de olika stegen från A till B till projektets slut och lansering är en enorm kvalitet som vi glömmer att vi har.

Vi driver projektet. Även om vi inte är tekniska kan vi fortfarande föra projektet framåt.

Galen Low: Jag älskar det. Ja, värdet ligger i att vi skapar struktur. Du tar upp en bra poäng: om du är på intervju för en teknisk projektledarroll hade de bara kallat det en projektledarroll om de inte förväntade sig någon nivå av förståelse.

Så gör din hemläxa. Anta inte bara att du kan säga: ”Jag är bra med människor”, och att det därför är perfekt för rollen. Det finns en avsikt bakom att kalla rollen teknisk projektledare. Det finns en förväntansnivå. Det är god praxis att göra den researchen inför en intervju, för gissa vad? Det är förmodligen det du kommer att göra i jobbet också.

Lite av Kays metod: läs på, skaffa kunskap, prata med någon som är kunnigare och kör sedan igång.

Kayla Keizer: Ja.

Galen Low: Jag kanske ska avrunda med det här. Vi har pratat om teknisk projektledning och hamnat i ett område där du måste vara nyfiken, men inte nödvändigtvis utvecklare. Du behöver inte heller vara djupt teknisk själv. Men om du hade någon i teamet, eller kände någon som var projektledare och funderade på om de skulle fördjupa sin specialisering som teknisk projektledare – med andra ord, om de faktiskt var hungriga på att lära sig mer – vilket råd skulle du ge dem?

Skulle du rekommendera att de skaffar certifieringar som AWS eller kanske går en kurs i webbutveckling? Eller skulle du se det som att du leder dem i fel riktning?

Kayla Keizer: Om de överväger det tycker jag att de ska utvärdera vart de vill ta sin karriär och inom vilken nisch.

Om du till exempel verkligen är intresserad av säkerhet ska du definitivt skaffa certifieringar inom webbsäkerhet och fräscha upp dina kunskaper, så att du kan prata om det och förstå koncepten. Om du verkligen är intresserad av tillgänglighet och vill vara en förespråkare för tillgänglighet, ska du förstå de grundläggande principerna för tillgänglighet och hur man arbetar med dem.

Vi kodar inte. Åtminstone känner jag inte till några projektledare som kodar, så du behöver inte kunna koda. Men om du vill in i en specifik bransch kan det finnas certifieringar för just den branschen som du kan skaffa och fräscha upp dina kunskaper med, så att du kan ta med dem till en intervju.

Galen Low: Ja, jag gillar det, för ibland glömmer jag också att specialisering handlar om att vara specifik. Förstår du vad jag menar? Det kanske vore fel att ha hundra specialiseringar, för då undrar folk: ”Vad är det egentligen du gör?”

Men om du har en djup nisch som du verkligen brinner för och är intresserad av – till exempel cybersäkerhet – kan du säga: ”Jag tycker om projektledning och cybersäkerhet.” När någon anställer eller befordrar dig till en roll vet de vad de får, eftersom du har båda delarna.

Det är något annat än att specialisera sig inom för många saker och se ut som en tusenkonstnär eller få höra att man är överkvalificerad. Egentligen betyder det ofta att det inte ser ut som att du kan bestämma vad du gör eller kommunicera vad som gör dig speciell och annorlunda.

Kayla Keizer: Och jag tror inte att människor inser hur många riktningar man kan ta inom webben, internet och teknik i dag. Jag arbetade inom telekom. Det finns människor som är projektledare inom telekom och det är det de gör. De förstår hårdvaran och hur man sätter upp ett nätverk, och det är deras specialisering.

Om du vill specialisera dig ska du ta reda på vilken bransch du vill arbeta i: cybersäkerhet, telekom, webbutveckling. Det finns så många olika nischer och så många möjligheter.

Galen Low: Jag älskar det.

Kanske ska jag knyta ihop det med början, eftersom vi har pratat om att leda och handleda ett team av tekniska projektledare. Många av de här sakerna lär sig varje enskild teammedlem under arbetets gång. Har ni någon mekanism på Plank eller någon gemenskap där ni kan dela lärdomar under arbetets gång mellan projektledarna?

Kayla Keizer: Ja, jag träffar mitt team ungefär en gång i veckan och vi går igenom olika saker. Men en gång i månaden träffas vi allihop.

Då pratar vi om utmaningar, projektens framsteg och processer. Vi har också en privat Slack-kanal där vi kan vädra våra klagomål. Det är så vi kommunicerar med varandra. Jag har faktiskt använt mycket av DPM-materialet. Jag har gått igenom det tillsammans med en av mina medarbetare för att ge personen en bättre grund eller mer information på ett annat sätt.

Man kan ta en PMP-certifiering eller en CMPM-certifiering, men särskilt inom digitalt arbete kommer man till webbutveckling och förstår inte ens hur det hänger ihop. Att ha det extra innehållet som kan översätta principer till konkreta uppgifter är mycket värdefullt.

Galen Low: Jag är så glad att du använder det. Tack för det. Men du har rätt: det finns så många vägar att ta på webben. På vissa sätt vore det orimligt att anta att en organisation som Project Management Institute skulle kunna skapa den perfekta lösningen som besvarar alla världens frågor.

Vi började med att man inte kan veta allt. Och jag tycker att det är en vacker och nästan poetisk plats att landa på: fördjupa dig där du har passion, intresse och nyfikenhet. Förstå världen du verkar i och ställ frågor. Fortsätt vara nyfiken.

Kayla Keizer: Och jag tycker att det är viktigt att också erkänna var du befinner dig. Om du precis har börjat så har du precis börjat. Ingen förväntar sig att du ska ha tio års erfarenhet på dag ett, och det är okej. Känn dig inte som en bedragare. Var inte nervös. Erkänn var du befinner dig, så möter människor dig där.

Det är något jag påminner mitt team om flera gånger när de känner att de borde ha vetat något. Du är där du är i dag. Om fem eller tio år kommer du att vara på en annan plats och förväntningarna kommer att vara annorlunda.

Galen Low: Jag älskar det. Det är ett fantastiskt råd.

Kay, tack så mycket för att du tog dig tid att prata med mig i dag. Jag har haft väldigt roligt.

Kayla Keizer: Toppen. Tack för att du bjöd in mig.

Galen Low: Ja, det har varit ett nöje. Ett nöje.

Okej allihop, där har ni det. Som alltid: om du vill delta i samtalet med över tusen likasinnade förespråkare för projektledning, kom och gå med i vår gemenskap! Gå till thedpm.com/membership för att läsa mer. Och om du gillade det du hörde i dag får du gärna prenumerera och hålla kontakten på thedigitalprojectmanager.com. Vi hörs nästa gång. Tack för att du lyssnade.