Lad min AI ringe til din AI.

tirsdag den 16. april 2024

Jeg beskæftiger mig faktisk sjældent med de popkulturelle facetter af min branche, men jeg går da op i massefænomener, fordi jeg finder psykologien og incitamenterne bag dem interessante, og hvordan disse fænomener har det med at påvirke en form for konsensus selvom denne er baseret på noget jeg ikke helt kan kvalificere.

Jeg vil godt tage på mig at jeg ikke er særlig klog og jeg vil også acceptere, at mit sind vil gøre meget for at forsvare sig selv omkring det faktum, fordi ellers ville jeg pludselig føle mig mindre værd og det kan menneskets hjerne ikke rigtig lide.

Disse forhold inden i mig gælder ikke bare teknologi, det gælder også politik, sejlads og kultur.

Hvis man virkelig gerne vil forstå noget, er det min holdning, at den bedste mulighed er, at man skal forsøge at ændre det, man ønsker at forstå. Det er for eksempel sådan, store dele af videnskaben fungerer: Man tester sine hypoteser, validerer sine resultater og derefter undersøger man, om de understøttes af uafhængig evidens og om de fører til nye verificerbare teorier eller love.

Det har de fleste naturligvis hverken tid eller mod på. Min ringe formodning må være at vi nok havde været et lidt andet sted, og brugt vores samlede kollektive energi en smule anderledes, havde vi været bedre udviklet som mennesker. Men det er vi ikke. Og det er en af skuffelserne ved menneskesheden. Og det er den øjensynelige og fuldstændigt klare retning vi tager - se historien gentage sig selv overalt du kigger hen - som langt inden vi vælger den retning ikke bare er fjollet og dum, men ikke uden for forventningen af hvad vi rent faktisk formår.

Heldigvis findes der mennesker som er klogere end mig og dig, og som har viet dele af deres liv til at studere en vis form for progression, og hvordan vi kommer videre fra et stadie til et andet. Det er f.eks. sådan noget som videnskabskvinder og mænd går op i. Det skal vi andre mindre begavede naturligvis støtte op omkring fordi uden dem var vi mindre end vi er idag.

Bevares, der findes selvfølgelig også masser af pseudo-videnskabsfolk og holdninger fra disse, som er meget nemmere at forstå end det de rigtige vidensskabsfolk kommunikere, fordi pseudo-folket formår at kommunikerer omkring noget komplekst, der er i virkeligheden er endnu mere komplekst end også de forstår.

Jeg er ikke engang klog til at være pseudo-videnskabsmand, til tider ikke engang menneskelig, så i må nøjes med min ringe holdning.

Men heldigvis kan jeg læse. Og historiebøgerne kan naturligvis også give os en masse indsigt.

Leon Festinger skriver i sin bog fra 1957 "A Theory of Cognitive Dissonance" bl.a. således:

“A man with a conviction is a hard man to change. Tell him you disagree and he turns away. Show him facts or figures and he questions your sources. Appeal to logic and he fails to see your point.”

Forståelsen af AI er i min optik et glimrende eksempel på Leon Festingers udsagn. Her har vi muligvis med et massefænomen at gøre, hvor det er gætterier, gentagelser og menneskets forunderlige tro på, at når vi har oplevet noget progression et sted, så må den da også fortsætte i nogenlunde samme hastighed som den allerede har været fremskyndet med (Læs kapitel 10, "The Role of Social Support: Data on Mass Phenomena").

Lokkefugle og NP-hard udfordringer.

(Hvis et problem er NP-hard, tyder det generelt på, at der ikke er nogen kendt effektiv måde at finde en løsning, der fungerer for alle mulige tilfælde. Dette gør disse problemer særligt udfordrende og betydningsfulde i forskning, da løsning af dem eller endda forbedring af, hvordan vi griber dem an, kan have stor indvirkning på forskellige områder inden for videnskab og engineering.)

Iris van Rooij er "Professor of Computational Cognitive Science" hos Radboud Universitet i Nijmegen, og har bl.a. været forfatter til nogle interessante artikler, som tager udgangspunkt i spændet mellem det menneskelige kognitive og den nutidige teknologiske fremdrift omkring såkaldt AI.

Denne artikel "Reclaiming AI as a theoretical tool for cognitive science" har mere end et par indsigtsfulde forklaringer, som forsøger at gøre et par ting rimelig tydelige for dem, der befinder sig i Leon Festingers psykologiske teori omkring "Show him facts or figures and he questions your sources".

Men lad mig alligevel bruge noget tid på at fremføre et par ting fra Iris' forfatterskab.

"...This means that any factual AI systems created in the short-run are at best decoys. When we think these systems capture something deep about ourselves and our thinking, we induce distorted and impoverished images of ourselves and our cognition."

Nå for pokker, så vores ringe kognitive forståelse af hvad der foregår spejler sig i de systemer vi bygger. Who would have thought.

Jeg kan sagtens forstå, folk falder på halen over en statistisk model, der gætter på, hvad den skal svare på et spørgsmål. Det er nemt, det går stærkt, det giver et resultat. Det taler også direkte ind i tidsånden, hvor kvantitet – som ihverfald er udbredt og trives fint i den professionelle teknologiindustri – er vigtigere end at skabe fundamentalt stabile innovationer samt organisationer, der kan leve i mange år.

Inden jeg fortsætter ud af den kvantitets-tangent, så er her et uddrag fra Iris' medforfatterskab fra artiklen ovenover. Du læser sikkert ikke artiklen, fordi du mener du allerede har styr på det, men prøv at læse den, den er god.

Jeg siger ikke Iris har ret. Jeg siger bare at nogle videnskabspersoner har brugt tid på at validere nogle hypoteser og deres resultater ser interessante ud.

Jeg har mennesker omkring mig, som arbejder for virksomheder, der på en eller anden måde forsøger at retfærdiggøre brugen af millioner af kroner på, at AI skal gøre deres eller deres kunders forretning mere værdifuld. Jeg har bare ikke set skyggen af pålidelighed, hvad deres indsats angår.

Men lige præcis det handler ikke så meget om AI, det handler nok mere om, at "Software stadigvæk bliver bygget på antagelser, anekdoter, idolisering og af hierarkiets prestige."

Nogle af os ved godt, problemet ikke er AI.

Peter Hunt Welch har skrevet en sjov, men også rammende rigtig essay med titlen "AI is not the problem".

"...Even if 50,000 of us just got fired, there are tech entrepreneurs pouring out of Stanford ready to borrow money from their parents and develop fresh methodologies for tanking the economy. With few bumps, the last two decades have enshrined software engineering as the career immune to the cataclysmic shocks it creates in the world at large."

Han fortsætter

"ChatGPT was the first hint of a crack in the fortress. Could we, too, be devalued due to technology? No."

Og herefter fortæller Peter så hvorfor han ikke tror på, at os der er professionelle IT-folk bliver arbejdsløse; "Actual use of ChatGPT for articles or essays or code will produce more of the content that made its output subpar, and achieve little besides accelerating the homogenization of mediocrity."

Middelmådighed er udmærket strategi hvis du skal brute-force dig igennem. Personligt tvivler jeg bare på at det er innovation der er gemt i den.

Det er først i afsnittet omkring DALL-E, han folder sig lidt mere ud i en retning, jeg holder af, fordi jeg heller ikke kan se mig fri for den kognitive dissonans, og hans evne til at overbevise mig, acceptere jeg som en brist i min egen psykologiske verden.

"Computers have been generating art in some fashion for ages, but now it looks like human art. I never worried about this in terms of art because art is about expression and communication. It is inextricably bound up in the history and philosophy of itself and what it means to be human."

Og næste paragraf synes jeg endnu mere om.

"Unfortunately, there’s that certain sector of the population for whom art is a commodity for shallow consumption, accompanied by an industry happy to sell at scale. In this context, art is not expression: art is packaging. Nobody wants to pay premium fees for packaging, and now nobody will."

Prøv at tage den en gang til også erstat "art" med det, du laver.

"Unfortunately, there’s that certain sector of the population for whom MUSIC is a commodity for shallow consumption, accompanied by an industry happy to sell at scale. In this context, MUSIC is not expression: MUSIC is packaging. Nobody wants to pay premium fees for packaging, and now nobody will."

Det udsagn gælder også programmøren, forfatteren, fotografen, psykologen, lægen, kokken, pornostjernen, politikeren, din hund og den studerende. Og ikke mindst dine børn. Hvis du ikke står for noget, er det nemt at falde for det meste. Kvaliteten får ikke lov at spirre i et rum hvor presset for kvantitet er størst.

Og I en verden, der helliger sig kvantitet og hurtige løsninger, er der mere på spil, end vi lige skulle tro. Men som jeg skrev tidligere, som mennesker er vi kollektivt ikke kloge nok til acceptere vores egne begrænsninger.

"Suppose an individual believes something with a whole heart; suppose further a commitment to this belief, suppose irrevocable actions have been taken because of it; finally, suppose evidence, unequivocal and undeniable evidence, that the belief is wrong: what will happen?" - Leon Festinger, A Social and Psychological Study of a Modern Group that Predicted the Destruction of the World.

Polpetta compileren på stranden i Mondello.

tirsdag den 2. april 2024

Vi var ankommet til Palermo om aftenen. Det var sensommer. Det dunkle orange gadelys drev af murene, de sprækkede brune og grå facader, udhakket og solmørnede, fortalte hemmeligheder fra de sidste århundreder. Varmen imellem dem var intens. Lige fra arbejdsfolkets stemme til kvindernes diskussioner på de små balkoner. Der hænger altid tingeltangel fra de skide vinduer, tænkte jeg, og den stakkels jomfru syntes ikke at kunne få fred fra en andens jomfrus øjne.

Hotellet, vi var tjekket ind på, var bestyret og drevet af nigerianske bådflygtninge. De var drevet i land på Lampedusa og derfra fundet til Sicilien. Det var et æstetisk flot hotel, men en forretning. Æstetik og forretning. Det harmonerer sjældent, men de rige kan ikke se forskel.

Bådflygtningene talte bedre italiensk end dem, der var født med italiensk i passet. De var blevet stolte italienere. Mon ikke, tænkte jeg, at det kræver en naturlig intelligens og et dygtigt menneske i den anden ende at lykkedes. Historien på Sicilien er, at der altid har været mange forskellige religioner og baggrunde. Historien oppe nordpå er, de er bange for forandringen. Et dygtigt menneske i den anden ende.

De fik mig til at føle mig mere fattig. Lysende øjne kiggede på mig, og jeg vidste godt, at jeg et eller andet sted ikke var i stand til at fremføre den samme bevisbyrde som de bar rundt på.

Og de var ikke engang blevet sindssyge. Sikke en bedrift, tænkte jeg. De fortjente det pludseligt mere end os andre. Når du aldrig har mistet noget, sagde jeg til min kompagnon, bliver du aldrig i stand til rigtig at vide, hvad du har.

Jeg ringede til Matteo og fortalte om vores ankomst og hvor vi var i byen. Jeg bad ham stille, når han havde muligheden, fordi som sagnet går, er ethvert sted mere værd med en lokal som dirigent. Det gjorde han så, som et italiensk urværk gør bedst. Så vi gik bare selv ud i aftenen.

Vi forlod hotellet og vandrede mod Monte di Pietà. Duft af sandsten og en fortagende varme blandet med høje stemmer og kropslige fagter. Hestevogne og blæseorkestre var ved at lukke aftensolen helt ned, og temperaturen føltes mere bleg. Vi havde været i solen i flere måneder ombord på Rubin, så vi mærkede kulden fra de varme dage på samme måde som de indfødte. Sejladsen hertil havde været helt rolig, og de små øjeblikke for sig selv var stadig den vigtigste valuta. Scirocco-vinden, bevares.

Nu sad vi her under et Peroni-telt og drak Marsala, og jeg glædede mig over grunden til, vi faktisk var ankommet. Når man er på ferie, under institutionen, i de 7 uger man nu råder over, udebliver de lærerige stunder. Der skal mindst 2 måneder non-stop til for at nærme sig en fordybning. Ikke så underligt, de dumme bliver dummere, og de kloge bliver klogere.

Historien havde udspillet sig nogle år forinden, længere nordpå. Vi kom altid nordpå i enten maj eller september, når de værste ryk af turister var overstået, når havnepriserne var overkommelige. Vi er ikke fattige, men vi har bare ingen penge.

På et vinotek ved navn Nebraska lidt udenfor Camaiore sad vi og spiste og drak kold rødvin.

Her gik historien iblandt nogle tidligere italienske kolleger - som jeg havde hjulpet med nogle knap så dogmatiske tekniske ceremonier, og jeg havde forsøgt at lære dem en smule om processernes kontekst i forbindelse med, hvor i et software-forløb man befinder sig. Det var alt sammen i forbindelse med et stykke software til en industri-protokol og endnu en abstraktion ovenpå en ligegyldig innovation, der i sidste ende alligevel handlede om konkurrence og hverken solidaritet eller samarbejde.

Men på stranden i Mondello, lidt udenfor Palermo, fandtes en restaurantejer, som grillede blæksprutter på åben ild, og hvis søn havde lavet restaurantens "kasseapparat". Noget med en egenudviklet compiler og et lille sprog, som efterfølgende gjorde det muligt at afvikle et program ovenpå en Intel 4040-chip. Han havde i hvert fald opkaldt compileren "Polpetta" efter sin mor (man kan ikke hedde Polpetta). Ingen vidste, hvad drengen hed. Men faren hed Piero.

Historien var god. Den blev også fortalt godt. Det hører sig alligevel til sjældenhederne, tænkte jeg, at nogen kan fortælle historier om tekniske bedrifter, uden at fortælleren selv finder fortællingen værende noget af det vigtigste andre skal begaves med. Folk og deres arbejde, tænkte jeg, de er begravet i lyserødt fór, men hvis de kiggede op, bare et par dage, se, at der faktisk også var verdner af azurblåt.

Den aften sad vi med cikaderne på repeat på Nebraska i Camaiore, efter en tur på den offentlige strand ude bagved pinjeskoven i Viareggio. Jeg var kommet på Nebraska, siden jeg havde været lille barn, og nu var det Stefano og ikke den gamle ejer Giuseppe, der fortalte historier. Giuseppe havde smidt folk ud, hvis de stillede for mange spørgsmål til mulighederne eller ville have salt til maden.

Historien om restauranten i Mondello, der var blevet kendt af de lokale for et "kasseapparat", som kunne prutte om prisen, men mindst ligeså meget for drengen, som havde bygget den. Noget med, at den betalende gæst selv skulle stå med maskinen i hånden og taste de priser, som stod på regningen, og dernæst kunne selvsamme trykke på en tast, som enten ville få maskinen til at forøge eller mindske prisen. Og alt sammen ville ske, fordi en ung drengs bedrifter og hans ungdommelige udvikling af en compiler til en chip. Drengens far havde været så glad for sønnens passion og hans iver, at den absolut måtte bruges i restauranten.

Jeg vågnede lidt op igen. Fysisk i Palermo.

Vi bestilte mere vin oppe fra vulkanen. Den har et udtryk af splittelse og menneskets ubetydelige vandren i naturen, når du står oppe i højderne og ser den forstenede lava, der tårner sig op over dig. Fuldstændig sort. Men Nerello Mascalese er alt andet end det. Masser af liv. Tænk nogle gaver at få fra sådan et sted. Gaver, man kan drikke.

Matteo var ankommet og havde fundet ud af, at vi skulle mod havnen og spise kalvetunge og derefter spille kort på den anden side af gaden. Ovre hos de gamle. "Fantastisk," sagde vi alle til hinanden og gik smilende hånd i hånd ned mod vandet.

Piero stod i hjørnet af ude-køkkenet på hjørnet af Via Delfini og flåede blæksprutter. Der var mange blæksprutter. De er klogere end de fleste mennesker, tænkte jeg. Derinde bagved vidste jeg, Polpetta eksisterede et sted, og jeg begyndte pludseligt at lide et afsavn til mine sene aftentimer, imens Paul Oakenfold fulgte mig derind, derind i flowet af programmeringens uendelige muligheder.

I arbejdet var mulighederne skiftet ud med mennesker, der vitterligt troede, de gjorde en forskel, med tusinder af linjer for betaling til lige at kunne klare tusinde mere, og som aldrig fik den samme fløjelsbehandling som den ægte kærlighed i kvaliteten udsprunget fra ens bedste energi.

Mondello var en skøn og på visse områder, en rå strand. Vi havde fire år forinden været der med Claudio og hans mor, som hverken røg eller drak, men som inden vi forlod sandet og vandet, både havde cigaretter i lommen og var blevet halvberuset. Vi havde uden, vi vidste det, gået forbi det sted, jeg nu så frem til at få en bid af. Mondello havde, ligesom bådflygtningene og historien fra Nebraska, taget røven på mig.

Da jeg endelig mødte Gianni, drengen der med sine computer-fingre havde bygget det, jeg gerne vil se, sker det på baggrund af en telefonopringning, som jeg ikke har set komme. Men Matteo har - fordi jeg har talt om det mere end en gang i nostalgiske vendinger - fundet ud af, hvor og hvem drengen er, og han har med lille portion armod i stemmen indvilget i at vise sit "kasseapparat" frem for os fremmede interesserede.

Gianni er 15 år gammel, og han har været begravet i sin computer, siden han var 8 år, fortæller han. Han har interesseret sig for den hemmelige verden inde under skærmen, siden jeg første gang tændte den, og som alle os, der har forvildet sig ind i en verden, som de færreste forstår, forstår jeg udmærket, hvor han kommer fra, selvom der er over 20 års aldersforskel på os.

Gianni fortalte mig med en lille undren, at han ikke erindrede, hvorfor det blev en Intel 4040-chip, men at han som 12-årig, i forbindelse med en ferie, havde fundet et "kit" hos en tjekkisk computerforretning, som også kom med hardwaren omkring en regnemaskine; display, knapper osv.

Også havde han fundet instruktionssættet for chippen knap så udfordrende - han viste mig den patinerede fysiske manual - men bestemt ikke nemt, og forsøget med at programmere mere komplekse ting havde fejlet for ham pga., mente han, antallet af bits til rådighed gjorde større operationer mere besværlige, end hvis han havde brugt en 8-bit chip. Så det var "bare" blevet til en simpel regnemaskine i begyndelsen.

Efter noget tid med hans nye regnemaskine begyndte Gianni at kede sig og besluttede sig for at udfordre foretagende og derfor bygge et lille sprog (DSL) og dertil en compiler i C og Python. Han kaldte compileren Polpetta efter en af hans mors søndagsretter, og navnet var netop opstået, fordi hun med stolthed havde serveret "Polpette al sugo alla siciliana" en sen aften, hvor hans udfordringer med programmeringen havde gjort ham tosset. Hans mors aftensmad havde reddet hans humør.

Gianni fortalte mig med hans teenage-jomfruelighed, at den afmagt, når noget ikke fungerede, ville holde ham vågen om natten og gøre ham kort for hovedet. Muligvis ud af hensyn til husfreden fandt hans far det morsomt, at hans program på det tidspunkt ikke kunne regne rigtigt, og så en mulighed i at bruge genstanden i restauranten, når betalingen fra gæsten skulle falde. Derfor endte Giannis "kasseapparat" hos restaurant Piero, og dens til tider finurlige resultater havde også underholdt gæsterne på restauranten, når der skulle betales.

Vi sad i Giannis fars restaurant, og jeg lyttede naturligvis til hans vidunderlige historie. Det er passionen, tænkte jeg, drømmen og ønskerne om at kunne omsætte tanker til virkelighed, der gør, at man lytter mere til nogle mennesker end andre. Rigdommen kan forsvinde med alderen, fordi forventningen æder sig ind fra noget, du ikke selv kan kontrollere - medmindre du er opmærksom på det fra begyndelsen.

Når det kommer fra unge mennesker, tænkte jeg, kan misundelsen opstå, fordi tiden i rummet er ubalanceret, og de har statistisk mere tid tilbage end en selv. Det er afgjort et forbilledligt mentalt maleri af, hvor stolt jeg bliver på de unges vegne - den sult Gianni havde - men samtidig også muligheden for at forberede dem på, hvor mange ligegyldigheder der venter dem fra en anden verden. Så min eneste anke til Gianni var, at han skulle passe på sin passion og lade den drive ham, men passe på, når andre ville have del i den for en afgift, der ikke harmonerede med den rigdom, den virkelig gav ham. Så hellere gå tiggergang, fortalte jeg ham.

Vi takkede derpå alle på restauranten for en formidabel aften og især for det minde til livet, vi var blevet beriget med. Vi skulle afsted ombord på Rubin nogle dage efter, og vi havde mere end en ting, der skulle forberedes inden. Da vi forlod Sicilien og sejlede af det Tyrrhenske hav op mod Ligurien, vidste jeg, at vores historie ville passe godt ind, når vi endnu engang stod på Nebraska lidt nord for Viareggio, i Camaiore. Det var der, vi satte kursen mod.

Lighed på arbejdspladsen.

tirsdag den 12. marts 2024

Alan Kay er citeret for at have sagt: "Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future—it’s living in the present. I think the same is true for most people who write code for money. They have no idea where their culture came from—and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made."

Se bort fra Alan Kay's kommentar omkring det at skrive kode. Tænk i et større perspektiv.

Det er et slående udsagn, som jeg har tænkt over i flere år, og som belaster min evne til selv at forbedre omstændighederne, men som også presser min egen solidaritet omkring det, at være samarbejdsvillig i mit professionelle virke.

Mine næsten 25 års erfaring peger, for mig, udelukkende på, at den manglende progression - at år efter år helliger vi os til hurtigere og billigere resultater - handler mere om, hvordan vores institutioner er indrettet, end om at det er mennesket som ikke ønsker at samarbejde eller opnå en følelse af tryghed og lighed.

Der er ikke meget ro eller tid til samarbejde når omdrejningspunktet for success er forankret omkring individualisme og konkurrence. Så hvordan kan en institution forvente, at mennesker kan udtænke innovation, finde på gode løsninger sammen med andre, og bruge tid til fordybelse når timeglasset konstant bliver mindre? Det er svært at få øje på en umiddelbar positiv retning der afviger, fra en eller anden form for menneskelig tragedie.

Det er naturligvis ikke kun i min egen branche tingene forholder sig således. Og historien gentager sig selv. Politik. Krig. Langbrug. Fiskeri. Uddannelser. Og alt det andet du selv kan komme i tanke om.

Mennesket bliver ikke klogere fordi tiden går, det er der ingen evidens for, så hvis man gentager sig selv forbliver man i gentagelsen.

I Nancy G. Levesons bog "Engineering a Safer World" skriver hun bla. om luftfarten: "The average time to translate a basic technical discovery into a commercial product in the early part of this century was thirty years. Today, our technologies get to market in two or three years and may be obsolete in five. We no longer have the luxury of carefully testing systems and designs to understand all the potential behaviours and risks before commercial or scientific use."

Se hvordan det er gået med Boeing. Se hvordan de mennesker der har viet sit professionelle virke se det smuldre fordi omdrejningspunktet er hurtigere og billigere. Det dør folk af.

Se på dit eget professionelle virke. Hvor er innovationen til en bedre og mere tryg verden?

Alt skal altså gå hurtigere. Og til hvilken pris? Og hvordan står man af, samtidig med at man skal overleve?

Vi har indrettet os på en måde, hvor solidariteten og samarbejdsvilligheden ikke blot handler mere om selviscenesættelse og grådidhed, men hos langt de fleste mennesker udløser det en psykologisk forsvarsmekanisme, som bunder i overlevelse.

Du har ikke mulighed for at ændre noget i den virkelighed der hersker udenfor dit eget ansvar - og end ikke der kan vi føle os helt trygge - men du kan forsøge at klare dig eller tilpasse dig. Det er bare ikke progression.

Jeg tror, det, hr. Kay siger, samtidig har en dyb korrelation til bl.a. udbrændthed og sorg hos mennesker. Der findes en form for overgivelse. Vi forsøger hele tiden at klare og tilpasse os. Men vi forbedrer os ikke rigtig, og jo mere vi distancerer os fra solidariteten og ligheden des værre bliver det desværre.

Alan Kay siger i en anden forbindelse: "...there's no concept of progress in our genes...we have an enormous set of genetic apparatus to make us good copers. Anything happens to us, we can find a way of being resilient...and adapting to it. We're copers and adapters...so when we come up against difficulties, our tendency is to cope with these difficulties. It's like working for a company, go into a company and the company seems sort of screwed up. Maybe you can quit, you can cope, but your chances of actually changing the company are very low because nobody will listen to reason."

Så folk lytter ikke rigtigt. Men hvorfor skulle de også det når andre ikke lytter til dem?

Individualisterne bekæmper hinanden i køen til den samme success. Hvis du står af der, bliver du efterladt med en følelse af, at du har misforstået konceptet, udefra set. Presset er enormt hos de mennesker der har købt ind i det dér.

Det avler samtidigt en kultur af mennesker, som ikke føler sig inkluderet eller beriget, og uden de samme chancer for at gøre den forskel, de i virkeligheden rummer og ønsker, fordi institutionen er bygget, som den er.

Og lige netop ulighed er så meget på tale i disse år. Ulighed mellem mænd og kvinder. Ulighed mellem mennesker. Hvad med uligheden på arbejdspladsen?

Der, hvor de fleste voksne mennesker bygger deres identitet og bliver en del af det institutionelle sammenkog, hvor netop hurtige og billige resultater belønnes, men hvor du også bliver målt og vejet på, om du er i overensstemmelse med institutionens værdier, og hvor det former dig som menneske, fordi indoktrineringen er sket fyldest. Det kræver jo ikke ligefrem en ph.d. for at gennemskue, at den lighed kun eksisterer, hvis du ikke forsøger at ændre den.

...maybe you can quit, you can cope, but your chances of actually changing the company are very low because nobody will listen to reason..."

Det er ikke relevant om du er mand eller kvinde. Hvis du ikke tilpasser dig det som institutionerne forventer - som har intet at gøre med solidaritet eller lighed - så kan du bare tage bagdøren.

Så hvis du tror dit professionelle liv er demokratisk og dine chancer er lig andres, så tager du altså fejl. Men du skal jo klare dig, og hellere dig en de andre ik'.

Myten om "det er bare et arbejde" hører ingen steder hjemme, fordi det er på det selv samme arbejde forventningen fra andre ikke handler om lighed. Fordi hvis det virkelig var lighed man søgte så gjorde man netop institutionerne mere solidariske. Problemet er bare at det ikke harmonere med den verden vi har indrettet.

"The important thing is not to stop questioning. Curiosity has its own reason for existing. One cannot help but be in awe when she contemplates the mysteries of eternity, of life, of the marvelous structure of reality. It is enough if one tries merely to comprehend a little of this mystery every day." - Albert Einstein

En note til mig selv ligsom til dig er, at man skal passe på med, hvad man tror på. Det kunne jo være, det var forkert.

Microservices udstiller organisationens kommunikationsstrukturer, hvilket medfører, at enhver svaghed og styrke i den, bliver synlig.

søndag den 11. februar 2024

Microservices er en ubarmhjertig arkitektur.

Ikke kun fordi den stiller andre krav til de teknologiske aspekter der differentierer den fra den traditionelle organisations systemudvikling.

Men i højere grad fordi den udstiller organisationens design men samtidig forventer klarhed over, hvor de enkelte services er forankret, i hvilke teams.

Microservices er blevet udskammet og rost, ligeligt. Udskammet af teknologister fordi designet ikke kan stå alene, teknologisk. Rost fordi, organisationen der rent faktisk formår at ændre kommunikationsstrukturene imellem deres teams, også er dem som får mere ud af designet end blot en teknologisk edge.

Microservices primære succes-parameter handler næsten udelukkende om hvordan kommunikationen flyder i organisationen, ift. hvordan kontrol og forankring placeres.

Microservices repræsenterer således et udfordrende paradigme, primært fordi grundlaget for succes i høj grad ikke blot afhænger af teknologisk professionalisme, men i større graf afhænger af de udøvende teams autonomi i organisationen.

Derfor er nødvendigheden eksplicit omkring hvordan organisationens kommunikation flyder.

Dette er jeg personligt overbevist om er et must, selv for meget små organisationer.

Et system er en helhed sammensat af flere dele. Forstil dig vi ser systemet med udgangspunkt i software eller andre menneskeskabte ting.

Hver af disse dele er designet, udviklet og bygget et eller andet sted i en organisation, og højst sandsynligt omkring et domæne, noget viden og erfaring.

Og hver eneste menneske som er involveret i denne process vil blive kognitivt påvirket ved at indgå i dets arbejde.

Gestalt refererer til en helhed bestående af flere enkelte dele. Helheden betragtes som større end summen af de enkelte dele, der danner gestalten. For eksempel er en rytme mere end summen af de enkelte slag, og en melodi er mere end summen af de enkelte toner. Kilde

Selv en lille del i et system kan have stor betydning. Ofte bruger jeg en analogi omkring en motor. En motor er et system bestående af mindre helheder, som igen består af mindre dele.

Her er en brændstofsdysse. Det kan vi betragte som en helhed. Den udgør et facit som er brugbart hos andre helheder og givetvis i forbindelse med andre systemer. Den er samtidig opdelt og samlet af mindre dele.

Motorens mange dele handler rent teknisk om at lade den indgå i samarbejdet med andre dele og sammen udgøre en enhed - en mindre enhed - men som samtidig kan spille en rolle i en større helhed af et system (en motor f.eks.).

Men om helheden af en brændstofsdysse sidder i en diesel-generator, en græsslåmaskine eller en industri-ovn er ikke systemets ansvar at bestemme. Omverdenen må altså også beslutte hvor en helhed i deres eget system, giver mening - men de bestemme over helheden.

En af mine egne maskiner set fra siden; luftindtag, vandpumpe, starter-motor, manifold etc. Brændstofdysserne sidder forbundet på hver det som ligner omvendte "U'er".

Hver lille del samarbejder til at blive noget større, som potentielt igen bliver til noget endnu mere.

• Del. Enhed. System.
• Del. Helhed. System.
• Endpoint. Service. System.
• Endpoint. Input/Ouput. System.

Men det er også her, vi kan begynde at betvivle vores hidtidige opfattelse af helheden af systemet som værende forkert.

Hvis vi antager, at den enkelte del kun bør indgå i én systematisk sammenhæng, hvorfor skulle vi så ikke integrere delen fuldstændig i helheden? Hvad er fordelen ved at bygge noget som kan "leve" i en anden sammenhæng ?

Se på motoren og overvej så at jeg ikke kan skifte vandpumpen (den lille bronze del nederest til venstre) uden at jeg også skal skifte hele blokken.

Vandpumpen suger vand ind. Og pumper vand videre. Det er ansvaret for den helhed. Det er dens facit. Hvordan resten af motoren bruger vandet er vandpumpen hverken interesseret eler ansvarlig for.

Vandpumpen på billedet kan f.eks bruges på motorer af Nanni, Volvo Penta, Perkins og Mercedes.

Vi kan altså opfatte vores services som egne helheder. Det er selvfølgelig ikke et krav. Vi kan også betrage dem som værende interne dele som i sidste ende udgør en helhed.

Om helheden kan anvendes - ikke kun af ét system - men også i og af flere andre, er det som gør helheden i stand til at differentiere sig, og ikke have en nær relation/kobling til andet software.

Dette svarer dog ikke på spørgsmålet om, hvorfor microservices kan være et fordelagtigt design. Men det fører os måske lidt nærmere til erkendelsen af, at en del, som kan fungere som en helhed - se på brændstofsdyssen - kan udvikles uden at skulle forholde sig nært til hvordan andre helheder eller systemer. Og hvis man ikke skal forholde sig til det så er det mindre at fylde hovedet op med.

Herover er der dele som udgør enhender.

Helhederne bliver måske en del af to forskellige systemer.

Forestil dig det sådan, at hvis virksomheder, som fremstiller dæk til biler, også var nødt til at designe og udvikle aksler og undervogne for at få deres dæk til at passe på bilen, ville det så være fordelagtigt ? Næppe.

Det er ikke ligefrem en subjektiv antagelse jeg fremfører, at jo mindre kompleksitet mennesket behøver at forholde sig til, desto større er sandsynligheden for at ens hjerne har en bedre chance for danne overblik og tænke mere klart.

Når en organisation beder sine ansatte om at bygge et system, sker der ofte det, at de ansatte starter med at forsøge at forstå helheden omkring systemet.

The human mind is incredibly averse to uncertainty and ambiguity; from an early age, we respond to uncertainty or lack of clarity by spontaneously generating plausible explanations. What’s more, we hold on to these invented explanations as having intrinsic value of their own. Once we have them, we don’t like to let them go. Kilde

I begyndelsen kan det muligvis være nemt nok, fordi systemet endnu ikke er stort nok til at skabe betydelige kognitive udfordringer for medlemmerne. Men hvis du har bygget software længe nok, i teams af mere end én person (og selv da er det svært, når tingene vokser), så opstår der pludselig alle mulige udfordringer, som faktisk har meget lidt at gøre med teknologi. Derimod meget at gøre om organisation, deraf kommunikationen også ganske enkelt psykologien hos mennesket.

Kruglanski conceptualizes our need for cognitive closure as consisting of two major stages, seizing and freezing. In the first stage, we are driven by urgency, or the need to reach closure quickly: we “seize” whatever information we can, without necessarily taking the time to verify it as we otherwise would. In the second stage, we are driven by permanence, or the need to preserve that closure for as long as possible: we “freeze” our knowledge and do what we can to safeguard it. (So, for instance, we support policies or arguments that validate our initial view). And once we’ve frozen? Our confidence increases apace. Kilde

Vi skal derfor designe systemer omkring, at en del eller en helhed bør forblive tilstrækkeligt lille, således at både systemet, organisationen, teamet og den enkelte person kan rumme det. Ja det er meget at bede om.

Her kan vi, istedet for at betragte de største kasser som helheder for deres bærende dele, også betragte dem som værende teams, med et ansvar for helheden og dets bærende dele. Hver farvet kasse er nu et team der bygger det som farven har ansvar for.

Små helheder er ofte tæt knyttet til noget, der har større betydning end den enkelte helhed selv.

Når man bygger noget, der skal kunne fungere afkoblet, men samtidig interagere med andre helheder og systemer, skal denne helhed altså kunne bidrage med mere end bare at være en helhed for sig selv.

Jeg bliver gerne at sige, at det er den enkelte enhed som indeni sig selv har ansvaret for, at manipulere de data som er vigtig for enhedens jeg. Hvad der dernæst udstilles på den baggrund er op til modtageren at undersøge om er brugbart og nyttigt for sit dets eget jeg.

intet der ikke er en intern del af helheden skal kunne manipulere med den.

Microservices skal give nogle forbedrede evner hos organisationen, hvoraf nogle af mulighederne er:

• reducere mængden af ting som der skal foholdes sig til
• minimere kommunikationen fordi ikke ikke er forankret samme sted
• øge helhedernes og systemernes transparens så det tydeliggør hvad og hvor noget er kompliceret/dyrt.

En anden evne er, at en del eller heldhed kan repræsentere en forretningsmæssig værdi eller mulighed. For eksempel på samme måde som vandpumpen, der kunne anvendes af mange forskellige motorer og ikke blot én.

Derfor, hvis vi ønsker at bygge mindre, for bla. at øge transparensen omkring kompleksiteten, forandre kommunikationsstrukturer og dele ansvaret op hvor sømningerne i domænet også splitter, så kan vi ikke længere organisere eller kommunikere på samme måde som hvis vi ville bygge systemer med ideen om, at alle dele skulle være forankret på samme sted.

Der følger trade-offs med til alle valg. Så uden først at acceptere at der naturligvis også følger trade-offs med i valget af et microservice design, så vil dit valg føre til nye frustrationer som blot vil være anderledes. De frustrationer vil højst sandsynligt komme fra organisationens forsøg på at adoptere nye måde at kommunikere på, eller dens umodenhed til samme.

Hvordan ser jeres kommunikationsstrømme ud ? Hvordan bygger I software på baggrund af den ? Tegn den op så i kan se hvordan strømningen er, men lad den være baseret på jeres eget data.

Personligt har jeg aldrig set en microservice arkitektur fungere, uden at der til grunds var dannet teams der ejede dele og små helheder, snarere end hele systemer eller store helheder.

Jeg har set det være en rigtig modbydelig tilgang mere end en gang. Der førte til skyttegravskrig imellem teams, elfenbenstårnsarkitekter der valgte at prøve at gøre det forfra - bare i andre teams. At koblingen imellem helhederne var så "tight" men menneskerne så adskilt, at den asynkroni og det mandat der skulle gøre ansvaret mindre hos det enkelte team, istedet mangedoblede den og samtidig udpenslede organisationen som værende både umoden og til sidst perfid.

Jeg ved godt det lyder vildt og dramatisk men det kan blive grimt når ens organisation faktisk viser sig patologisk, og ikke vil formår at tage ansvar for dets valg.

Teams skal kunne operere inden for rammerne, trygheden og autonomien for, hvad deres del og mindre helhed gør det muligt for dem at tilbyde andre og andet.

Hvis en organisation ikke formår at adskille disse begreber - dele, helheder, og systemer - både på et højere abstraktionsniveau og især i den praktiske udførelse, løber den en risiko for at blive overvældet af services, som reelt set kun er løst forbundet software centreret om teknologi frem for domæner, teams, og forretningsegenskaber.

Jeg har set interne service-registre i virksomhed, udviklet i hundredevis, som kunne alt fra at sende, emails, booke aftaler eller registere parkering. Problemet med den slags services er, at de ikke udgør en del af en større helhed som er forankret omkring et doæne i forretningen. De lever bare et passivt liv og ingen tager rigtig ansvar for dem af samme grund.

Jeg ville aldrig anbefale organisationer, der opererer ud fra traditionelle organisationsstrukturer, at forfølge en idé om at udvikle systemer baseret på microservices. Det kræver en vis modenhed fra ledelsens side - især omkring autonomi i de enkelte teams syntes at være meget svært at accepterer - men ofte også en teknologisk forandring blandt programmørernes tankevirksomhed, da de givetvis skal begynde at forholde sig til nogle andre begreber og tilstande, end de højst sandsynlig har været vant til.

Software bliver stadigvæk bygget på antagelser, anekdoter, idolisering og af hierarkiets prestige.

onsdag den 31. januar 2024

software: en potentiel mulighed for en virksomhed eller organisation for at understøtte målsætningen omkring enten at innovere, øge den forretningsmæssige økonomiske værdi eller på anden vis være bedre stillet ift. effektivitet og produktivitet.

software: eksterne eller internt vendte produkter, features, komponenter eller systemer, som har til formål at adressere ovenstående.

Da Jan og jeg for nogle år siden indledte vores samtaler og diskussioner omkring vores erfaringer og udfordringer i og med organisationer, som bygger software, var omdrejningspunktet, at mulighederne for at supportere og lære organisationer nogle bedre vaner i forbindelse med softwareudvikling, var ret store.

En af de udfordringer, vi begge har og havde været så stor en del af tidligere, er det faktum, at software ofte bliver drevet med udgangspunkt i en "god idé", ofte enten udklækket hos en leder eller et stort ego, men hvis hypoteser aldrig bliver valideret i den virkelige verden.

Vi var begge overbeviste om, at modenheden i organisationer og virksomheder skulle testes og valideres, fordi vores hypotese omkring ovenstående ikke var andet end vores egen pendant til "god idé", og vi vidste naturligvis heller ikke, hvad den virkelige verden ønskede sig, før vi involverede os i den.

Vores egen forventning var, at vi i det mindste kunne få taletid omkring vores budskaber hos virksomheder, der set udefra kæmpede med at få det meste ud af deres softwareorganisation.

Vi har aldrig nogensinde villet agere på samme vis som den typiske konsulentvirksomhed, hvor mantraet i grove træk alt for ofte er "gør som vi siger, fordi vi siger det" eller "I gør det forkert, I skal gøre sådan her". Det er en pinlig bevisførelse og på mange måder en arrogant og manglende kontekstforståelse, som desværre lever i alt for stor udstrækning i vores branche.

Vi havde selvfølgelig antagelser omkring vores hypoteser. Nogle skulle også vise sig at være korrekte. Men grundlæggende skulle det vise sig, at vi hurtigt blev udfordret af, at stort set ingen var interesseret i at blive fortalt, at deres initiativer og idéer ville nyde godt af at blive udfordret et andet sted end virksomhedens tankeland.

"Jeg har bygget software i 30 år uden at have talt med en eneste bruger," - softwareudvikler ansat i en softwarevirksomhed.

Vi ville ind tidligere.

Når vi oplevede teams på nært hold og betragtede deres udfordringer sammen med dem, var deres udfordringer sjældent af synderlig teknologisk karakter. Bevares, kompetente (tekniske) mennesker, som forstår, at målet for deres arbejde i virkeligheden ikke handler om at skrive kode eller tegne streger imellem systemer, skal man naturligvis gøre sig en smule umage for at tiltrække.

Men vi ville ind længe før den første linje kode, den første tegning på en tavle eller første skærmbillede blev udfærdiget. Vi ville ind der, hvor ledelsen begyndte at tro på, at virkeligheden for deres initiativer og idéer stemte overens med det tankeland, de befandt sig i.

Og det ville vi udelukkende for at spare dem for den potentielle hovedpine og de langstrakte perioder, som ud fra vores erfaringer fortalte os, at tiden brugt på endeløse møder, rygklapperi og monologer fra dem med mest senioritet, var tid, der ikke kom igen. Vi ville ind der, hvor vi kunne hjælpe med at udfordre deres billede af virkeligheden og hjælpe med, hvad det rigtige var for dem at bygge.

Hvorfor noget er en god idé, er jo et valideringspunkt, som skal udstilles og testes, ikke fordi idéen er dårlig, men fordi idéen er værdiløs, før den resulterer i noget virkeligt i den virkelige verden. Du kan ikke se ind i fremtiden, og selvom du gerne vil have ret, så er det en yndefuld egenskab hos mennesker at hvile i, at det er helt okay at tage fejl og derefter komme videre. Deraf "fail fast".

Af samme grund eksisterer der i rigtig mange virksomheder en forberedelse, som er fuldstændig uforløst, fordi initiativer ofte har det med at udspringe mere på baggrund af en leders stjerner på skulderen end på baggrund af at have brugt energi på at forberede sig og validere sine hypoteser, så det man producerer rent faktisk også stemmer overens med det, som virkeligheden efterspørger.

Vi ville ind der, hvor vi fik mulighed for at supportere og lære organisationen og lederne nye vaner, som de i forlængelse af os kunne bruge i deres egne organisationer.

Lederne blev et nøgleord her, fordi vi fandt ret hurtigt ud af det, som vores egen hypotese blev valideret ud fra - at det er de færreste organisationer, som er designet og drevet på baggrund af nutidige muligheder om at skabe et bedre miljø og fundament for ens softwareorganisation. Vi fandt ud af - vi havde allerede en antagelse herom - at langt størstedelen af organisationer til stadighed er designet på en måde, som helliger enkeltpersoners position frem for den samlede enheds kapacitet.

Kommunikation er i dag helt og aldeles gratis. Hvorfor ønske sig en leder, hvis rolle det er at kommunikere oppefra og ned? Hvorfor have en leder bestemme, hvordan et team skal adressere en given problemstilling?

Der ligger et enormt ego gemt i, hvordan de triangulære organisationer er designet, og det er også vores klare overbevisning, at det er en kæmpe fejl at lade enkeltpersoner udøve sit ansvar på baggrund af idéen om, at det de foretager sig, må være rigtigt, fordi ellers ville de jo kunne opleves som inkompetente.

Hvis en enkelt person er så dygtig til at komme med svarene, så lad vedkommende sidde ved klaveret og spille med, indtil sangen er færdig.

Vi arbejdede sammen med et par virksomheder og i teams, som har været ret fantastiske i deres evne til at organisere sig og forankre det mandat, autonomi og ansvar fra en kompetent ledelse. Det har været en gave at opleve, hvordan nogle organisationer evner at skabe en sådan arbejdsplads.

Men vi har fundet det afsindig svært at komme ind på det tidspunkt, vi gerne vil ind på. Idéer har det nemlig med at være sejlivet, og jo flere klap på skulderen ophavsmanden modtager, jo større energi får idéen. Vi har simpelthen ikke været gode nok til at få vores argumenter plantet, især omkring det at skulle forbedre organisationens evne til at forberede sig "inden vi går i trykken".

Default er den gode idé.

Vi havde specielt et engagement, som skulle vise sig at være en lærerig oplevelse. Vi har aldrig haft et ønske om nogensinde at gå ind i et udviklingsforløb med mindre, der foreligger en afklaring omkring hvorfor det forløb eksisterer, og hvad grundlaget for beslutningerne er baseret på.

Vi har hverken tid eller lyst til at bruge andre folks penge på at lave noget, som ikke kan understøttes med data fra virkeligheden. Det har været hele vores eksistensgrundlag ikke at omdanne en såkaldt god idé til noget, der alligevel ikke gav mening.

Så vi starter aldrig med at tegne diagrammer eller designe systemer på en tavle, eller sidde i møder og snakke om, hvem vi skal købe hvad fra og hvornår.

Vi arbejder med mennesker i den virkelige verden, og lader dem skyde med skarpt på baggrund af de hypoteser, der opstilles, så vi på den måde kan få indsamlet evidens og dannet grundlag. Det er sådan, det er nødt til at være, taget alle de forgangne års fejlede initiativer i betragtning.

I det her tilfælde – vores lærerige eksperiment – havde vi indledt en dialog med en virksomhed, som var så forblændet af deres egen idé, at selvom de godt kunne se værdien i at få den valideret i den virkelige verden, så var deres tro på idéen så stor, at de valgte at udvikle produktet i stedet for først at teste dets hypoteser af.

Det fik os alligevel til at indse og begribe omfanget og alvoren omkring idéens magt og dens tag i menneskerne, der er investeret i den. Det var jo ikke fordi vi ikke havde set det før – vores data viser os, at 80% af alle virksomheder, vi har været en del af, bygger software på den baggrund – men det kommer alligevel bag på os, hvor vigtig ens egen virkelighed synes at blive brugt som drivkraft for en idé.

Det har samtidig også vist sig flere gange, i andre kunderelationer, at når et team finder det udfordrende at vide, hvilken retning noget skal bevæge sig i, så default'es der ofte til den "gode idé", som så alligevel senere viser sig at være ingenting værd.

Af samme grund mener vi, fordi vi har været i de her forhold mere end bare et par gange, at det er langt mere værd at forberede sig langsommere end at bygge hurtigere. Du kan ikke snyde dig til evidens eller bruge ude-af-kontekst data fra andre. Du er simpelthen nødt til at teste og validere dig frem til dine egne data omkring den kontekst, I befinder jer i, og det kan spare dig for mere end bare tid og penge.

Vi anser os selv som en del af den bevægelse, som udover at være kompetente og passionerede omkring vores virke, opfatter og oversætter den agile filosofi og kultur som noget, der handler mere om at blive klogere på det, man bygger, frem for at gætte sig frem igennem lukkethed og ubarmhjertige vilkår. Altså handler det om at bygge det rigtige ved hurtigt at kunne modtage feedback fra den virkelige verden.

Jeg er et eller andet sted rigtig ked af, at agile har fået så dårligt et "rep", men med indførelsen af de ellers så smukke og pragmatiske muligheder, i hvad der syntes at være uforanderlige organisationer, er de på sin vis blevet misbrugt som en knækket løftestang, med troen på, at kulturændringer kan læres igennem kurser, tegninger, certificeringer og titler.

Kvalitet går langsomt men I vil hele tiden gøre tingene hurtigere.

Loven om "leaky abstractions" får hvert år en stadig større betydning for alvoren om, i hvilken retning branchen bevæger sig, når der laves investeringer i forbindelse med at forbedre den produktive og effektive tilstand for alle virksomheder, som bygger software.

Prøv for sjov skyld at se på, hvad der er blevet talt om på diverse konferencer, samt hvilke litterære værker der er udgivet de sidste 10 år, og frem til i dag, også dan dig dit eget billede af, hvor langt du egentlig synes, vi som branche har rykket os. Læg dertil din organisations forandring oveni.

Hvis du med fuldstændig ro kan sige til dig selv, at med flere af de samme abstraktioner, er vi blevet bedre, så chapeau til dig. Godt gået. Really!

Udfordringen er bare, at jo flere abstraktioner vi smider ovenpå hinanden, des mere skal vi forholde os til. Så selvom abstraktionen synes at gøre os i stand til mere, er der i samme ombæring mere, vi skal jonglere med. Så med en pseudo-forøgelse af produktivitet eller effektivitet medfølger der et stadig større kognitivt og økonomisk pres.

Jeg finder det glædeligt, når de mennesker, hvis litteratur jeg ynder at læse, eller hvis karriere jeg finder nogenlunde tidsløs, til stadighed beviser, at de "nederste" abstraktioner stadig er dem, som er mest betydningsfulde for, hvordan tingene reelt hænger sammen. Men jo længere jeg bevæger mig op i abstraktionerne, jo længere bevæger jeg mig imod popkulturens karakteristika om fuckability, larm og hurtige resultater.

På den måde finder jeg meget lidt tvivl omkring, at Jan og jeg desværre har været klemt op i et paradoksalt hjørne. De mennesker og virksomheder, der godt ved, hvordan man gør, har nemlig ikke brug for sådan nogle som Jan og jeg. Dem, som vi mener godt kunne bruge vores viden og data, enten leder de forkerte steder, eller også ønsker de, bevidst eller ubevidst, at mærke frustrationerne igennem deres egne erfaringer, og for sig selv.

Udviklingen af teknologi går stærkere, end vi når at forholde os til den, og det er svært at få øje på - bl.a. taget loven om "leaky abstractions" i betragtning - hvordan flere abstraktioner skal hjælpe os til rent faktisk at blive bedre. Det gælder ikke kun IT; det er ligeså udtalt en bekymring andre steder i verden. Bare kig op og se, hvem der forsøger at sælge dig mere teknologi.

Personligt finder jeg kvalitet andre steder end i teknologiens verden. Kvalitet for mig er en helt anden størrelse, og det kan være betagende at sidde og betragte historien og kurverne omkring den.

Når jeg nu sidder her og kigger på de materialer, som er brugt, og det håndværk, som er udført, på mit svenskbyggede sejlskib fra 1986, så bliver jeg hele tiden overrasket over, at nogen har formået at lave noget, der "lever" i så barske omgivelser (vand, salt, sol og vind), og som stadig er så holdbart og driftsikkert. Det er kvalitet.

Eller når jeg studerer min instruktionsbog til min Mercedes OM636, og det gør jeg flere gange om året, så falder jeg fuldstændig i staver over, hvor detaljeret og veldokumenteret det produkt er. Det er for mig en enestående oplevelse at sidde der og prøve at forstå, hvordan man kunne samle et team, og rent faktisk komme i mål med at udvikle noget så velfungerende og smukt. Det er kvalitet.

Jeg har derimod absolut ingen forventning til, at vi alle sammen skal hellige den samme forståelse eller ønske om kvalitet. Det ville være en yderst arrogant forventning. Men den laveste kvalitative fællesnævner må i en professionel setting adresseres, inden man bygger software, fordi den, udover at have betydning for selve kvaliteten af resultatet, også har en betydelig indflydelse på de mennesker, som deltager i forløbet omkring og i udviklingen.

Kvalitet kan udover at være en holdning også samtidig være en skrøbelig tilstand, som kræver, at en organisation udviser kurage og tryghed overfor de mennesker, hvis tilstedeværelse og energi de trods alt har et betydeligt råderum over, og som der er en forventning til, kan stemple ind.

Lederens rolle

En sideeffekt af de ting, Jan og jeg har oplevet i vores virke sammen, har bl.a. været, at de ting, som har været et velkendt negativ i årtier, stadig i stor udstrækning bliver brugt som støttekrykker, også selvom branchens kompetente og velansete litterære og udøvere har formidlet viden og statueret grundige eksempler på, at de er mindre gunstige ift. at drive udvikling af software.

Vi har måttet sande, at organisationer til stadighed er forankret omkring et triangulært organisationsdesign, hvor levn fra den traditionelle "switchboard manager" stadig har til formål at kontrollere og kommandere.

Organisationer har haft den udfordring, siden kommunikation er gået fra at være dyrt til at være gratis. Og de sidste 15 år har kommunikationen altså været gratis. Derfor har en af lederens primære roller ændret sig, fra ikke længere at agere bindeled imellem teams eller ledelse, sidde i toppen af trekantens snævreste linjer og kommandere nedad og rapportere opad.

Sådan ser verden ikke ud i dag, og jo før man accepterer det, des mindre vil det gøre ondt på ens organisation. Inden General Motors gik konkurs, bad en VP i GM om, at man fotograferede hele fabrikken hos Toyota, fordi GM måtte kunne opnå den samme mulige succes, hvis de blot kopierede Toyota-fabrikken.

At kommunikation er gratis, har de færreste organisationer grundlæggende accepteret – der er stadig alt for meget institutionel indoktrinering og hierarki (jeg kunne godt tale om ægte diversitet samt inklusion) – og det koster til stadighed virksomhederne rigtig dyrt.

Vi har set og været en del af teams, som er blevet bedt om at vente på, at et andet menneske i virksomheden er blevet færdig med sit eget arbejde, før et 10, 20, 80 personers team kunne komme videre.

Vi har oplevet, at teams skal sende support-emails for at ville udgive sin software.

Vi har oplevet, at et team ud af mange teams har bestemt, hvordan alle andre teams skal strukturere deres arbejde.

Vi har deltaget i agile transformationer. Sågar DevOps transformationer. Vi har endda selv brugt ordet digital transformation, fordi vi troede, vi kunne sparke døren ind hos dem, der alligevel ikke vidste, hvad det betød.

På et tidspunkt vil medarbejdere, som sidder fast i flaskehalse, magtesløshed, endeløse ligegyldige agenda-løse møder om tankeland, venten på såkaldte nøglepersoner, ikke længere acceptere, at de ikke kan udnytte deres eget voksne råderum og tage affære igennem deres egne kommunikationsstrukturer.

Så når samfundsdebatten også er koncentreret om spørgsmålet om, hvorfor vi skifter arbejde som aldrig før, og virksomheder har hamrende dygtige mennesker væltende ud af bagdøren, så tror jeg ikke, det er forkert at pege på det her som en betydelig udfordring.

Det har heldigvis vist sig at fungere langt mere effektivt at lade sine teams og medarbejdere eje ansvaret og have mandatet til selv at kunne gøre det, de mener er bedst for den forretningsmæssige egenskab, de har fået stillet i sigte.

"Organisationen", som de fleste af os har været i berøring med som professionelle, er i Jan og min lille bog, mega udfordret. Ikke blot fordi den ikke længere formår at bevise sit værd på et organisatorisk plan, men fordi verden er så forandret, at vi som mennesker ikke længere kan se os selv navigere i sådan et hierarki.

Da jeg mødte Said, en tidligere lektor på CBS, og min tidligere og helt igennem fantastiske kollega i Microsoft, sagde han til mig: "I er 10-15 år for tidligt på den, der er ikke mange som forstår, hvad det er, I forsøger."

Vi koncentrerer os ikke synderligt om fremtiden, vi koncentrerer os om, hvad vi har nu og her, og hvad der kommer i morgen, må vi forholde os til dér.

Vi har fået valideret et par af vores egne hypoteser igennem dialog og smørrelse med vel omkring hundrede virksomheder.

Vores idé om at få virksomhedens initiativer ud af tankelandet med målet om at:

• Eksperimentere og validere sig frem til det, hvad der er rigtigt at bygge.
• Supportere lederne ved at etablere gode vaner i og omkring sin softwareorganisation.

Hvis du vil have flere detaljer, må du tage kontakt til mig.

Du kan ikke skalere agile. Et par af SAFe's misforståelser.

onsdag den 24. januar 2024

Det er en udbredt misforståelse, at man kan skalere agile. SAFe, et populært produkt i denne sammenhæng, falder ofte i denne kategori. Men at dvæle ved dette postulat er unødvendigt. Forståelsen af agile, som det er beskrevet i det agile manifest, er afgørende her. Det handler om en grundlæggende indsigt og accept af agilitet, snarere end en dogmatisk tilgang.

Agilitet er omgivet af visse dogmatiske synspunkter, hvilket jeg kunne diskutere længe. I softwareudviklingsforløb er det almindeligt at støde på såkaldte agile purister, der argumenterer med udsagn som "du gør det forkert" eller "det er også en del af agile".

"When one sperm gets into a human egg, there’s an automatic shut-off device that bars any other sperm from getting in. The human mind tends strongly toward the same sort of result."

SAFe indeholder mekanismer, som på overfladen kan synes agile, men som faktisk strider mod den sunde fornuft og erfaring, der ligger til grund for agilitet, som den er udtrykt i det agile manifest. Manifestets fire nøgleværdier - Individuals and interactions, Working software, Customer collaboration og Responding to change - er ikke komplekse. De tolv underliggende principper er endda mere objektive, om end de kan være udfordrende at følge i praksis.

"The brain of man is programmed with a tendency to quickly remove doubt by reaching some decision."

Agile er i den grad også blevet genstand for kommerciel udnyttelse, hvilket de sidste 20 år har vist. SAFe er et glimrende eksempel på, at kommercialisere det agile manifest i en retning det aldrig har været tiltænkt. Agile er ikke et produkt.

Samtidig er det er ikke nok bare at påstå "det agile manifest virker bare". Også selvom det langt hen ad vejen er sandheden.

"The brain of man conserves programming space by being reluctant to change, which is a form of inconsistency avoidance. We see this in all human habits, constructive and destructive."

Jeg har oplevet SAFe's såkaldte PI-Planning mekanisme hos en kunde, hvor 100 mennesker fordelt på 12 teams brugte 3 dage på at forberede det næste kvartals produktudvikling. Dette er ikke kun en voldsom overtrædelse af "planning fallacy", men også meget kostbart.

Udover den åbenlyse tilsidesættelse af "planning fallacy" så er det også en ofte meget dyr øvelse. I den pågældende kundes konstellation kan vi udregne det som 100 mennesker * 1000kr i timen * 7 timer * 3 dage = 2.100.000kr. pr kvartal.

Ved agilitet planlægges der baseret på hvad kunder og brugere finder relevant og på baggrund af evidens for, hvad der fungerer i de feedback loops som netop agile fordrer.

Man kan ikke planlægge tre måneder frem i et agilt miljø. Du kan godt forsøge at sætte nogle high-level målsætninger men lad endelig være med, at bruge dem som andet end din egen målestok for hvad dine egne ønsker er.

Hos Microsoft oplevede vi, at et otte-personers team forsøgte at planlægge et kvartal frem. Det lykkedes aldrig at komme ud med en plan, og møderne endte ofte i frustration over manglende konsensus og forståelse.

Agilitet handler ikke om skalering, men om at praktisere det, der står i manifestet og de underliggende principper for at skabe vedvarende gevinst.

Jeg forstår udmærket hvorfor SAFe har fundet vej til virksomheder, der er baseret på industrialiseringens blueprint. Det handler basal set om kontrol, som er en indgroet del af de fleste organisationer.

Disse virksomheder har enten ikke har formået eller ønsket, at ændre sin organisatoriske og kulturelle adfærd - noget der er nødvendigt for at opnå det som agile står for.

Og samtidig forstår selv samme virksomheder ikke forstår hvorfor det til stadigighed er svært for dem - vi har jo plastret agile på organisationen - at få større gevinster på baggrund af et sundere, sjovere og rigere fundament.

"...the idea of having an executive team, department directors, middle management, and then lower-level workers came straight from the railroad system..."

"If you’ve ever wondered where the workplace terms “chain of command” and “front line workers” come from, they transferred over from as the Greatest Generation returned from war and traded in uniforms and C-rations for suits and corporate..."

Indoktrineringen som stammer fra industrialiseringens hierarki, omkring værdiskabelse gennem hierakiets "command & control" og ledelsens prioriteringer, trives stadig i stor stil.

SAFe er blevet solgt til disse institutioner med et løfte om agilitet, men i realiteten bremser det alt, hvad agilitet står for - eksperimentering, autonomi, forretnings-potentiale - og fremmer i stedet silo teams, "chain of command", hierarkisk forankrede roller og en overflod af træninger og certificeringer.

"An ounce of prevention is worth a pound of cure." Brug energi på at tilegne jer gode vaner i stedet for at bekæmpe dårlige. Det sidste er nemlig mere energikrævende.

Quotes og kilder:

https://fs.blog/great-talks/psychology-human-misjudgment/ https://en.wikipedia.org/wiki/Planning_fallacy https://www.forbes.com/sites/forbesbooksauthors/2023/06/05/industrial-revolution-hangovers-part-i-corporate-hierarchy/ https://www.forbes.com/sites/forbesbooksauthors/2023/06/14/industrial-revolution-hangovers-part-ii-command-and-control-management/

Den triangulære organisation - en historie om et arkitekt og produkt teams organisatoriske forbandelse.

tirsdag den 23. januar 2024

I forlængelse af Switchboard Managers, vil jeg forsøge at dele lidt ud af nogle erfaringer om diverse organisationsdesign.

Samtidigt, posten om dedikerede teams, hvis rolle bliver en flaskehals for andre teams, forklarer jeg noget omkring, hvordan teams skal have mandat og ansvar til selv at bestemme, hvordan de ønsker at behandle deres software, og hvordan forankringen af et kollaborativt samarbejde skal ske internt i teamet, og ikke designes omkring forlængelser hos andre teams.

Kort fortalt, så skal teams, der bygger software, om det er produkter, features eller eksperimenter, selv eje alt ansvar omkring den software. Og det skal de netop fordi, at når man bygger software, så er det vigtigste at få det afprøvet så hurtigt som muligt i hænderne på rigtige mennesker, om det man har bygget også er det, som forventningen er i den virkelige verden.

Den her historie og erfaring udspiller sig i en større dansk virksomhed. Konteksten er omkring et initiativ, som kommer direkte fra ledelsen og som handler om, at "virksomheden skal mere effektivt kunne bedømme likviditeten hos kunden, ved optagelse eller ændring af nye eller eksisterende engagementer".

Eksternt produkt, internt produkt. To teams der ikke taler sammen.

Vi befinder os i et triangulært hierarki, hvor der eksisterer et dedikeret arkitekt-team (som dog også skriver kode), et produktteam (potentiel aftager af arkitekt-teamets produkt) og et øvre ledelseslag.

Hvert team har hver deres ledelse i toppen af hver deres trekant.

arkitekt teamet

• Arkitekt-teamet har fået til opgave at lave et internt produkt, som andre teams kan være aftager af.

• Det er arkitekt-teamet, som ud fra ledelsens idé har til opgave at udvikle og vedligeholde dette interne produkt.

• Der bruges mange måneder fra enkelte medlemmer i arkitekt-teamet på at tegne diagrammer, UML og andet, og trykteste diagrammerne hos andre arkitekter.

• Der udvikles software på baggrund af disse diagrammer, mundtlige overleveringer fra arkitekt-teamets ledelse, og der nedfældes ikke skriftlige krav, som ikke er af teknisk karakter.

• Når det viser sig, at udviklerne ikke forstår diagrammerne eller formår at løse opgaverne, fordi de hverken er nedfældede eller på anden måde formaliseret, bliver ledelsen involveret.

• På en hånd kan der tælles, i de første 6 måneder, hvor mange gange en bruger til softwaren er involveret i udviklingen. Og det er på et ledelsesniveau.

• Frustrationerne er store i arkitekt-teamet, både hos udviklerne og hos forretningens domæneeksperter, fordi diagrammerne ikke hænger sammen med virkeligheden, når først udviklingen er påbegyndt.

• Ledelsen i arkitekt-teamet kommer ind fra højre med påstanden om, at der ikke er blevet lyttet ordentligt efter ved overleveringerne. At X skal være Y, og at modellerne i V skal være som W.

• Der tilføres med spredt fægtning, og som månederne går uden at kunne fremføre et reelt outcome, flere mennesker til opgaven. Nogle forsvinder igen. Andre er der kun gradvist.

produkt teamet

Man fornemmer den næsten konstante frustration hos produkt-teamet, hvis opgave det er at bygge et kunde-vendt produkt, hvor en af søjlerne i fundamentet for den software er det værktøj, som arkitekt-teamet udvikler.

Det er svært at gengive produkt-teamets hovedtræk for mig, fordi jeg var ikke en del af det, og fordi det triangulære hierarki i organisationen ikke tilgodeså, supporterede eller var designet omkring en involvering fra enkelte medlemmer i arkitekt-teamet, så var det meget svært at drive en positiv forandring.

• "Vi får ikke det, vi skal bruge fra arkitekt-teamet, hvorfor?"

• "Hvis vi ikke kan få det, vi skal bruge, så bygger vi det selv."

• "Vi laver om i vores systemdesign, derfor skal arkitekt-teamet også kunne understøtte det systemdesign."

• Tovtrækkeri imellem de to ledelsesfunktioner i hhv. produkt og arkitekt-team.

Ledelsen og den virkelige verden.

Når ledelsen får en idé, sker der ofte det, at den bliver tilgodeset af velmente kolleger og samarbejdspartnere. Jo længere en idé får lov til at flyde rundt i organisationen og blive genfortalt, jo mere forplanter den sig, og på et tidspunkt kan den være svær at skille sig af med igen.

Idéer kan være nok så gode, men de er intet værd, hvis deres hypoteser ikke bliver valideret, og gerne så hurtigt som muligt. I stedet gør man, som man altid har gjort - bygger først, sælger senere, smider væk, når man indser, at man tog fejl.

Hvad skulle man have gjort ?

Det er altid svært for mig at skulle rådgive virksomheder om, hvad de skal gøre anderledes for at nå frem til et bedre udgangspunkt. Det kræver en betydelig mængde viden omkring den kontekst, et team eller en organisation befinder sig i, og derfor er det både naivt og egoistisk at tro, man kan forandre tilstanden, når ens job er at bidrage andetsteds.

Men det er ligeså meget en del af en organisationsdesign at kunne formidle og forandre tilstanden i den omstændighed, man befinder sig i. Det kan ikke lade sig gøre i en organisation, som er så forankret omkring topstyrede teams, hvor individer enten handler ud fra en leders ordre.

I dette tilfælde var der ingen tvivl om, hvordan den software skulle se ud; det var altsammen inde i hovedet på lederen. Og det blev ikke efterladt til hverken arkitekterne eller udviklerne i samme team at forandre det.

Når man ikke kan ændre ting, man er en aktiv del af, bliver man frustreret. Det er helt præcist det, som der ligger i ordet magtesløshed. Og det er hverken sundt for en medarbejder, et team eller en virksomhed. Det er som jeg skriver i Switchboard Managers, et levn.

Skulle jeg alligevel komme op med en løsning, så havde jeg:

• Samlet de to teams i ét team og rapporteret direkte til idé-ejeren.
• Havde bedt teamet lave en prototype af produktet, uden brugen af rigtig data, baseret på én vigtig forretningsmæssig egenskab (f.eks.: tegne ny forsikring).
• Valideret preto/prototypen overfor rigtige kunder.
• Præsenteret data og kunde-feedback til idé-ejeren.
• Afventet mulig omstilling på baggrund af den feedback.

(for en god ordens skyld vil jeg lige tilføje, at jeg aldrig nogensinde ville anbefale nogen som helst virksomhed, at bygge teams op omkring enkelte beslutningstagere eller ansvarsfratagere i andre teams. Billedet herover er blot et stilbillede af hvordan et enkelt teams skal kommunikere med ejeren af en idé. Og det er en god idé, fordi det får idé-ejeren til at forstå hvad det er han får tilbage fra det feedback loop som et eksperiment udløser. )

Lad os nu sige, at ovenstående ville have taget 3 mand 1 måned at lave, og så ville man pludselig have reel feedback fra rigtige kunder. Ens idé ville pludselig leve i den virkelige verden.

Derfra ville man have en valideret hypotese omkring den ene forretningsmæssige problemstilling. Den ville give indsigt i, om der skulle valideres yderligere, eller om teamet mente, det havde tro nok på data, til at gå i gang med at udvikle den ene ting, man havde valideret.

På den måde ville man spare 12 måneders udviklingstid på en idé, som ingen kunne præsentere data for, om var god eller dårlig. Det er en stor chance at tage.

Hverken velviljen, troen på ledelsen, idéen, eksekveringen, trygheden i teamet, tilhørelsesforholdet eller gennemskueligheden vokser ved at lade sin tro på egne idéer triumfere. Det er bad for business hele vejen igennem.

At gennemtvinge en idé er altså et grundlæggende tegn på, hvordan en organisation er designet, hvor nogen mener, de er klogere end virkeligheden, og hvor andre ikke er hierakisk egnet til at modsige sig det eller forandre det.

Lad være med at spilde jeres tid på at tro på jeres idéer. Det er håbløst. Få dem valideret, og validér dem gerne af flere omgange, så I trygt kan komme videre når den viser sig enten at holde vand, eller bedst egner sig til arkivet.

Side-effekten af et dedikeret cloud/devops/platform team.

torsdag den 18. januar 2024

• software/produkt/feature/* team,
• cloud/devops/platform/* team,
  • et team, som kontrollerer og er ansvarshavende overfor ovenstående teams ifbm. infrastruktur, pipelines, servere, databaser, netværk, monitorering, alerts, disk, etc.

I forbindelse med, at cloud providers, som AWS og Windows Azure, de sidste 10-12 år er blevet evangeliseret af Amazon, Microsoft og communitiet, og siden adopteret af virksomheder, er forankringen af disse i selve virksomhederne ikke meget anderledes, end hvordan man hverken anskuede eller designede sin organisation omkring de tidligere kendte "admin"/"infra" teams.

I dag kalder man det bare noget andet, fordi alle ved, at buzzwords skaber forandring, som gør ens teams i stand til at flytte sig i et mere bæredygtigt tempo.

Udfordringen er stadig kommunikation på tværs af teams, som hæmmer muligheden for, at lade de enkelte udviklingsteams bestemme og kunne tage ansvar for, hvad og hvordan de selv ønsker, at bruge det, de finder relevant for det, de bygger. Altså, det udstiller lynhurtigt, hvordan organisationen er designet omkring, hvor beslutninger og kontrol er placeret - command and control.

Fordelen ved, at lade de enkelte teams have dette mandat, siger sig selv. De bliver ikke blokeret af idle-time fra andre teams. De lærer og forankrer, hos dem selv, hvad det vil sige, at administrere den software, de bygger. Og det skaber ydermere et større tilhørelsesforhold hos teamet.

At have et dedikeret team til at styre eller forankre en platform, er en løsning, som bør leve i et absolut minimum antal måneder. Og deres fornemmeste rolle er absolut ikke at skabe flere abstraktioner, men at gøre software- og produktteams i stand til selv at kunne varetage den eller de cloud platforme, som man har valgt, at understøtte i virksomheden.

Hvad tror du, der sker, når 3 forskellige teams uafhængigt af hinanden beder det såkaldte devops/cloud-team om at få adgang til, at oprette noget infrastruktur?

En cloud-provider vil altid out-performe ens egne cloud-teams, så i stedet for, at bygge abstraktioner ovenpå, så skab en lige linje til cloud-provideren.

Vi ser den her konstellation mange steder stadigvæk. Og det fremmer ikke noget som helst godt hos teams, der er sat i verden for at skabe resultater i et så bæredygtigt tempo som muligt.

Men der er ingen gode argumenter for at lade være med, at give enkelte teams det ansvar og mandat til selv, at kunne styre sine behov direkte imod en cloud-provider. Det handler udelukkende om at kunne kontrollere og bestemme, hvor beslutningerne træffes, og det indgyder mere et strejf af positionering af magt mere end forankring af ansvar, mandat, tryghed og et devops mindset.

Sådan her ser det altså ud, når man laver et cloud team, som er flaskehals for andre teams, og som er fuldstændig identisk med tidligere infra/admin/* teams, vi kender fra de sidste 25 år.

Minder det til forveksling f.eks. om det samme design, som når man har et dedikeret DBA team?

Det her design har intet at gøre med, at lade ens software og produkt teams komme så bæredygtigt som muligt, fra A til B. Det handler udelukkende om kontrol og hvor beslutningerne træffes.

Så tror jeg, du har forstået det. Hvordan kan det ellers se ud?

Hvis vi nu lige kan etablere konsensus omkring, at det, som det handler om for at skabe resultater med software, som minimum, må være, at et team kan iterere over, hvad de har lært siden sidst, deres software blev udgivet. En stor del af mantraet i agilitet handler om feedback loops fra de mennesker, som bruger ens software. Så hvis ens team ikke har mulighed for, at udgive sin software, som de finder mest bæredygtigt, så har man fjernet fundamentet for, at lade dem lære nye ting fra de feedback loops.

Derfor må vi lave en antagelse om, at teams skal kunne udgive deres software, som det passer dem, også uanfægtet af, om de både skal bruge den ene eller den anden funktionalitet hos en cloud-provider. Og derfor er det nødvendigt for dem, at kunne kontrollere det setup selv. Og hvis et internt cloud/devops/platform/* team ikke tilbyder - og de kan ikke tilbyde det samme som en cloud provider - det, så piller man ved det mandat.

Heldigvis findes der virksomheder, som stoler på, at deres medarbejdere både kan selv og som stoler på, at de tager ansvaret seriøst. Hvor kontrollen er sluppet, fordi man har forstået for længe siden, at kontrollen også skal administreres.

De teams, der kan selv, er ofte gladere, netop fordi kulturen omkring dem er fri for kontrol og styring af beslutninger. Man stoler på dem, fordi de er professionelle, voksne mennesker, som er dygtige til deres arbejde. Hvor man finder de mennesker, er en anden historie.

Jeg har skrevet nogle tekniske ting her, det behøver du ikke bide for meget mærke i. Du skal derimod bide mærke i, at hvert team uafhængigt af et andet team kan kommunikere direkte med en given cloud provider. Og det gør de igennem det toolset, som den gældende provider stiller til rådighed, og ikke igennem et internt team.

Ting sker naturligvis ikke af sig selv, så derfor er en ikke fremført heuristik på tegningen, iblandt de forskellige teams, at der naturligvis skal eksistere en egenskab til at kunne kommunikere med hinanden. Ikke indblanding, kontrol eller bestemmelse. Spørgsmål og svar om, hvordan en udfordring kan løses fornuftigt i et enkelt team eller på tværs af flere teams ifbm. med den givne cloud provider.

Her findes der ingen teams, som har ansvar for, at andre teams kan komme videre med deres eget foretagende. Der er heller ingen teams, som bestemmer hvordan andre teams skal bruge en platform eller hvordan platformen skal se ud. Det enkelte team bestemmer fuldstændig selv, hvordan den udfordring, de står med, ift. den software, de bygger, skal løses og hvordan cloud-platformen kan afhjælpe den udfordring.

Vi har oplevet af og til, at der eksisterer en nervøsitet og bekymring omkring "cost". Omvendt har vi også erfaret, at netop enkelte software teams har en langt bedre mulighed for, at kunne svare på, hvad deres forbrug er, fordi de i modsætning til et eksternt silo cloud team, ved præcis, hvad de skal bruge og hvad de kan lukke ned for. Det ved et cloud team ikke på samme måde, fordi de ofte partitionerer ressourcer på baggrund af flere teams, og derfor bliver cost uigennemsigtig og svær at styre.

Facit er altså stadigvæk, at når man bygger software, så er det vigtigste, at få det afprøvet så hurtigt som muligt, i hænderne på rigtige mennesker. For at kunne nå derhen, skal teamet have mulighed for at udgive det sammen med dets afhængigheder. Teamet skal selv kunne bestemme, hvordan det gøres og uafhængigt af indblanding, kontrol og bestemmelse fra andre teams.

Switchboard Managers - et fortidens levn.

onsdag den 17. januar 2024

Der er et levn, som vel sagtens har sin oprindelse i tiden tilbage fra Napoleons tid. Det handler om, hvordan en organisations kommunikation flyder fra bund til top og fra top til bund. Oprindeligt havde ledere en god grund til at agere således, fordi kommunikation var dyrt og besværligt.

Men den triangulære organisationsstruktur lever stadig i bedste velgående. Her agerer managers, per design, som knudepunkter for de mennesker, de er managere for, og hvor "chain of command" stadig er en betydelig del af det at være manager.

Hvis du selv er manager og tænker, at det er en del af din rolle at kontrollere strømmen af kommunikation som et bidrag til den implicitte kontrol af eksekvering samt at skulle rapportere opad og nedad, så er anbefalingen herfra, at lade de mennesker - som du i virkeligheden burde sørge for har de rammer, de beder om - selv bestemme, hvordan kommunikationen skal flyde, og hvordan beslutninger tages.

Det er med tiden blevet debatteret (Groupthink), at en manager i et sådant hierarki ubevidst udøver en pedestal-rolle, som lægger mere vægt på at "følge lederen" end på at understøtte gruppens egne evner til at nå frem til de bedste resultater. Men også, at gruppen af mennesker, denne manager udøver sin rolle overfor, ofte ikke finder det tryghedsskabende eller evidensbaseret, at et andet menneske i den samme professionelle relation udøver sit arbejde på baggrund af sin position i et hierarki, i stedet for at bruge sine kompetencer til netop at fremme gruppens muligheder.

Kommunikation mellem os er ikke længere hindret af teknologi; den er fuldstændig gratis. Og fordi målet med at kommunikere med hinanden, i en professionel sammenhæng, ofte handler om at nå til konsensus frem for at fremme sin egen position over gruppens fælles position, bør gruppen kunne løse deres egne udfordringer gennem diskussioner, validering, tests og evidens. Det bør en manager kun observere og støtte gruppen i.

Den kontrollerende og bestemmende manager er derfor en unødvendighed og en besværliggørende abstraktion, som ofte ikke gavner andre end managerens egen position og incitamenter.

Flere gange i min karriere har jeg mødt mennesker med leder- og managertitler i hierarkiske positioner, som på papiret er fordelagtige for dem til at tage bedre beslutninger end gruppen, men som i praksis efterlader gruppen med ringe muligheder for at udøve et ordentligt arbejde.

En manager sagde for nyligt til mig, i forbindelse med et softwareteam, jeg hjalp: "Vi vil gerne lave code reviews, men så når vi ikke deadlinen". Skal manageren blande sig i det? Slet ikke. Det samme gælder for eksempel refactoring. Hold jeres manager ude af disse beslutninger - det er op til gruppen at bestemme, ikke individet.

Et andet eksempel fra den virkelige verden er, hvor ansvaret ikke slipper en manager, og informationer bliver holdt tæt ind til kroppen i et forsøg på at kunne kontrollere, hvordan noget udføres. Det efterlader gruppen i magtesløshed og har desværre også den konsekvens, at manageren hele tiden forstærker sin position, fordi det udelukkende er vedkommende, der kan svare på ting.

Test din organisations Chain of Command.

Hvis du aldrig har testet din organisation for, hvordan "Chain of Command" fungerer, så prøv først at tale med dit team om at ville gøre en lille forskel, der forbedrer jeres tilstand, og som I finder absolut nødvendig for jer. Derefter se, hvem der først beder jer om en forklaring herpå og om, hvorvidt I skal tilgives eller fejres.

Som jeg tidligere har beskrevet, skal man i software- eller produktteams på ingen måde lade en manager bestemme, hvor meget og hvor lidt der skal refaktoreres i en kodebase, før teamet kan stå inde for en given ny feature, udførelsen af en bugfix, kvaliteten af tests osv. Det skal manageren blot støtte dem i.

En manager bør heller ikke blande sig i hverken tekniske designs, teststrategier eller, hvordan teamet mest fordelagtigt finder det gavnligt at udgive deres software. Hvorfor skulle de gøre det? Er det ikke professionelle mennesker, I har ansat til at varetage disse udfordringer?

I stedet for at lade din manager agere proxy over for andre teams, som I samarbejder med, så lad teamet selv bestemme, hvordan det ønsker at samarbejde med andre. Hvorfor skal en manager blande sig i det? Managere bør understøtte solidariteten og demokratiet i et team og sætte rammerne for, at teamet har det bedste udgangspunkt for at blive en succes.

Der er sket en del siden nitten-hundrede og hvidkål

"Chain of command" handler blandt andet om en organisatorisk tro på, at enkeltpersoner i et trekantsformet hierarki kan udstikke ordrer samt styre kommunikationen og kontrollen op og ned, alt sammen med troen på, at dette medfører bedre resultater.

Udfordringen er blot, at vi ikke længere befinder os i en verden, hvor det er svært eller dyrt at kommunikere (command) med de rigtige mennesker og derigennem optage den nødvendige viden for at kunne tage beslutninger (control).

Så når du hører eller oplever disse ting, vær forsikret om, at grunden til, at de eksisterer, handler om, at organisationen i så fald ikke har ændret sig i denne henseende, med forståelsen af, at det ikke længere er dyrt at kommunikere til siden, skråt op eller bare til den person eller det team, der nu engang er nødvendigt. Sådan fungerer vores verden ikke længere; vi er tættere forbundne, og derfor behøver managere ikke at agere proxy eller knudepunkt for hverken beslutninger eller kommunikation.

Når noget er billigt - som kommunikation - kan det ofte komme til dig i en overflod. Og derfor er det naturligvis ikke et spørgsmål om "hvordan vi kommunikerer" men "hvorfor vi kommunikerer". I en verden af billig kommunikation kan vi være sikre på, at alle, der mener, de har noget at bidrage med, vil gøre det. At kunne håndtere kommunikationen - at sikre sig kvalitet i den - det er noget, vi alle skal øve os på hele tiden.

Husk at læg mærke til Peter og Shirky princippet

Peter princippet: "ansatte i en hierarkisk organisation vil blive forfremmet indtil de når deres niveau for inkompetence."

Shirky princippet: "Institutions will try to preserve the problem to which they are the solution"

Pournelle's iron law of bureaucracy

"In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals that the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely."

Tornado Konsulenten

lørdag den 13. januar 2024

opdateres løbende med tanker og idéer

Der findes en række forskellige angrebsvinkler, hvorpå virksomheder kan udnytte brugen af konsulenter bedst muligt. De fleste virksomheder har dog en forældet, industrialiseret tilgang til brugen af udefrakommende hjælp.

Der bliver solgt konsulenter til virksomheder, ofte med en rimelig interessant indlemmelse, hvor udfrakommende enten betragtes som en tilførelse af ny viden og med muligheden for at "gøre en forskel", eller hvor ansættelsen har rødder i devisen om, at "flere mennesker må betyde mere produktivitet."

Der er ikke noget i vejen med, at ansætte konsulenter på hverken den ene eller den anden baggrund. Så længe man er bevidst om hvad det gør ved ens kontekst af både team og output.

I forbindelse med udvikling af software betyder flere mennesker meget ofte mere overhead, og det forstærkes betydeligt når konsulenter ansættes som værende bedre end teamets fællesskab til at yde en kollektiv indsats.

Det er jo ikke konsulentens udfordring, at skulle styre hvordan ens komptencer benyttes på den korte bane, men det er derimod bestemt konsulentens opgave, at kunne stemme imod når vedkommende fornemmer antydelsen af, at blive isoleret med forventningen om, at skulle yde en indsats der fremmer personens egen situation, frem for teamet og organisationens mål.

Det formår mange konsulenter ikke at gøre. Og med god grund. For det første er de forhold de arbejder under ofte ikke modnet til, at kunne opretholde en midlertidig relation, samt at sørge for, at bruge konsulentens evner til udelukkende at fremme sine fastansattes kompetencer. Og dernæst er deres kontraktuelle økonomiske forhold ofte gode.

De færreste har integritet til, at fjerne sig fra et arbejde som betaler godt over en million om året. Også selvom de godt kan få øje på udfordringerne som ofte handler om alt andet end at forbedre situationen for helheden af organisationen de er midertidigt ansat i.

At være en dygtig konsulent er svært fordi det kræver, at kunne få taletid de rigtige steder hvor man er midertidigt ansat, samt hurtigt at kunne fjerne sig hvis det ikke er muligt.

Men den måde virksomheder ansætter konsulenter er i bund og grund i stykker. Det lukreres der naturligvis på. Det er bla. derfor vi også er vidne til, at udfrakommende arbejdskraft er midlertidigt ansat i flere år, uden at yde betydelig værdi.

De fleste konsulenter vil gerne gøre et godt stykke arbejde. Men de vil også gerne sørge for at de anses som så værdifulde, at de måske ubevidst arbejder sig hen imod at blive uundværelige. Det er her tornado-konsulenten kommer ind.

Tornado-konsulenten er et velkendt fænomen. Det er først og fremmest en udefrakommende, der umiddelbart anser sig selv som have nogle svar på virksomhedenens udfordringer, og derfor finder sig selv som en god løsning for virksomheden.

På den anden side - virksomheden - der tror på forøgelsen af organisationen med indlemmelese af individer som kommer med en potentiel anden og anderledes viden, øger produktivitet og kompetencer. Eller noget endnu mere lavpraktisk.

I begyndelsen af en professionel relation skal begge parter lære hinanden at kende. Og det tager som regel udgangspunkt i nogle problemstillinger som er relevante og hvor parterne diskuterer om mulighederne.

Det efterlader derfor implicit konsulenten med en allerede påtagethed af, at vedkommende bliver opfattet som værende medvirkende til en mulig løsning på en problemstilling. Og konsulenten ved godt, at relationen er midligertidig så vedkommende skal gøre sig umage for, at byde ind med de bedst mulige løsninger, for ikke at afkorte den relation.

Det er i det her spænd tornado-konsulenten udklækkes og hvor vedkommende bliver betraget anderledes positivt, netop fordi vedkommende måske har interessante erfaringer og anden viden end modparten.

Tornado-konsulenten har ofte en evne til at overtale eller brute-force kommunikere sine argumenter, både for at bide sig fast i organisationen men også for, at fremstå som værende svar-parat på det som bliver stillet op foran vedkommende.

Virksomheder og organisationer, der enten helt bevidst eller ubevidst tillader en konsulent at agere tornado, er ofte udfordret i flere henseende.

Disse virksomheder anskuer tornadoer som værende et positivt asset, fordi det udmiddelbart ser ud, som de har svarene på det meste og derfor hurtigere kan fremme deres egen produktivitet end resten af medlemmerne på et givent team.

I virkeligheden - lidt skarpt sat op - kan de betragtes som individualister, som trives bedst med, at deres arbejdsrammer beror mere på personlige bidrag frem for en solidarisk team-indsats. Virksomhederne er ofte glade for det, fordi det umiddelbart ser ud, som om produktiviteten øges.

Ofte vil tornado-konsulenter bidrage i en udstrækning, der udstiller dem selv som potentielt uundværdlige. Ikke på grund af deres team-indsats, men fordi de positionerer sig selv som værende bedre end resten af medlemmerne. F.eks. ved at beslutte, handle og eksekvere på tiltag, de selv har opfundet. Og fordi virksomheden tillader det.

Det er ikke en humanistisk tilgang til at bidrage positivt, og det er ofte uretfærdigt for teamet, når en tornado-konsulent ansættes.

Omvendt kan det være svært, som hvilken som helst konsulent, at spille sig selv ind i en organisation, når det er klart, at netop selv samme organisation ikke har formået at drive deres teams i en autonom form og som selvstyrende enheder.

Så på den måde finder konsulenten sig selv i et paradoks, fordi der hverken er adgang til forandring af mandat, og samtidig en forventning om, at der bidrages på baggrund af beviste ødelagte organisation strukturerer.

Konsulenten vil derfor kun have mulighed for at opnå succes ved at spille indenfor pladen af dysfunktionalitet, men vil givetvis føle sig forklejnet, fordi der ikke er adgang til at åbne de dører, hvor den positive forandring står inde bag og venter.

Altså at der er ikke et talerør direkte til ledelsen, men et adgrænset kommunikationsapparat, der ikke fører til bedre vilkår, og derfor til stadighed fremmer falsk produktivet og forkvaklet team-ånd.

Det er langt ofte en fejl, når virksomheder hyrer konsulenter som en forøgelse af et allerede etableret team. Virksomheder hyrer ofte konsulenter på baggrund af to udfordringer:

• Vi har travlt og skal bruge flere hænder (Brooks' law).
• Vi har nok arbejde i fremtiden til at kunne bruge flere hænder.

Det første er en helt tydelig fejl, som har været velkendt i 50 år, men som virksomheder og organisationer, baseret på industrialiseringens produktivitetsprincip om, at flere kan levere mere, stadig ikke har formået at ændre. Brooks' law, anyone?

Den anden grund er lidt mere subtil, men den siger ofte noget om, hvordan virksomheder tilgår deres udvikling og brug af teknologi.

Usikkerheden om fremtiden siger sig selv. Det er ikke muligt at se ind i den. Så hvis man på forhånd godt ved, at man har mere arbejde i fremtiden end man har i dag, og man ikke har kapacitet nok til at løfte arbejdsmængden, så skal man som udgangspunkt ikke hyre flere mennesker, men være fuldstændig sikker på, at ens prioritering af opgaver er velkendt og kunne svare på hvorfor.

Hvis man ikke kan det med meget stor sikkerhed, så er det ikke mennesker man mangler, men bedre ledelse ift. prioriteringer og en anerkendelse af, at man potentielt må sige nej, fordi man ikke har kapaciteten.

Langt de fleste virksomheder, som er baseret på det industrialiserede blueprint - hvor parallelle opgaver kan løses asynkront uden kommunikation - tror, at de kan få det samme output, såfremt de er flere mennesker.

Det er bare en kæmpe stor fejltagelse.

Men der findes masser af konsulenter, som trives i bedste velgående med de dysfunktionelle organisationer. Fordi de bliver betalt godt og har ofte udsigt til lange kontrakter.

En dygtig konsulent vil naturligvis forholde sig anderledes til en sådan dysfunktionel organisation, og i stedet for at forblive i det vakuum af dysfunktionalitet, vil disse konsulenter kommunikere direkte til ledelsen, uanfægtet af såkaldt chain of command, og forklare sig professionelt.

En dygtig ledelse vil naturligvis ikke blot anerkende disse udfordringer, men hjælpe med at forbedre dem.