Angående “Kritisera inte något utan att komma med ett bättre förslag själv”
Jag tycker detta är en extremt trasig policy.
Så här ska det funka enligt mig:
- Alla håller ögonen på saker och identifierar problem och flaggar dom för gruppen.
- Man tittar tillsammans på det flaggade problemet och avgör om det faktiskt är ett problem, om man vill hantera det på något sätt.
- Man funderar tillsammans på alternativ för hur man kan hantera/förbättra, spånar fram brett (divergent) olika potentiella lösningar.
- Man identifierar några av förslagen att fördjupa/iterera på (convergent), pekar ut dom som ska ta lead att jobba med det.
- Man itererar, löser, återrapporterar, assignear resurser allteftersom det behövs.
En fara när någon ser ett problem är att dom kan börja jobba på att lösa problemet på egen kammare, kanske utan att ha kompentensen för att lösa det, kanske utan att våga fråga andra om hjälp och ta dom som bollplank. Man jobbar för länge och tar lösningen för långt, utan att etablera en feedbackloop med dom som faktiskt bestämmer eller har kunskap för att hantera problemet. Sedan flaggar dom problemet, och presenterar sin lösning framtagen helt i vakum, och så sågas lösningen för att andra inte fått vara inblandade och lösningen är “helt verklighetsfrånvänd”. Bortslösad mantid och kalendertid som kunde använts bättre.
Skapa en miljö där folk inte sitter och hemlighåller saker dom vet. Där folk vågar säga “Jag ser detta, förstår jag rätt, vad kan vi göra?” utan att själva behöva veta hur man löser något som skapar problem.
Jag tror många företag har gått i konkurs för att de haft en kultur där problem inte flaggas och skickas dit där de kan lösas på riktigt. Det värsta som kan hända är ju att viktiga problem ligger och gror oupptäckta för dom som kanske enkelt kan lösa dom, om de bara får tid tilldelade att tänka på problemet. Och att medarbetare distraherar sig på att gå och tänka på massa andra saker som dom inte vågat rapportera uppåt, spenderar tid på att försöka lösa själva när problemet kanske är tillräckligt allvarligt för att assigna ett helt team på, det är också trasigt.
Saker ska vara kända, även om det inte går att tilldela resurser till att lösa dom direkt. Då har man åtminstone tagit ett medvetet beslut att prioritera något annat.
Exempel: som medarbetare på utvecklingsdelen av vårt företag vill jag att problem som kollegor på supporten ser när dom pratar med våra kunder når mig. Jag vill hellre ha öppna frågor “detta händer och vi lägger mycket tid på detta” så att jag kan gå in med min kompetens och rätta och automatisera och spåra problemet till sin källa i vår mjukvara. Jag vill inte att supporten håller på och tar fram och förbättrar sina processer för att hantera problemet och se till så att allt funkar ändå, jag vill ha bort problemet på riktigt. I många fall har supporten inte en chans att titta ner i vår kodbas och förstå eller föreslå vad som egentligen kan göras, men det är superviktigt att dom får chans att dra i snöret och larma att något skaver.
När jag försöker lyfta något till någon och dom går i försvarsställning och jag får i ansiktet “Men kom med ett bättre förslag själv då!” så trycker jag bara på mer. “Jag ser något du inte ser, eller jag missförstår något som du förstår. Jag ber ju om din hjälp! Låt oss försöka lösa detta tillsammans.”
Men är alla överrens om att det “borde” funka som jag beskriver ovan, så har man åtminstonen en chans att fånga sig själv innan man skjuter ifrån sig.