Fimbul

Som konsulent så går jeg på jobb, jeg jobber åtte timer, og når dagen er omme så sender jeg kunden en faktura for åtte timers arbeid. Hvor langt kan det egentlig skalere? Og hva er egentlig alternativet?

Digitale tjenester og produkter har den fordelen — og ulempen — at de lar seg reprodusere. Enkelt og med lav kostnad. Har du først skrevet en bok, koster det nesten ingenting å lage ett eksemplar til. Og ett til. Og ett til.

Fordelen er åpenbart at straks det kreative arbeidet er gjort, så er jobben med å fremstille eksemplarer rask og rimelig. Men ulempen, derimot, er at det for kundene ofte kan fremstå som at det du har er gratis. At det ikke koster deg noe å lage et eksemplar til. Kan du ikke bare sende meg den PDF-en, da? Du har jo allerede laget den?

Hvordan priser du egentlig digitale produkter og tjenester?

Hvordan får du gjort ting på jobben? Hvem jobber du med? Hvordan jobber dere sammen? Og hvem har bestemt at det skal være slik?

Vi trenger å snakke litt om estimater og estimering. Elsket og hatet. Begge deler av gode grunner. Finnes det egentlig gode grunner til å estimere arbeidsoppgaver? Og når bør man i så fall gjøre det?

Det finnes et uttrykk som heter «If it works, don't touch it!». Jeg slår heller et slag for uttrykket «If it works, touch it!» Om risiko knyttet til å la fungerende kode og løsninger forbli urørt over tid.

Husker du din første faste jobb? Og din aller første arbeidsdag? Om viktigheten av å ansette nyutdannede.

I bedriften hvor du jobber, er dere kostnadsfokusert eller er dere innovasjonsfokusert? Og da spør jeg ikke om hva du ønsker at dere skal være, men hva dere faktisk er. Og hva dere bør egentlig være?

Hvordan skal din bedrift vokse videre? Mer av det samme eller kanskje prøve noe helt nytt? Om kategorisering av alternativer for vekst.

Du som arbeider med produktutvikling og skal lage nye produkter eller tjenester som folk trenger og vil betale for. Mulighetene du har er mange, og med så mange muligheter å utforske, hva bør du utforske først? Hva bør du bruke tiden og pengene og kreftene på? Hvordan vet du at det ene er viktigere å utforske før det andre eller tredje? Og hvis du ikke vet, hvordan velger du? Vi snakker om én mulig måte å tilnærme seg problemet på.

Hva gjør du når ting går ned? Når ingenting fungerer og ingen vet hvorfor? Hva gjør du når det brenner på dass? Ting å tenke på for deg som leder og hvordan man skaper god stemning også når ting er vanskelig.

Liker du at dagen i dag er mest mulig lik dagen i går? Eller foretrekker du at dagen i morgen blir litt bedre enn dagen i dag?

Jeg aner ikke hva du driver med på jobb, men kan det du driver med være så vanskelig, da? Om å ha nok innsikt for å ta bedre beslutninger.

OKR har vært et buzz-ord de siste par årene. I Fimbul får du vite hvorfor jeg liker OKR og hvilke erfaringer jeg har gjort meg med dette rammeverket.

Gjærbakst og programvare har én ting til felles. Sakte, sakte gror de større uten at du ser det.

Tradisjonelt har ofte toppledere økonomibakgrunn. Men hva gjør man når økonomisk styring kan overlates til andre enn toppledelsen?

Hvorfor er det slik at noen produkter og tjenester overlever mens andre dør? Hva kjennetegner egentlig et godt produkt?

Alle bedrifter har en intern bedriftskultur som påvirker hvordan man jobber og hvordan man oppfattes fra utsiden. Men hvordan arbeider man egentlig med bedriftskultur?

Hva synes jeg er viktig når man driver teknologiledelse fra hjemmekontoret?

Det finnes mange måter å tilegne seg kunnskap på, men en av de vanligste måtene lider ofte under et litt uheldig bias. I denne episoden snakker vi om forskjellige bias generelt og survivorship bias spesielt, og hva du kan gjøre for å kompensere for det.

Der vannfall er en betegnelse for hvordan man tidligere gjennomførte IT-prosjekter gjennom langtidsplaner, er smidig samlebetegnelsen på motstykket som gjør deg i stand til å reagere raskt på endrede behov og få bedre kvalitet og fremdrift i alt du lager. Men hvordan blir man egentlig smidig?

Teknisk gjeld er et begrep i IT-bransjen som beskriver den delen av en IT-løsning som man burde forbedret. Men hvordan forholder man seg egentlig til teknisk gjeld? Hvordan måler man det? Hvordan sørger man for å ha den på et akseptabelt nivå? At det ikke er for mye av den? Eller for lite?

I Norge gjennomføres det fortsatt IT-prosjekter på samme måte som man bygger hus. Er det rart det går galt?

I motsetning til hus har ikke programvare har en tilstand man kan  kalle «ferdig». Man etablerer en minimumsløsning som dekker  minimumsbehovet, så tar man programvaren i bruk og videreutvikler den i  tråd med hvordan programvaren brukes og behovene endrer seg over tid.

Dette tatt i betraktning finnes det ingenting som et «IT-prosjekt».  Det er snarere snakk om en hel livssyklus. Programvare er organisk. Det  oppstår og det brukes og det videreutvikles og når utviklingen stopper  opp dør programvaren.

Å ha «vært ute en vinternatt før» er et uttrykk for erfaring,  innsikt og kunnskap. I følge den norrøne mytologien er fimbulvinteren  den harde, tre år lange vinteren forut for ragnarok, verdens undergang.

Fimbul er en podcast om hvordan teknologien endrer samfunnet og  utfordringene teknologiskiftene fører med seg for samfunnet, mennesker  og bedrifter.

I Fimbul snakker vi om alternative måter å forholde seg til og  eksperimentere med teknologi, og hvordan man blir bedre rustet for  vinternatten.