House of Cards: Lessons in Power and Politics for Corporate Entrepreneurs

11. February 2014 — 2 Comments

No spoilers for Season 3: Based on earlier Seasons.

Wake up your inner entrepreneur – it’s time to disrupt yourself. By hauge2.

Take Kodak, Nokia and Commodore in their prime time, and ask yourself why your company is any different right now.

Getting enthusiasm about your ideas at lunch is one thing – getting the organization behind your mission to innovate, is another.

Disobedient innovation, or intrapreneurship as we prefer to call it, requires political skills: Any good idea in an established organization is also a threat to someone (anyone who perpetuates the status quo).

Master the politics – become an effective entrepreneur

But you’re not an underdog. You’re Frank Underwood, ready to outmaneuver the opposition with political virtuosity, lean thinking and entrepreneurial charm.

Like the president, who unknowingly unleashes a monster when double-crossing Underwood in the first episode of season 1, established companies who hunger for continuation unknowingly unleash the entrepreneurs in their people. Preventing entrepreneurship is after all the cardinal sin of a technology company in its prime. Thank God entrepreneurs now learn to deal with the Washington in their companies.

Here’s how Frank Underwood would disrupt your company from within:

Hitchhiker’s Guide to… GAMIFICATION

31. October 2013 — Leave a comment

Keep It Simple, Make It Smile!

“In every job that must be done, there is an element of fun.

You find the fun and snap! the job is a game.”

— Mary Poppins

WHAT:

As a matter of perspective, to be able to understand “What is Gamification”, it’s better first to go through what it is not! Then we shall continue talking about this topic in a broader perspective.

Gamification is…

Not just for marketing or sales
Not just Points, Badges and Leaderboards
Not making everything a game
Not rocket science! Ha!

What is it then?

There are plenty of experiments going on about this topic, together with the challenge of making a definition for this emerging area. I took the liberty of picking a simplistic definition which was mainly coined by Kevin Werbach.

Gamification is…

The axis of serial innovation

15. August 2013 — 3 Comments

@hauge2: What are the characteristics of organizations that help its people innovate? Vice versa: What do they look like, organizations that unintentionally obstruct creative work?

Innovation can be categorized from continuous (improving existing products, e.g. the Hybrid car) to disruptive (changing an entire market, e.g. the digital camera). In order to understand serial innovation – companies that succeed with innovation over and over again – I however believe we need an additional organizational dimension:

How can we classify established organizations doing innovation?

Simply putting “customers” or “innovation” in your value statements just wont do it.

So what could be the labels of my organizational dimension? New vs. established? Top-down vs. bottom-up? Independent vs. embedded?

7 questions to innovators

14. March 2013 — 2 Comments

We’ve outlined 7 questions to innovators in established organizations. Each question has two possible answers, but you may only choose one of them.

The good news is: If you choose the latter, you may eventually also achieve the former.

1. Success defined as Growth or Innovation?

Growth is about optimizing revenue and economy of scale. Innovation is about learning what works and what doesn’t. You can’t grow a product before you know the effect it has on customers.

2. To Show off or To Show the way?

Leaders that show off are driven by the expectations of the surrounding organization. This is about handling – and improving – what we already know, and have. Leaders that show they way will show – not tell – their entrepreneurs why they go to work. They make sure that great ideas win over fear of the organization. If necessary, such leaders take chances by making decisions that possibly threaten their career.

3. Solving the problems of Stakeholders or Customers?

Solving the stakeholders’ problems is about making sure you fit in the corporate puzzle. Solving customers’ problems is about learning and adjusting – possibly several times – before finding a product that customers really need.

4. Taking a Position or following a Vision?

Position is about keeping competitors from “stealing” your shares. Vision is about building great technology that solves real problems for real people, possibly making you pioneer a new market.

5. Teams expected to Deliver or Iterate?

Delivering is about launching something that looks complete and impressive, and adds to your existing reputation and brand. Iterating is about learning, in small steps, first under the radar, later in the market majorities. In the beginning of learning, dialog is your weapon (and you can’t Deliver dialog).

6. Organized around Expertise or Autonomous Units?

Expertise is about putting the most experienced people in charge, pick their brains and try to repeat their success. Autonomous units are fast-learning cross-functional squads with just enough people and skills to be able to solve problems outside your organization – without having to ask anyone for permission or help to get the job done. Such units are also expected to fail and learn from it.

7. Developing Heroes or Culture?

Developing heroes is about promoting, and keeping, key personell with skills critical for maintaining your products and services. Culture is about developing knowledge workers into great teams, who in turn can build new great teams (even when the heroes quit).

If you’re either planning for it, or your are in the middle of an innovation effort, we encourage you to discuss these questions with everyone involved. From director to programmer.

We hope it will help you discovering how you should be set up. The war is out there, and in order to win you want to get started without applying any brakes in here.

If these questions provide you with any insight, please let us know! @hauge2 @TomJohannesBang

Know your feedback loop – why and how to optimize it

1. October 2012 — 2 Comments

If you always write perfect code, know how to predict the future and don’t care how your money is spent, you don’t need to read this. The rest of you need to know this stuff.

What is a feedback loop?

A feedback loop is the path your assumptions travel before they are validated or invalidated. Naturally you will have different feedback loops for different assumptions. In this post we will discuss three levels of feedback loops that should be easily recognizable. They are:
Continue reading

Being focused is being cross-functional

31. August 2012 — Leave a comment

Some years ago, I facilitated an integration workshop in a multi team development project. Teams had been working for too long in isolation, and while everybody thought their modules were nice and shiny, none of us knew how they would fit together. So we decided to sit down with representatives from each team and integrate so that a simple use case encompassing all modules came through. There were some questions before we started whether the ambitions of the workshop were to low, as the use case we wanted to address was really simple. But we decided to keep scope low, to get an easy start.

The result of two days work was devastating. Nothing worked. For a long time, progress stopped because our servers simply weren’t able to ping each other. During the two days we constantly had to lower expectations, and we were getting increasingly worried about the presentation to management scheduled at the end of the workshop. The whole project was already behind, and now we were going to top the situation by exposing ourselves as incompetent. What could we possibly gain from this foolish initiative?

Developer’s DNA

13. April 2012 — 2 Comments

“The candidates must have at least three years of Java development and experience with four of the following five technologies…”. This is how a typical request for consultants goes, both for public and private sector customers. It clearly favors candidates with long, stable assignments behind them. It seems to be commonly accepted in our industry that the most important quality a developer can bring to a new project is experience. That may not be such a good idea.

The underlying premise here is that training makes you a more effective developer. That may be true, but only to a very small degree.

The problem is that deep tool knowledge is not where the biggest gains are. Software development is just not that trivial.

I have seen teams that have success based on criteria that are different from this kind of experience. A developer with 4 different projects in a 2 year time span take along more good thoughts than one with 5 years of experience with the technology being used. A fresh graduate with nothing to defend often asks those stupid questions that makes the rest stop and think. One who is attending meetups and reading relevant blogs takes along experiences others have gained without having been there himself.

Efficiency is not first and foremost dependant on the speed with which you can code because you have long experience with a specific tool. Efficiency comes with the one who asks if we really need to use the framework we have taken for granted. It comes with the one that had heard of the tool that ends up saving the team for weeks of work. It comes with the one who takes the time to think clearly and simplifies our process and makes everyone more productive. The efficient developer thinks like an innovator.

Development is innovation, and the best developers are innovators. The good news is that you do not have to be among the very creative to think new thoughts. You do not have to be fresh from school to ask the stupid questions, and you do not need experience from many different projects to be able to draw on other people’s knowledge.

Er nye bygninger trygge?

21. March 2012 — Leave a comment

Vi er vant til at programvare har feil. Bare husk de grufulle minnene fra Windows sin blåskjerm “blue screen of death”, som selv for Bill Gates kom på det mest ubeleilige tidspunkt (da Windows 95 krasjet under en demonstrasjon for pressen). Som brukere har vi forsonet oss med at programvare ikke er perfekt.

Enkelte av oss har nylig erfart ubehageligheter med selvangivelsen. Problemer mer alvorlige enn de vanlige ytelsesproblemene som kommer når halve kongeriket sjekker restskatten samtidig: Enkelte har til sin store overraskelse fått anledning til å se en annen person sin selvangivelse. Det er kanskje å ta offentlige skattelister en smule langt?

Vi stoler ikke på nye IT-systemer. Vi har lært oss å ikke oppgradere noe som helst rett før vi tar med oss laptoppen på hytta, eller før vi går i et viktig møte. Jo eldre programvare, desto tryggere føler vi oss, fordi tiden har luket ut de styggeste feilene.

Det er anderledes med bygninger. Selv føler jeg meg mindre trygg desto eldre bygning. En kompis bodde en gang i en loftsleilighet fra 1800-tallet, og etasjeskillerne besto av knusktørr halm. Én flamme på feil sted i første etasje, og hele bygningen hadde blitt en stor skorstein. Nye bygninger derimot, de står støtt. Bygget etter moderne metoder, og gjennomgått grundig ettersyn. Iallefall de fleste av dem.

Hva skiller disiplinene bygg og programvare? I byggeindustrien må man sikre kvalitet i hvert ledd. Du kan ikke bygge andre etasje før du vet at første etasje holder. Det er man (dessverre) ikke nødt til i programvareindustrien. Istedenfor å bygge integritet inn i løsningen, tester vi kvaliteten etterpå. Da finner vi selvfølgelig masse feil, som vi ikke har tid til å rette opp. Det er et paradoks: Vi tester for å finne feilene vi har laget, når det åpenbare alternativet er å unngå feilene i utgangspunktet.

Empire State Building ble bygget på ett år, men kanskje ikke utelukkende i små sikre steg ..

Hvorfor er det slik?

Få betalt for feil du ikke finner!

1. March 2012 — 5 Comments

På dagens frokostmøte ble det ytret frustrasjon rundt testere i ett prosjekt som så det som sin oppgave å finne flest mulige feil i applikasjonen. Og det er greit nok det, om man har rigget prosjektet sitt på en måte som gjør at det er mulig å implementere feil i utgangspunktet. Kollegaen min refererte hele tiden til “oss” og “dem” når vi snakket om situasjonen. Noe som forsterket muren som stod mellom utviklere og testere i dette prosjektet.

Dette er fra et prosjekt med den klassiske designe-alt-utvikle-alt-teste-alt-produksjonsette-alt-tankegangen (også kjent som vannfall). Ett av problemene er jo selvsagt strategien som er valgt, men hovedproblemet til min stakkars kollega er at utvikling kommer før test i et slikt sekvensielt løp. Det må jo være bedre om utviklere og testere samarbeider i større grad, tenker jeg? Noe man kan dra nytte av helt uavhengig av metode og strategi.

The 3 Most Important Things I’ve Learned This Year

26. November 2011 — Leave a comment

In Iterate we are mostly dealing with technology but why do we actually use technology? We use it because we want to help people achieve something – and in the process of doing that we have to cooperate and communicate with many humans. The human factor is far more determining for our success than any kind of technology could ever be. Why do most project fail? Because of a bad technology? No – usually it’s a failure of communication, leadership, process change. And this week I’ve learnt some very important things about this crucial human factor – and thus this post may well be the most valuable piece published here til now – or ever.

First, I’ve learned how we decide (and a project – IT or other – is nothing but a bunch of hundreds, millions of decisions, both small and big). To deal with the incredibly complex world around us, human brain has many decision strategies ranging from a very rational decision making to “gut feeling” decisions based on our emotions and subconsciousness. Every of these strategies is perfectly suitable for some situations (for example relying on emotions and intuition is often the best thing, conversely to what we’ve been thought) – and leads to suboptimal results (read: terrible failures) in others. Thus the single most important factor that determines how successful we are is our ability of metacognition, i.e. being aware of how we think, and thus being able to select the most appropriate strategy for the situation at hand. (Which might not be as easy as it sounds and may require that we “trick” our mind somehow, i.e. by distracting it or forcing it into a certain decision mode.) Jonah Lehrer documents that on the “Marshmallow experiment” – the children who knew that they got to distract themselves somehow not to eat the marshmallow, which they’ve been given, not only managed to wait those 15 minutes for another one but were also much more successful in their later lives – presumably because their ability of metacognition helped them to make better decisions more often.