Fordi de fleste virksomheder håndterer initiativ til ikke-kerneartikler dårligt

De fleste mennesker i et nyt job tager initiativ en eller to gange og stopper derefter, fordi de fik dårlige resultater. Jeg vil hævde, at initiativ kun belønnes under nicheforhold i de fleste virksomheder.

1. Du rørte ved det, så hvis noget går galt, er det din skyld.

Virksomheder har denne dårlige vane at dybest set ønsker at gøre ethvert initiativ selvstændigt og ønsker at udskyde risikoen. Så snart noget går galt, bebrejder de den person, der rørte ved det, selvom vedkommendes handlinger ikke havde noget at gøre med, hvorfor noget gik galt.

Nærhed er ofte 90% af skylden.

Hvordan fungerer problemer i din virksomhed? Er det den, der sidst rørte ved et system eller sendte den sidste e-mail, der blev ramt med en pind?

2. Mange ting, der skal gøres, straffes af dårlige systemer.

Jeg kender en fyr, der brugte masser af tid på at blive ekspert på visse ældre systemer i hans firma. Han gik med at forstå koden, finde de grundlæggende årsager til fejl og var villig til at arbejde entusiastisk på crusty gammel kode, der var blevet hacket sammen af ​​over et årti af udviklere.

Han blev belønnet med ikke at få en hæve, fordi han ikke bidrog til nye projekter, så ingen vidste, hvad hans værdi var, og en ny manager ankom, der ikke havde nogen idé om, hvad han gjorde, bortset fra "at holde gamle ting i gang." Var han i stand til at komme på nye projekter? Nej, da han var blevet fremragende til at rette de gamle projekter, så alt det arbejde blev tildelt ham.

Belønnes ekspertise i opdatering / vedligeholdelse hos din organisation? Eller bryr folk sig mere om dem, der arbejder med de prangende nye ting?

3. Mange styringssystemer sletter ikke-klientdrevet arbejde.

Ethvert system, der primært måler projektfremskridt og succes på baggrund af, hvad slutbrugeren ser (de fleste ikke-rene tekniske projekter) er en projektledelsesmetodologi, der er tilbøjelig til at skubbe alt, som brugeren ikke kan se til side.

For eksempel bruger min organisation Scrum. Hvad ledelse / produkt ejere ser er Scrum-taskboardet. De eneste ting der er dem, der går på projektet. Hvis det ikke er på procesbordet, sker der aldrig noget med det. For eksempel har vores testløber været nede i flere måneder. Medmindre vi finder en uge, hvor der ikke er noget at gøre, og ikke højere op vil have funktioner bygget, bliver det aldrig løst. Hvorfor? Hvis vi bruger for meget tid, og det forsinker en funktion, mister vi tempoet.

Trænger noget andet ud af alt det arbejde, du vil have dem til at gøre? Opdatering af biblioteker er en stor og rodet opgave. Jeg ville ikke forpligte mig til det uden tidligere afsat tid. Samme med bugs. Disse ting skal budgetteres og tildeles tid, forhåbentlig ikke fast på siden.

4. "Fremragende. Her er mere af nøjagtigt det samme arbejde. "

En god ven af ​​mig automatiserede hele sit rapporteringsjob ved hjælp af SQL. Han fortalte derefter sin manager. Hans manager ansatte bare ikke det andet praktikantjob og gav det til min ven, hvor det var den samme manuelle rapportering.

Den gamle automatisering "brød", og han brugte resten af ​​samarbejdsperioden på at gøre intet andet end at lære datalogi og anvende stipendier. Der var ingen værdi at gøre noget ud over at indsamle en lønningskasse.

5. De mangler tillid til ledelsen.

Denne historie er faktisk fra i går. Nogle ledere bliver gale, når problemer bringes til dem. En ven kender en på et andet hold, der vil skrige på alle, der giver hende et problem mere, end han havde planlagt at håndtere den dag.

Du gør det en gang, og du vil tilbringe de næste 6 måneder med, at dit personale ikke er i stand til at håndtere problemer, fordi de er bekymrede for, at du bliver sur og dermed skjuler dårlige nyheder eller problemer, som de ikke straks kan give en løsning til.

Det firma mistede lige en større klient, fordi de ikke kunne levere en funktion i tide på grund af manglende ressourcer. Holdet nægtede at fortælle manager om forsinkelsen på grund af hendes korte sikring. Måske er dine teammedlemmer ikke i stand til at løse problemerne selv, men har ikke tilstrækkelig tro på, at du vil hjælpe dem.

Alt i alt skal folk gøre det rigtige. Stærk > Men i de fleste virksomheder er der stærke incitamenter til ikke at være ansvarlig for visse ubehagelige opgaver eller ignorere ting, der går galt.

Dette er et meget bredt spørgsmål, jeg vil forsøge at give et bredt svar.

Der er kun meget få mennesker, der ikke iboende motiverede til at udføre et godt stykke arbejde, uanset deres job er. Jeg har mødt nøjagtigt en i hele mit liv, og den person var så ikke interesseret i deres (eller noget) job, at de bestemt ikke ville være på SE, og ikke læse en reddit, der har ordet "job" i det eller endda gør noget som en hobby, der er tæt på deres job.

Så noget tog initiativet ud af dit team. Noget lavet dem vender ryggen og er ligeglad. Det meste af tiden er det uklare noget den måde, de styres på. Uanset om det er systemet, der stinker eller lederens personlighed eller begge dele, har noget lært dem at det ikke er værd at vise initiativ.

Ingen står op om morgenen og tænker "i dag , lad os suge på mit job ". Mange rejser sig måske og planlægger at gøre det minimum, de kan slippe af med og stadig få betalt, men selv inden for dette minimum, alt andet lige, vil de hellere gøre et godt stykke arbejde end et dårligt.

Så der er sket noget i fortiden, der lader dit team tænke, at de hellere ikke bryr sig om end at passe på og få konsekvenserne. ens job er til alles fordel.

Det kan tage et stykke tid, selvom du gør det rigtigt. Tillid kommer ikke tilbage om natten.

Det er muligt, at din kode har lidt for meget af teknisk gæld, at dit team har besluttet, at det bare ikke er det værd. Som hvis du har et program, der bruger Java 4 med SOAP-slutpunkter, er dit team sandsynligvis ikke interesseret i at udføre opgraderingen til Java 12 og skifte til REST "bare fordi". Denne type ting er MEGET arbejde og skal styres ordentligt og afgrænses.

Ligeledes, hvis din applikation har for mange indbyrdes afhængigheder, bliver bug fixing kompliceret. Hvad hvis du "retter" en "bug", men så viser det sig, at "bug" faktisk var en "funktion", der blev annonceret for dine forbrugere, og dine forbrugere har bygget deres kode på baggrund af den "bug"? Nu er du gået og brudt andres kode. Dette gælder, selvom dine forbrugere er dig selv; nu har du "rettet" en "bug" i din applikation, men "brudt" måske 5-10 andre af dine egne applikationer, så hvad laver du nu? Dette er grunden til at rette bugs meget omhyggeligt i ældre systemer af virkelig enhver meningsfuld størrelse, og hvorfor du ikke bare "gør det" uden at scope og overveje det.

Du bør opmuntre dit team til at påpeg problemer, når de ser dem, såsom teknisk gæld og bugs, og opret billetter i dit bagud for at løse disse problemer. Men tilfældigt at "rette" ting uden at overveje virkningen er ikke en god ide for et system af ikke-stor størrelse.

Dette er for bredt af et spørgsmål til at besvare her, og vi er de forkerte mennesker til at besvare det.

I stedet er det tid til at grave i historien og psykologien for dette team. Jeg anbefaler at bringe det op en efter en med medlemmer af teamet og spørge dem hvorfor denne adfærd sker. Du kan opleve, at der er langvarige personlighedsproblemer eller tidligere ledelsesproblemer. Du siger, at du er et par måneder inde i jobbet, hvilket betyder, at der var en leder forud for dig. Reagerer teammedlemmer stadig på lederens opførsel?

For det andet skal spørgsmålet om prioriteter rejses internt. Der kan være gyldige forretningsårsager til at skubbe nogle fejlrettelser og opdateringer ud i årevis. Jeg anbefaler at holde styr på disse problemer, men find ud af, hvad forretningsprioriteterne er, inden du laver et stort problem med en enkelt fejl eller opdatering.

For det tredje, når du først har en idé om hvorfor, så tag problem op til holdet i teammøder som et problem for holdet at løse. Dette kan være et "make or break" -problem for holdet. I hvilket tilfælde skal holdet løse dette, ikke dig alene. Det kan være, at hvis holdet ikke er villig til at løse dette problem, så bliver teamet udskiftet - enten af ​​dig eller din afløser, når du ikke har fået holdet til at løse dette.