Skip to the content

Circular Wonderings is an exploration of the role of digital, software and technology in the Circular Economy. Exploration is the key word here. I write regularly, reflecting on my current thoughts and research. Expect typos, incomplete thoughts, varied rambling topics and (hopefully) a journey towards clearer understanding and insight. Subscribe here to join my journey.

There is no 'answer'

Many of the businesses working on digital circular economy tools are shiny new start ups. By "start up" here I mean any type of new businesses, coop, social enterprise or whatever. The common thread is that they are facing the challenges of creating and launching a new initiative and moving forward a society wide, systemic change.

It is incredibly hard to balance the ambitions you have and the desire to make that positive circular impact against the reality of limited time, limited money and limited knowledge.

The is also the need to have a clear vision of the impact you're creating, while learning and adapting at an incredibly fast rate.

This plays out in the many, many decisions and leaps into the (scary) unknown that founders must take.

One of the most common challenges in this situation is how to find and afford good developers. Good software engineering is a skilled job and takes the right sort of experience for this context.

Right now there seems to be many talented new developers looking for roles where they can be part of something positive (perhaps young graduates or career changers who also bring other skills to the table). But folks with the right balance of skills, experience and connection to your mission are harder to find - and more expensive.

This is true whether you are hiring, contracting, working with agencies or even outsourcing.

Do I know the answer to this?


Or, more accurately, there is no magic answer.

But there is one thing that I think is important to avoid: putting the code first.

There are many pitfalls in this, from ego-driven coding [1] to well intentioned over engineering. Focusing on the code for it's own sake risks missing out on the important learning that might mean changing things quickly [2]. Or we might get excited about what is possible, regardless of the downsides [3].