What is the equation for success?

Let´s go to work fun.

After 9 months as CEO at Iterate I want to share some of my thoughts and actions on how we tackle globalization, Lean Startup movements, platform revolutions, millennials and everything else that predicts the 4th industrial revolution.

The equation:

Potential + (autonomy, clarity and intent) + slack = value creation + fun

Well at least this is the equation that we are trying to solve. And our hypothesis is that this is the equation to our future success.

Let me explain..

The last 10 years, the industry has been good, but the trend (in Norway at least) is that salaries increase faster than hourly rates. We are looking into a future of squeezed margins and we have to deal with that one way or another. Lower margins can normally be compensated with higher volume. That is a reasonable logic when you talk about products on a shelf, but not necessarily true when you are dealing with people. We do not believe that we will create a better work environment if we triple in number of employees.

The industry is changing. Luckily we se less of big pre-planned project tenders and more requests for getting the right person on the right task. At some point this might make the consultancies redundant as we don’t need big companies to carry constructed contract risk anymore.

The reality of the market, and our vision of simply having the best workplace in the world, just will not coincide. Lower margins means less fun enabling money. The obvious economical factor and our curiosity about the creative potential of our employees have made us wonder…

Looks like we have a transformation on our hands. Luckily, we have all the skills necessary to start this journey. Transformation is exactly what we do for our customers, so let’s do it for ourselves this time.

Potential.

We have always focused on hiring the right people and worked systematically on developing them to become even better. Choosing the right customers with challenging  assignments using new technology has been a good combination for us. Therefore, I believe we have great potential in our employees.

Autonomy, clarity and intent.

The literature is full of evidence that autonomy is a key to productivity for knowledge workers. From my own experience this is true. When you deal with highly educated, ambitious and motivated employees you have no choice but to trust them to make their own decisions. If you don´t, they just leave.

The hard part as a leader is to give clarity to what we are trying to achieve as a company. If autonomous persons and teams autonomously drift in different directions, we will not succeed. As a former project manager I know the importance of expectation management. The second you step out of that meeting where you all seemed so aligned, the expectation start to diverge. To maintain clarity and alignment I have to constantly remind the organization of what we are trying to achieve without coming off as fussy.

Pro tip: Give employees responsibility, guidance and then back off!

Slack

No, not the team collaboration tool. We’re using it, but I mean real slack as in lowering the utilization of employees. This is where it gets really hard, because this means investing money or accept lower economic results. I can do that because the board of directors introduced slack from the very top. As CEO my mandate from the board is to hit a 5% profit margin. Compared to an industry standard of 10%-15%, or even higher for the really “profit margin driven” ones, that´s a lot of slack. I have several millions (NOK) worth of slack at my disposal. Wait a moment – doesn’t this make me an investor?

So, what do you normally do as an investor?

You find a company that is apparently underestimated and you put your money into it.

Easy, right?

My version of putting money into an apparently underestimated company is to give my own employees time to play with ideas that someday might end up as the next big thing. Allow for time to procrastinate, so that they can be more creative. And most important, allow failure, so that we all can learn from them and make better decisions later on.

We are “trained killers consultants”. We have been drilled on what to do. We consult, we invoice, we upsell. If we have spare time, we find a customer that is willing to pay for that time. This is optimization for the consulting business model, and we are pretty good at it.

My job is to say no!

Trust me, It´s really hard to say no to customers when you do have spare capacity, but it´s necessary to do so to get where we want to be. Breaking out of this “trained killer consultant” mindset is hard, but we are getting there.

Oh, and before I forget. Introducing slack like we do, probably will not work that well if you have an incentive model based on profit margin. Let everybody own the company instead. That way you are in the same boat.

Value creation

So, where do we want to be? The reason we became engineers, designers and business developers is because we really want to accomplish something. The timing is now. We have created value for our customers for 10 years already, so we know we can. Our own shots at creating value in new and existing markets with value adding services, platforms or whatever it takes.

We call it Iterate Ventures!

Fun

It´s not about doing company outings and goof around all the time, but the best reward I get as a leader is to see people genuinely  love their work. Too many people work to earn money so they can afford time off to spend on what they are passionate about. Why don’t we try to create win-win situations instead? If we can let people work on what they are passionate about, they have fun at work. If we can put a good business model on top, we might just strike some gold eventually.

It´s all about creating a culture where we take care of each other, where we can be creators and maximise for utilization of potential, not capacity.

A great example of how this culture really manifests itself is this years “Iterockalypse” festival:

Me: We should arrange the annual Iterate party with customers, employees and friends.

Employees: OK

Me: Do you need me for anything?

Employees: No, not really.

Result:

So, what’s the worst thing that can happen?

– We just get a lot better at consulting.


By Rune Larsen – CEO Iterate AS. Written with valuable feedback from Anders Haugeto, Kim Leskovsky, Charles Michelson, Fredrik Pettersen, Jonas Feiring and Torve Indahl.

Flex med bokser

Flex med bokser: Magnus Dæhlen from JavaZone on Vimeo.

Hva er Flexbox?

Flexbox, eller “CSS3 Flexible box layout”, er en CSS layout som gjør det enklere å implementere dynamiske nettsider. Flexbox har vært under utvikling over flere år, men det var først i fjor det fikk stor oppmerksomhet. Mye av dette skyldes at Flexbox ble den valgte layouten for React Native.

Med dagens antall mobile enheter begynte arbeidsmengden å bli tyngre og tyngre for CSS-en til hver enkelts nettside. I dag finnes det utallige forskjellige enheter med forskjellige skjermstørrelser. I tillegg kommer mange av disse med muligheten til å vise innhold både vertikalt og horisontalt. Tidligere brukte man media queries i CSS til å løse problematikk rundt struktur for forskjellige enheter. Med dagens antall enheter blir dette uhåndterbart. Flexbox kom som et svar på at ikke var noe klar måte å strukturere dynamisk og responsive nettsider. Dette ble også et stort problem med nettsider der man har et ukjent antall elementer som kommer inn i DOM-en, som nesten alle webapplikasjoner har i dag.

Per dags dato er Flexbox fortsatt en såkalt Candidate Recommendation, men det er bare et spørsmål om tid før det er en W3C-standard. Alle dagens nettlesere har full Flexbox-støtte (med mindre en regner eldre versjoner av IE som en nettleser).

Hvorfor bruke Flexbox?

Å strukturere en nettsiden som inneholder et ukjent antall elementer kan være utfordrende. Mye kan løses med mange av dagens gridløsninger, som for eksempel Bootstrap sin, men det krever ofte mer CSS og mye kunnskap om hvordan CSS oppfører seg. Flexbox krever lite CSS for å gjøre operasjoner som før var vanskelige. Å sentrere alle elementene i en div kan nå gjøres med bare to linjer CSS:

display: flex;
justify-content: center;

Men Flexbox er ikke en silver bullet. For eksempel vil jeg ikke anbefale å utelukkende bruke Flexbox som layout. Det vil være flere steder der antall elementer er kjent og dermed ikke trenger noe dynamisk layout. Da vil det være fornuftig å skrive sin egen CSS for rammene eller bruke et tredjeparts grid-rammeverk. Du kan tenke deg at et grid er rammen til et bilde, mens alt inne i bildet er Flexbox.

Sist vil jeg påpeke at Flexbox gjør layout-bygging morsomt. Det er enkelt å flytte elementene i en div uten å måtte slåss med bredder, wrapping og andre utfordringer.

Flexbox 101

Så litt mer teknisk hva det faktisk er. Flexbox kan deles i to, ett sett med container-sentrerte kommandoer og ett sett med item-sentrerte kommandoer.

ci

Det første man må lære seg er det “the magic word”, display: flex . Det definerer at containeren din skal få layouten Flexbox.

.my-container {
display: flex;
}

Neste steg er å lære seg at når man bruker Flexbox så snakker man om en hovedakse og en crossakse. Hovedaksen er aksen du vil fokusere elementene rundt. Dette kan være x- eller y-aksen etter hva du definerer. Crossaksen vil være den motsatte aksen av den du definerer som hovedaksen.

Så hvordan gjør man det? Det gjøres slik flex-direction: row/column . Row er x-aksen og column er y-aksen. Én kan også reversere dem ved å legge på -reverse etter. Man kan også definere om elementene skal wrappe når de blir for store for boksen eller krympe slik at de passer. Det gjøres med flex-wrap. Under er et eksempel med flex-direction og flex-row pluss attributtet flex-flow som er 2 i 1.

.my-container {
flex-direction: row;
flex-wrap: wrap;
//COMBO!
flex-flow: row wrap;
}

Den kanskje viktigste tingen å lære seg er attributtet justify-content. Den sørger for å holde styr på hvordan elementene dine legger seg på hovedaksen. Se eksempel i paragrafen om hvorfor Flexbox.

just

justify-content

Det siste attributtet vi viser er align-items. Det er rett og slett det motsatte av justify-content. Det bestemmer hvordan elementene legger seg på cross-aksen. Altså den motsatte aksen av justify-content.align.png

For eksempel om din cross-akse er satt til Y og man har en satt høyde så kan man definere hvordan elementene skal legge seg i høyden.

.my-container {
justify-content: space-between;
align-items: center;
}

Tilslutt

Flexbox er her for å bli. Dermed vil vi sterkt anbefale å lære litt av hvordan det fungerer, enten jobber daglig med CSS og HTML eller bare litt. Det er også enkelt å starte med og enkelt å se endringene man ønsker.

W3C jobber også med en standard for et grid, “CSS Grid Layout”, som kanskje vil ta over for alle tredjeparts gridløsninger som finnes i dag.  Vi gleder oss allerede til å bygge dynamiske nettsider med både Grid og Flexbox. 

Noen tips til hvor man kan starte å leke med Flexbox:

CSS Tricks har en veldig god tutorial på sin nettside, CSS Tricks
Flexbox Froggy er et spill som går utpå å plassere froskene på sine respektive blader med Flexbox. Det gjør læring spesielt morsom. flexboxfroggy.com

Gogo start flexing!

Eksterne lenker:

 

Lean Summer 2016: De to første dagene

erik

Slik ser jeg ut.

Hello, World! Jeg heter Eirik og er en av studentene som jobber hos Iterate sommeren 2016. Iterate er et konsulentselskap med rundt førti ansatte, og vi er syv studenter som skal jobbe her i sommer. Vi er seks IT-studenter, der fem er fra NTNU og én er fra UiO, og én grafisk-design-student fra Westerdals.

I går var første dag på jobb. Iterates kontorer ligger ikke så langt fra Karl Johan. Men på tross av god beliggenhet og nøye planlegging av reisen, hadde jeg bare et par minutters margin da jeg kom inn døra den første dagen. (Programmerer-lærdom én: Estimering er ingen enkel sport.)

alle.jpg

… og slik ser resten av oss ut. Fra øverst til venstre: Julia, Anders, Andreas, Ingrid, Hogne og Thor Håkon.

Continue reading

Hvordan få til endring – del 1

En lørdag i 2000 i Chicago fikk kinogjengere utdelt store bokser med gratis popcorn før de skulle inn  og se filmen Payback. De fleste mottok gledelig de enorme boksene med popcorn, og gikk med på å ta med seg bøttene ut og levere dem tilbake etter filmen. Det de ikke visste var at de var deltakere i et eksperiment.

Denne teksten handler om endringsledelse, og en av utfordringene med å få gjennomført en endring hos seg selv eller hos andre. Skal man endre ens egne vaner, få til endringer i en organisasjon eller i et samfunn, er det mye det samme det handler om; klarer du å få folk til å oppføre seg på en annen måte enn det de gjør i dag? Suksessfull endring følger et mønster, og skal du få til en endring kreves det at du gjør tre ting samtidig.

Tilbake til kinogjengerne i Chicago. Popcornet de fikk utdelt gratis var av billigste type. I tillegg var det seigt og flere dager gammelt. Det var forskjellige størrelser på posjonene, men alle var så store at det skulle være umulig å spise opp popcornet man fikk utdelt. Eksperimentet ble gjennomført av Brian Wansink ved Cornell University, og gikk rett og slett ut på følgende; ville de som fikk de største porsjonene spise mer? Så alle bøttene med popcorn ble veiet før og etter kinofilmen.

Resultatet stemte med hypotesen til Brian, men var likevel overraskende tydelig; de med de største porsjonene spiste 53% mer enn personer med mindre porsjoner!

Her er det viktig å huske på at det var snakk om dårlig og gammelt popcorn, alle porsjonene var gigantiske, og popcornet var gratis. Det skulle ikke være noen grunner til å trykke i seg så mye popcorn som mulig. Undersøkelsen ble gjennomført flere ganger, ulike steder og med ulike filmer. Resultatet var alltid det samme:

Continue reading

Konsulenteriet må dø!

av Erik Assum / erik@iterate.no / @slipset

Dette er en transkribering av min lyntale på JavaZone i år. Det er ikke ordrett, men innholdet er relativt likt.

Introduksjon

Jeg kommer i denne blog-posten til å snakke om konsulenter, prosjekter og forvaltning, så jeg må begynne med å definere i alle fall disse begrepene. Deretter skal jeg si noe om hvordan jeg mener man bør bruke konsulenter. Dette holder jeg opp mot noen vedtatte sannheter jeg mener finnes om IT, og tilslutt en oppsummering.

Definisjoner

Wikipedia definerer en konsulent som

en tjenesteyter som i en profesjonell ramme tilbyr sin ekspertise innenfor et visst fagfelt, vanligvis i et begrenset tidsrom

I dag finnes ordet konsulent også brukt om innleid ekstrahjelp uten den kompetansen vi tradisjonelt forbinder med begrepet

Samme nettsted definerer et prosjekt som

En innsats som gjøres for å oppnå et definert mål, som oftest innenfor en planlagt tids- og ressursramme

Selv definerer jeg forvaltning som

Et sted der systemer laget i prosjekter bemannet med konsulenter blir sendt for å dø

Konsulentbruk

Så hvis jeg mener at konsulenteriet må dø, mener jeg da at all konsulentbruk er ufornuftig? Det enkle svaret er nei. Det litt utfyllende svaret er at man skal bruke konsulenter når man har korte og avgrensede oppgaver utenfor kjerneområdet. Eksempler på dette er f.eks om du skal bytte fra websphere til tomcat, flytte fra svn til git eller sanere noe gammelt ræl som ingen bruker lenger. Det viktige her er at det er konsulenten som er domene-eksperten. Ikke kunden.

En annen god grunn til å bruke konsulenter er fordi du mangler kompetanse og trenger hjelp til å komme igang. Eksempler på dette vil være å få opp et CI/CD-miljø eller begynne med et nytt programmeringsspråk som Clojure. Igjen er det konsulenten som er domene-eksperten og kundens mål vil være å nytte godt av denne ekspertisen for å unngå fallgruver og komme seg fortere igang.

Konsulenteriet må dø!

Så hvilken bruk av konsulenter er det som er så feilaktig at jeg mener at det må dø? Det er når man bruker konsulenter til oppgaver som ligger i de fast ansattes domene. Fordi da er ikke lenger konsulenter ekspertene. De er vikarer.

Grunnen til at jeg bryr meg om dette er at jeg mener at en slik bruk av konsulenter koster langt mer enn det smaker. For konsulentbruk er et optimaliseringsproblem, som så mye annet. Og for slike problemer må man kjenne både gevinster og kostnader. Dessverre er det også slik at en del av de gevinstene man ser for seg kommer man aldri til å ta ut. Det blir som å kjøpe opsjoner uten å utøve dem. Og det er jo bare dyrt.

Vedtatte sannheter om IT

De skulte kostnadene ved bruk av konsulenter, sånn rent bortsett fra at de som regel er dyrere enn faste ansatte forblir skjulte fordi kunden tror på følgende sannheter om IT.

IT er kun en utgiftspost

Fordi IT kun er en utgiftspost er det fint å kunne skalere ned i dårlige tider. Av samme grunn er det fint å kunne bytte ut dyre konsulenter med billigere vikarer som er like bra. Poenget her er at det er ytterst få bedrifter som klarer seg uten IT. Man må innse at for å lykkes idag, må IT integreres på alle nivåer i forretningen. IT må være forretningen , forretningen må være IT.

Domenekunnskap er uviktig

For at IT og forretning skal kunne jobbe sammen og komme med de beste løsningene på de vanskeligste problemene, må IT forstå forretningen bedre enn forretningen selv. Da nytter det ikke med vikarer som løper ut døra så fort prosjektet er overlevert til forvaltning.

IT systemer blir ferdige

At Politiet fortsatt bruker Straffesaksystemet som ble levert i 1979 er bare trist. Det som hadde vært kult var om politets Straffesaksystem hadde vært topp moderne og i kontinuerlig utvkling siden 1979.

Fordi vi anser systemer som levert, og ikke foredler dem over tid, blir de tilslutt helt ubrukelige og må byttes helt ut, ikke ulikt Svinesundsbroen. Men fordi man ikke har hatt noen kontinuerlig utvikling, har man ingen utviklere og man må inn med konsulentene, som må lære seg domenet som de ikke kan noe om. Og fordi man nå endelig skal få et nytt system, må man passe på at man får med seg alt man har savnet de siste 30 år, pluss litt til. Og når systemet blir definert som ferdig, enten fordi budsjettet er brukt opp, eller tidsfristen overskredet, forsvinner konsulentene med tilhørende domenekunskap ut i nye oppdrag i nye domener, og tilbake sitter brukerne med et system som ikke virker, hverken idag eller i framtiden.

Tilslutt

IT har kommet for å bli

Det er veldig få bedrifter eller etater idag som sier at, nei, IT er
ikke noe vi satser på. Manuelle rutiner holder lenge for oss. Idag må alle
IT systemer være under kontinuerlig utvikling, bortsett kanskje fra de
som ingen bruker.

Konsulent eller vikar?

Så hvis du er konsulent idag, bør du tenke deg om. Hvis du sitter ute
i oppdrag og egentlig bare er en midlertidig ansatt fordi kunden
ikke klarer å ansette folk, bør du kanskje heller hjelpe kunden ved å
forklare på en pen måte hvorfor de ikke er attraktive. For din rolle
som konsulent bør være ekspertrollen. Den som kan noe som kunden ikke
kan.

Men dersom du sitter ute i et tidsbestemt oppdrag og hjelper kunden
med å bli bedre på ting den ikke kan, eller løser et problem som
ligger på siden av kjerneområdet, så synes jeg du skal klappe deg selv
på skulderen og gratulere deg selv med å ha funnet et godt
konsulentoppdrag.

Experiences from ReactEurope

At the beginning of July, Truls and I went on our first work trip abroad to attend the first ever ReactEurope conference in Paris. A two-day conference dedicated to the very popular React.js, a frontend library made by Facebook, and other related topics. Despite of an intense heatwave in southern Europe and the lack of an A/C that could cool down 700 people in a single venue, we still feel that the conference was a great experience. There were many great speakers who presented interesting topics and we learned a lot from their talks. The speakers include the creators of React.js, React Native, Flux, ImmutableJS, GraphQL, Relay, Babel, Redux and React Router, all important parts of the React ecosystem. We also had many enlightening discussions with other attendees.

A lot of people in a not-so-big and no-A/C venue.

Continue reading