Idag är jag förbannad därför att...

[SJP]

Ekonomerna behöver väl en motpol för sitt småpåvande i storföretagen.
Jag har alltid sett alla sånhär tendenser, från chefer som måste vara med och peta i allt, till mellanchefer som måste peta i alla chefers jobb, och så vidare upp i hierarkin som att cheferna i valfritt led inte har gjort sitt jävla jobb och anställt kompetent personal, och borde således avskedas för att de är inkompetenta.
Har sagt det ett par gånger till chefer med.
Lyckligtvis är problemet ickeexisterande som konsult, men det är jävligt bakvänt att jag som inhyrd kompetens får större förtroende än de fast anställda.

Ja, det känns väl iofs som att hela poängen med att ta in en konsult är att hyra in en kompetens som man saknar iofs?

 

[Ulvhamne]

Ja, det känns väl iofs som att hela poängen med att ta in en konsult är att hyra in en kompetens som man saknar iofs?

Det kan man ju tycka.
Men i mjukvara är det nästan alltid så att företaget har rätt kompetens redan, men inte litar på de egna utvecklarna. I en del fall är det väl inte helt fel att inte lita på dem (herrejösses vad jag kan raljera om inkompetenta utvecklare) men nästan alltid så hittar jag någon kompetent person på företaget som hade kunnat göra jobbet lika bra som mig.
Och inom programmering är det lite sådär att när du lägger till mer folk tar saker längre tid att få gjorda.

 

[SJP]

Det kan man ju tycka.
Men i mjukvara är det nästan alltid så att företaget har rätt kompetens redan, men inte litar på de egna utvecklarna. I en del fall är det väl inte helt fel att inte lita på dem (herrejösses vad jag kan raljera om inkompetenta utvecklare) men nästan alltid så hittar jag någon kompetent person på företaget som hade kunnat göra jobbet lika bra som mig.
Och inom programmering är det lite sådär att när du lägger till mer folk tar saker längre tid att få gjorda.

Låter helidiotiskt.

 

[Ulvhamne]

Låter helidiotiskt.

Japp!
Jag brukar säga att man kan sparka 90% av folk inom IT och få mer gjort. En stor del är alla mellanchefer, sedan alla inkompetenta sätesvärmare. Och sist den där biten om att fler utvecklare gör att saker tar längre tid.
Men corporate har försökt göra programmering till ett så kallat blue collar job, där alla är utbytbara och kompetens inte är värt något i årtionden nu, med resultatet att all mjukvara konstant blir sämre.

 

[Heaven]

Japp!
Jag brukar säga att man kan sparka 90% av folk inom IT och få mer gjort. En stor del är alla mellanchefer, sedan alla inkompetenta sätesvärmare. Och sist den där biten om att fler utvecklare gör att saker tar längre tid.
Men corporate har försökt göra programmering till ett så kallat blue collar job, där alla är utbytbara och kompetens inte är värt något i årtionden nu, med resultatet att all mjukvara konstant blir sämre.

Förstår frustrationen.

Dessutom har man ofta byggt sin arkitektur och organisation så det nästan alltid krävs inblandning av en massa olika människor (som inte har samma mål) för att få något gjort. Alla känner sig allt mer upptagna och stressade, men inte mycket kommer ut. De som beställer saker trycker dock in saker i högre takt än vad som går att få ut och tycker att det är utvecklingsorganisationen som får lösa det. Detta försöker då utvecklingsorganisationen lösa genom att ta in ännu fler människor och sitta och pussla med headcounts i excelark. Till slut sitter alla och väntar på alla och ingen får något gjort. De som har förmåga att få något gjort lämnar i frustration.

 

[Ulvhamne]

Förstår frustrationen.

Dessutom har man ofta byggt sin arkitektur och organisation så det nästan alltid krävs inblandning av en massa olika människor (som inte har samma mål) för att få något gjort. Alla känner sig allt mer upptagna och stressade, men inte mycket kommer ut. De som beställer saker trycker dock in saker i högre takt än vad som går att få ut och tycker att det är utvecklingsorganisationen som får lösa det. Detta försöker då utvecklingsorganisationen lösa genom att ta in ännu fler människor och sitta och pussla med headcounts i excelark. Till slut sitter alla och väntar på alla och ingen får något gjort. De som har förmåga att få något gjort lämnar i frustration.

Ge mig ett par kompetenta juniorer, en senior, en duktig testare och en kravare och jag kan flytta berg som team på tiotals utvecklare inte löst på ett årtionde.
Och access till beslutsfattare som kan röja undan byråkrati.

 

[Heaven]

View attachment 492583

Ge mig ett par kompetenta juniorer, en senior, en duktig testare och en kravare och jag kan flytta berg som team på tiotals utvecklare inte löst på ett årtionde.
Och access till beslutsfattare som kan röja undan byråkrati.

Exakt så! De mest framgångsrika teamen jag träffat på har haft ungefär detta upplägg.

 

[Ulvhamne]

Exakt så! De mest framgångsrika teamen jag träffat på har haft ungefär detta upplägg.

Det går att sträcka till 8 utvecklare om alla är duktiga, självgående och har förmågan att kommunicera med. Men allt över 8 är bortom brytgränsen, efter det får man bara extra byråkrati, extra onödigt tjatter i kommunikation och informationen dränks ut och det blir massa väntande och inget ansvarstagande.
Plus att de lata jävlarna kan gömma sig i mängden.

 

[Heaven]

Det går att sträcka till 8 utvecklare om alla är duktiga, självgående och har förmågan att kommunicera med. Men allt över 8 är bortom brytgränsen, efter det får man bara extra byråkrati, extra onödigt tjatter i kommunikation och informationen dränks ut och det blir massa väntande och inget ansvarstagande.
Plus att de lata jävlarna kan gömma sig i mängden.

Håller med. Sen kan det finnas ytterligare faktorer som gör att man trots allt behöver skala upp till fler och där frågan är om det då är bättre att utöka teamet eller skapa flera team. Flera små team som samtidigt har starka beroenden till varandra kan ibland vara ännu krångligare än ett stort team. Viktigast av allt är kanske att genom arkitektur, ledarskap osv. göra det möjligt för små team att arbeta självständigt.

 

[Two stroke man]

Nu påminner ni lite om Jonas Birgersson, ni minns från framtidsfabriken.

Det enda riktigt bra jag minns från hans allt snack var att dela upp företaget i grupper på max 16 personer som plutoner helt enkelt. En modell han direkt plockat från det militära, hans enda egentliga meriter var ju att han studerat militärhistoria. Och ett koncept jag köpte helt. Det är helt enkelt så stora grupper kan bli och ändå jobba effektivt tillsammans.

Någon gång ungefär mitt i It-bubblan så såg jag ett föredrag han höll på KTH. Det var mycket militära floskler. Jag vet inte hur många gånger han repeterade att man skulle skydda flankerna. Vet inte om han glömde göra det själv sen.

 

[Ulvhamne]

Nu påminner ni lite om Jonas Birgersson, ni minns från framtidsfabriken.

Det enda riktigt bra jag minns från hans allt snack var att dela upp företaget i grupper på max 16 personer som plutoner helt enkelt. En modell han direkt plockat från det militära, hans enda egentliga meriter var ju att han studerat militärhistoria. Och ett koncept jag köpte helt. Det är helt enkelt så stora grupper kan bli och ändå jobba effektivt tillsammans.

Någon gång ungefär mitt i It-bubblan så såg jag ett föredrag han höll på KTH. Det var mycket militära floskler. Jag vet inte hur många gånger han repeterade att man skulle skydda flankerna. Vet inte om han glömde göra det själv sen.

Det är inte ens hans idéer, det har varit väl dokumenterat sedan 70-80-talet att det är så det fungerar med mjukvaruutveckling. Men folk som pluggat mellanchef på universitet verkar inte få lära sig det.

Jag sträcker mitt organisatoriska filosoferande längre än så, och säger att man inte ska ha en militär hierarki med lager av beslutsfattare, utan istä'llet anställa folk som kan jobba på sitt eget hörn och samarbeta med andra team utan gnissel och gnäll, sedan kan ett eller två team vara strategiskt ansvariga, men inte överordnade andra team.

 

[Heaven]

Nu påminner ni lite om Jonas Birgersson, ni minns från framtidsfabriken.

Det enda riktigt bra jag minns från hans allt snack var att dela upp företaget i grupper på max 16 personer som plutoner helt enkelt. En modell han direkt plockat från det militära, hans enda egentliga meriter var ju att han studerat militärhistoria. Och ett koncept jag köpte helt. Det är helt enkelt så stora grupper kan bli och ändå jobba effektivt tillsammans.

Någon gång ungefär mitt i It-bubblan så såg jag ett föredrag han höll på KTH. Det var mycket militära floskler. Jag vet inte hur många gånger han repeterade att man skulle skydda flankerna. Vet inte om han glömde göra det själv sen.

Vet inte hur mycket det finns att lära av just Birgersson, men desto mer att lära från militärhistoria. Ingen slump att ledare för de mest framgångsrika företagen ofta inspirerats av Sun Tzu. Militären har den hårda vägen och under mycket lång tid lärt sig vad som fungerar när det gäller gruppstorlek osv. Även uppdragstaktiken (inom NATO kallas det Mission Command - att ge teamet ett uppdrag och låta dem självständigt lösa uppgiften utan detaljstyrning) som är en preussisk 1800-talsuppfinning av generalerna von Clausewitz och von Moltke som bl.a. använts framgångsrikt av Ukraina mot Ryssland.

Vad gäller gruppstorlek finns det även relevant forskning som säger ungefär samma sak av bl.a. Robin Dunbar som studerat gruppstorlekar under mänsklighetens utveckling.

Problemet är inte att det saknas forskning om detta, utan att många chefer inte känner till den eller bryr sig om den utan försöker styra och strukturera sina organisationer enligt principer som mer verkar bygga på pseudovetenskap och magiskt tänkande eller helt utan principer. Eller så har de gått en MBA-utbildning och fått lära sig att management handlar om Excel-ark och snygga Powerpointbilder. Men vad många inte fattar är att utveckling inte går att hantera som en stålfabrik på 1800-talet.

 

[SJP]

Jag har inte pillat så mycket med kodning, men tillräckligt för att kunna tänka mig att det blir bra jobbigt med många kockar.
Sedan vill man ju ha tillräckligt med folk ändå att en kodare kan syssla med en grej istället för att hålla på med 17 parallellt.

Det där med att räkna huvuden är jävligt farligt. Jag hade en chef en gång i tiden som flippade på att vi inte hann med, för vi "var ju två personer fler än tidigare". -ja men att de två med 10-15 års erfarenhet var ur dörren innan de fyra rätt ur högstadiet dök upp, så att de inte hade någon att lära sig av, det förstod denne inte att kunde vara ett problem. Man måste se till vem man har på plats, och vad de får gjort, antal anställda är ofta inte relaterat.

Eller som en tidigare VD kläckte ur sig; -"Det där kan man ju träna vilken schimpans som helst att göra!"
Nej, han kunde inte själv arbetsuppgiften i fråga.....

 

[Ulvhamne]

Vet inte hur mycket det finns att lära av just Birgersson, men desto mer att lära från militärhistoria. Ingen slump att ledare för de mest framgångsrika företagen ofta inspirerats av Sun Tzu. Militären har den hårda vägen och under mycket lång tid lärt sig vad som fungerar när det gäller gruppstorlek osv. Även uppdragstaktiken (inom NATO kallas det Mission Command - att ge teamet ett uppdrag och låta dem självständigt lösa uppgiften utan detaljstyrning) som är en preussisk 1800-talsuppfinning av generalerna von Clausewitz och von Moltke som bl.a. använts framgångsrikt av Ukraina mot Ryssland.

Vad gäller gruppstorlek finns det även relevant forskning som säger ungefär samma sak av bl.a. Robin Dunbar som studerat gruppstorlekar under mänsklighetens utveckling.

Problemet är inte att det saknas forskning om detta, utan att många chefer inte känner till den eller bryr sig om den utan försöker styra och strukturera sina organisationer enligt principer som mer verkar bygga på pseudovetenskap och magiskt tänkande eller helt utan principer. Eller så har de gått en MBA-utbildning och fått lära sig att management handlar om Excel-ark och snygga Powerpointbilder. Men vad många inte fattar är att utveckling inte går att hantera som en stålfabrik på 1800-talet.

Chefer bygger viktighet med storlek på siffran för hur många de chefar över, vad jag kan se. Det är det enda som förklarar att alla avdelningar överallt alltid vill växa. Det och det där med att chefsutbildningar inte tar upp förståelse för ämnet som det ska chefas i, snarare utbildas de i att det är tvärtom helt irrelevant.
Jag har inget emot chefer som inte kan ämnet, sålänge som chefen förstår att chefen inte är en ledare, utan en resurs som de som ska göra jobbet kan använda för att få irritationsmoment uppstädade. När jag får en sån chef blir jag skitglad.

 

[Ulvhamne]

Jag har inte pillat så mycket med kodning, men tillräckligt för att kunna tänka mig att det blir bra jobbigt med många kockar.
Sedan vill man ju ha tillräckligt med folk ändå att en kodare kan syssla med en grej istället för att hålla på med 17 parallellt.

Det kan man lösa genom att dela upp mjukvaran i mindre delar som var för sig kan arbetas separat med, men det går itne att lösa med att kasta mer folk på samma mjukvara.
Ett annat skoj problem med när man delar upp mjukvaran är att man då måste specificera kontaktytorna mellan de delar som ska samarbeta, och det är mycket svårare än vad alla tror att göra det bra.
Så, ha så få som möjligt, och låt dem jobba på.

En del utvecklare skiner när de har 17 olika jobb samtidigt (jag är definitivt inte en av dem), och de är extremt värdefulla för ett team om man kan hitta en sån som dessutom slutför saker.

Det där med att räkna huvuden är jävligt farligt. Jag hade en chef en gång i tiden som flippade på att vi inte hann med, för vi "var ju två personer fler än tidigare". -ja men att de två med 10-15 års erfarenhet var ur dörren innan de fyra rätt ur högstadiet dök upp, så att de inte hade någon att lära sig av, det förstod denne inte att kunde vara ett problem. Man måste se till vem man har på plats, och vad de får gjort, antal anställda är ofta inte relaterat.

Eller som en tidigare VD kläckte ur sig; -"Det där kan man ju träna vilken schimpans som helst att göra!"
Nej, han kunde inte själv arbetsuppgiften i fråga.....

Ja, det där med kompetens förnekas ju så ofta och mycket som möjligt. Jag skulle kunna skylla lite på att facket också är med och bidrar till det problemet i sann socialistist anda där alla ska vara lika mycket värda. Men vi behöver itne starta en ny diskussion om facket.

 

[Two stroke man]

Det är inte ens hans idéer, det har varit väl dokumenterat sedan 70-80-talet att det är så det fungerar med mjukvaruutveckling. Men folk som pluggat mellanchef på universitet verkar inte få lära sig det.

Jag sträcker mitt organisatoriska filosoferande längre än så, och säger att man inte ska ha en militär hierarki med lager av beslutsfattare, utan istä'llet anställa folk som kan jobba på sitt eget hörn och samarbeta med andra team utan gnissel och gnäll, sedan kan ett eller två team vara strategiskt ansvariga, men inte överordnade andra team.

Ja, även om han skulle ha varit den som tagit iden från militären så vore det ju per definition inte hans ide utan militärens.

Jag tror man har mycket att lära från militären just här. Även militären har ju de där personerna som jobbar "i sitt eget hörn" med sin uppgift men dom tillhör alltid en pluton. Jag själv var tex MC-ordonnans men tillhörde ju ändå en pluton även om jag jobbade ensam.
Och det behövs alltid chefer som styr och delegerar ut jobben, men lagom många chefer.
När det blir fler än 16 personer så delar man upp dom i två grupper med en gruppchef i vardera grupp.

 

[Heaven]

Kort sagt så kan man väl säga att ledarskap i de här sammanhangen handlar mycket om att kunna skapa en tydlig bild av VAD som skall uppnås och VARFÖR och att skapa förutsättningar för människor att uppnå detta genom att själva komma fram till HUR. Många chefer gör tvärtom. De försöker detaljstyra hur jobbet skall göras och det är högst oklart vad det skall syfta till. Det kanske funkar på McDonalds, men inte i yrken som kräver kunskap och där de som gör jobbet ofta har bättre kunskap om hur jobbet utförs än vad chefen har.

 

[Kratoz]

Jag såg ett föredrag med Birgersson för länge sedan.
En sak han nämnde var att ett "Ja" för proscessen/organisationen/företaget framåt medans ett "Nej" alltid haltar/stoppar detsamma.
Därför behövde man inte argumentera för ett "Ja" men alltid argumentera för ett "Nej" i hans organisation.
Jag gillade den idén.

Jobbade på Banverket på den tiden och där var det precis tvärt om...

 

[Two stroke man]

Jag såg ett föredrag med Birgersson för länge sedan.
En sak han nämnde var att ett "Ja" för proscessen/organisationen/företaget framåt medans ett "Nej" alltid haltar/stoppar detsamma.
Därför behövde man inte argumentera för ett "Ja" men alltid argumentera för ett "Nej" i hans organisation.
Jag gillade den idén.

Jobbade på Banverket på den tiden och där var det precis tvärt om...

Så gick det ju som det gick också med Framfab.

 

[GuW]

Så gick det ju som det gick också med Framfab.

Ska vi konkursa firman? JA!