Skip to content

Why we accept Bitcoin

12. June 2014

Since its launch in 2009 Bitcoin has become accepted in increasing numbers of shops and services around the globe. As of writing this post there are 9326 places listed on and 4359 on If you happen to have Bitcoins, you can use them to pay for pizza, manicure, artworks, web hosting, geeky t-shirts, online dating and even Space travel. But why did an IT consultancy (aka: we) decide to accept Bitcoins, and to deal with it at all? Few weeks ago an article was published in a local news-site (in Norwegian) about us accepting bitcoin where we gave some reasoning. We thought to take it one step further and talk a bit more about the “why” behind it.


Because Community

It all started with our developer Jakob, who showed great interest in Bitcoins. Since then we held sessions both internally and openly about introducing Bitcoin to people (see picture). For free, because sharing is caring. Here in Norway Bitcoin enthusiasts just started to form nests of interest. Here is one facebook group operating in Norwegian and this meetup group mostly in English.

Bitcoin for beginners - intro to the “what” and “how” of Bitcoin

Bitcoin for beginners – intro to the “what” and “how” of Bitcoin


Because Open Source!

Bitcoin is an open-source currency, and open source principles were always close to our heart. Collaboration, transparency, sharing and empowerment is just a better way to build software – or anything new. In case you are not hooked yet then I can warmly recommend this or this article.


The fun of learning and playing around with new stuff

Playing and experimenting is an important part of our work-culture. We nurture new ideas and and let everyone play around them. Since the first sparkle of interest showed up in the office already at least 5 people bought bit-cents in the company. I myself have 0.04 bitcoins and learned a great deal of new tech (thanks, Jakob). And we will all be millionaires in a few years from the rising value of Bitcoin, just like this guy!

…Well, probably not, as Bitcoin is extremely volatile and is subject to speculation. The point is that it is totally worth using few bucks to experiment around something new and fun.


Because innovation

Technology adoption life cycle

Technology adoption life cycle


We spend quite a lot of time working with innovation and have special interest in change that might or might not disrupt the market. An essential part of innovation is the ability to see the potential of an idea applied in other industries or context. Just like any other new inventions, Bitcoin for sure has lots of untapped potential. It´s extremely interesting to be with from the beginning and watch it scale (Or die. Who knows.)

Regarding the scepticism and regulatory gaps around cryptocurrencies I bet it will take a while till our first client shows up with the will to pay our services with Bitcoin. (Note to our Office Administration and accountant: just chill, no need to freak out. Yet.) Innovative ideas take their time to scale. But we nevertheless did our first step to be Early Adopters.

About us: Iterate is a group of skilled coders with business interest and business developers with IT interest. We combine entrepreneurship and growth strategy to develop digital solutions. Our drive is IT and innovation.  

About the author: Rita works with creative development and background logistics. She can´t really code, but loves to learn and experiment with IT, and tech in general.

Poisonous projects kill your organisation silently

2. June 2014

(n) toxicity (the degree to which something is poisonous)

Management of an organisation that is quite obviously based around products but chooses to see everything as projects creates a mismatch between how an organisation is run and what they try to accomplish. The structure in use to enable the accomplishment of work defines the foundation which future work is built on.

You would not, I hope, build a sprawling villa on ground that does not carry, lest you do not seek to repeat a classic scene from Monty Python and the Holy Grail:

“When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built it all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that’s what you’re going to get, Lad, the strongest castle in all of England.”

There are several lessons to be extracted from that quote about trying and failing, iterating, feedback loops, starting over, et cetera. Our focus is on the obvious one; do not build on unstable foundation.

A project by definition is something that should be accomplished with a fixed amount of resources within a fixed timeframe. When the goals are achieved the project is dee-oh-en-ee:  done.

Ergo projects have limited lifespans, which is something products do not. A product strives to live as long as it can. If it cannot pay for its own way in terms of further development and operational costs it is proven to not have a place in the market in its current form.

A few trends that emerge every time I work with an organisation that has structured themselves around projects can be summarised by this little tale about a man collecting sticks.

At first he can collect sticks he finds in one hand. Then, under his arm, and following that he lashes sticks together in bundles and carries them on his back, leaving his hand once again free to pick up sticks and the cycle can repeat itself.

If the man continues without any success/fail criterias he would never build his fire, never cook his meal and never reap the benefits of his work. He would keep collecting stick after stick and carry them until his back breaks from the load. Naturally a man has psychological and physiological inhibitors that would cause him to stop long before his back breaks, but an organisation does not have these self-regulating functions and can quite easily pave the way to its own demise as a result.


Structuring work around products instead of projects grants us these inhibitors, purely through a different approach in building the model applied throughout.


As you can see neither man nor organisation can in practice get rid of projects, and they probably should not attempt to do so either.

Think about how the two organisations approach projects. The former uses projects to manage everything, and even though a couple of projects are going well; on time and on budget, several are not going so well for various reasons and overall the organisation suffers. Their projects that aren’t going so well contain key functionality that other projects are constrained by which eliminates the choice of shutting down some of the bad projects. So more money is pumped into the failing projects, more people is added to the teams, and miraculously; something gets delivered — not as intended, not as designed, and not as planned.

By the grace of a dedicated and hard-working team that burns itself to cinder, tirelessly and ruthlessly cutting corners and Getting It Done … A cycle that many good developers have burned themselves out on, preventing them from doing good work for long stretches of time.

The second organisation is a little bit different. It has the same amount of projects that are not going according to schedule and the product these projects are run under cannot sustain itself when it’s being dragged down by these projects. This product is dying, and it can be strategic to let it die, which we will get into in a bit.

On a project-level the reasons the projects are failing are the same as for the first organisation. The difference is how the inhibitors work so it doesn’t damage the entire organisation and all other projects making better, or worse, progress. Right now, there is a choice between a new beginning and an end. We know that the product in trouble is not sustaining its own development and operational costs. We may not know why, we may have a clue, or a hunch. We might have data that tells us the market fit isn’t right, data that tells us users are not using it as intended, we might have a lot of things, but we know it is not self-supporting.

Prepare the pivot.

Or the axe.

I am not saying that amputating a product is a pain-free procedure but much like amputating a gangrenous limb it might very well save the patient. A project that is believed so necessary for the organisation that there exists no possibility to cancel it, is a project with a high amount of inherent toxicity. The project is very poisonous and there exists no known anti-venom. It will linger. It will spread to other projects no matter how well isolated they seem to be. The edges become fringed and productivity drops. Technical debt amasses, workarounds are implemented and this festering thing causes project after project to slide without no seemingly good reason. The developers get blamed for lower effectivity now versus a year before. Nothing else has changed — it has to be demotivated employees. Cogs are exchanged, moved around, shuffled like a deck of cards in hopes of a change in the daily grind will yield a boost in morale.

But the beast has taken hold.

Once an organisation has been dragged down far enough the stakeholders demand action. Someone is fired. A new face takes the reigns and tries to ride the beast. The beast claims another victim. This cycle repeats itself until the replacement has mandate to restructure the organisation in his image. The beast has finally spawned an offspring in his image, further spreading poison up the chain, the project with the ultimate level of toxicity: the project every CEO in a sick organisation undertakes in an attempt to impress stakeholders with bravado.

Cue the drum-roll.

The organisational restructure.


A very quick way to A/B-test

30. April 2014

In discussions about A/B testing, everyone usually agrees that it is a good thing. To get started, however, somebody must first have the time and the resources to build the A/B test rig. It will take weeks, and will probably involve some interesting big data technology. Also, it usually never gets priority enough to actually get done.

Read more…

Don’t hate the player, hire him!

25. April 2014

When you think about a typical successful company, who is it that comes to mind? Apple? Toyota? Ford? Those are all good examples, by all means. But what about Valve, Blizzard or Id Software? Or a company called These are all, as you might have noticed, gaming companies. And in a lot of cases, gaming companies have been miles ahead of other (IT-)companies when it comes to innovation, company culture and how we relate to our customers and community. Read more…

Serial innovation starts and ends with guidelines on the wall

4. April 2014

I wonder – what would work be like, if you and your team would agree to the following four guidelines?

I thought about having a designer work on a poster but decided it was better to monitor how many actually downloads my Keynote screenshot

I thought about having a designer work on a poster, but I decided it was better to monitor how many actually downloads this slide that I made in Keynote

1. Exploration over back-logs

There, I won’t forget it now. Phuh. Writing down future work is therapy to the overworked innovator.

Read more…

This is why I work for Iterate

31. March 2014

I have recently published quite a popular blog post Frustration-Driven Development – Towards DevOps, Lean, Clojure. My good colleague Tom Bang has pointed out that it actually shows nicely the reasons why many of us work for Iterate and why Iterate does what and how it does. I therefore republish it here under a modified name.


A post about development practices, speed, and frustration.

My wife has mentioned that she likes my passion for doing things right in software development. That made me thinking, why do I actually care so much and do not just enjoy the coding itself? It boils down to that I am not happy until my code is in production. Seeking the satisfaction of having my code used by and helping people while trying to eliminate all unnecessary mental drain is behind all the practices that I embrace and evangelize. It’s a drug I like to take often, in small doses.

practices = f(max(delivered value), min(mental energy))

So how does this relate to DevOps, Continuous Delivery, testing, single-piece-flow, Lean Startup, Clojure? It is simple.

Read more…

Lean Startup as an invisible hand

25. February 2014

Torve Indahl on Please share your opinion on what prevents lean startups in enterprise


Business cases are in most large corp the key follow-up tool to measure your projects success and growth. When business managers do the traditional thinking and “lock” the business case at the project starting point, they then also lock or restrain the projects ability to learn and change. Eg. working with a norwegian telecom post acquisition for my 2006 startup in 2008, we where following the telecom´s 1 year old pre-acquisition business case and followed that path for 4 years. The company does not exist today. Many factors played in, yes, but fore sure the set path was one.

Working with lean startup for large and SME on a daily basis and as an MSc in Business, I frequently us this mindset (lean Startup) as an invisible hand. We don´t explain everything, we just use it. We change the business cases at every board/steering group meetings and wait for them to start asking questions about way there are all this changes. We are proud then to look them right in the eye and tell them “Sorry, we were wrong the last time“. We then show them the evidence from our market experiments on why we where wrong and let them in on the discussions on what to do next. Now you suddenly are on the road of trustchanges is expected and the board executives starts digging into if we are doing enough experiments….”what about the MVP then” (yes, they start using your words).

The best part is when our “success formula for new stuff” then becomes demand. Life is good


Get every new post delivered to your Inbox.

Join 84 other followers