Life-like governance: structure thoughts

UPDATE: This post came from some thoughts that had been with me for some time. The title – ‘life-like governance’ was new. And when I saw the title on the screen, I realised that it encompasses a whole set of thoughts that are wider than this one post.

Accordingly, I have tweaked the title of this post with the suffix ‘Structure thoughts’. I’ll add others that relate, and try to build a more complete picture as I go.

Most conversations around governance as progressive organisations form are either handwavy; “It’ll be flat and super democratic” or hyper-specific; “We’ll be using holocracy and a modified version of dot voting plus some Loomio – read this document”. Or worse, some mash-up of the two. This rarely ends well. Either the Tyranny of Structurelessness asserts its dread grip, or the pancake falls apart into a depressing soggy mess.

But we want to build dynamic, effective organisations that have a chance at living alongside rapacious capitalist analogues, and so we must relate to our stakeholders in ways which engage them, and which capitalism cannot copy or steal.

We must have good governance, and it must be engaging.

If we can’t achieve this, we should go and try some other mode. For if we succeed on the basis of something that capitalism CAN do, we will be overrun – access to capital is their superpower (for instance it enables Uber to run at a massive loss, now and for years to come).

Our superpower is humanity. We can and must relate to our stakeholders (whether at the core, at the coalface, or customers) on a basis which engages them as whole humans – to the extent that they will stay because they want to, because they know they want to be with us, rather than with the ‘cheaper’, ‘faster’, ‘flashier’, ‘sexier’, ‘bigger’ that capitalism will always offer.

So here are some thoughts on founding our thinking in notions of ‘life-like’ qualities.

ONE

An idealised scenario for our experience with life-like governance:

TieredGovernanceDiag
We spend our daily lives doing what seems to come next. Only if there is some doubt about whether what we plan to do ‘fits’ do we need to think about ‘policy’. Policy is kept in the pit. Continue reading “Life-like governance: structure thoughts”

Alternative currencies – Simbi and the Flying Brick

Credit: danyythemartian – DeviantArt

The Flying Brick was the printed directory of the Brixton LETS Scheme (this isn’t the image we used – the original is lost in the mists of time – or a cardboard box in the attic).

LETS stood for Local Exchange and Trading Scheme. Brixton LETS was started in the second wave of alternative, local currency schemes in 1992 in Brixton, South London, and I’m proud to say I was one of the founding group, and one of the team that ran the scheme in its heyday over the following few years.

The idea was that members would trade together using our own local currency – the Brick (what else?) – which was a ‘virtual’ currency – a number in a database, with no physical existence. And that this currency would have different rules to ‘normal’ money, specifically: Continue reading “Alternative currencies – Simbi and the Flying Brick”

Startup Equity Distribution – an incremental approach

ezgif-com-resize
Equity distribution in early-stage startups is a slightly odd subject. Obviously at this point the startup is worth nothing – or less-than-nothing, if expenses are being recorded as debts on the future company – and who wants to argue about percentage points of nothing? Sometimes the whole subject is just ignored.
On the other hand, whatever the addressable market size of the idea at hand, the spectre of founders squabbling over enormous wealth is lurking somewhere in the subconscious of everyone involved, so it is equally possible to go the other way, and invoke complex calculation methods of one kind or another, however irrationally over-fussy.
While complex approaches are arguably better than failing to address the issue at all, a simpler method is more typically adopted: if there are two founders at the beginning, they are usually assumed to have 50% each, if three, 33 1/3%, etc – as in this Seedcamp agreement template.
If they add additional co-founders, there is a re-distribution by agreement, such that the original co-founders see their percentage ownership reduced, to ‘make room’ for the new partner. The process is repeated each time a new equity-holder is added (ignoring such things as special share types – usually considered as over-complicated at early stages).

I consider that there are several problems with this:

Continue reading “Startup Equity Distribution – an incremental approach”

Security as an Overhead isn’t working

We’re building a medical app. Of course, Therapy-Smarter isn’t collecting deeply intimate data – just basic contact information, some physiotherapist’s notes, exercise prescriptions and exercise performance data – but nevertheless, medical data is medical data- it’s inherently sensitive, and any company that cares about its reputation needs to take data privacy – and thus data security – very seriously indeed.

HealthITbreaches

So, we’ve been thinking about it fairly hard – but not in a technical way; it’s a specialist domain and we assume that we will need to pay people who know what they are doing to advise us on best practice and  then get them to assess our implementation.

No, we’ve been thinking hard about security in terms of business culture, because it seems painfully clear that this is where security weaknesses really come from. That’s right – I’m saying that security weaknesses have much more to do with business culture than they have to do with engineering.

Continue reading “Security as an Overhead isn’t working”

Developing a Digital idea without Developers

This is in many ways a companion piece to my previous post it started out as a version for LinkedIn, but rapidly evolved into something with a different emphasis.

The internet revolution has changed the landscape of our lives, and yet the disruption has only just started. Existing ways of doing business are largely unchanged from the way they were 20 years ago. Hilarious disconnects exist all over, when ultra-slick digital-only processes crash into messy physical transactions.

There is a reason for this. Coders like to code – they like the safe, ordered, complicated-but-not-truly-complex world of programming. And coders are the ones who feel empowered to invent digital businesses. So, of course, the early digital businesses are the ones that can be achieved with purely digital workflows, and don’t require the startup team ever to leave their own world.

Continue reading “Developing a Digital idea without Developers”

Using FilemakerPro as a RAD platform just got more interesting

I’ve mentioned before that we’ve used FPro as a type of Rapid Application Development Platform. Building a fully functioning prototype using this high-level (largely graphical) database application has allowed us, as non-coders (albeit with a decent understanding of how a properly architected database should be structured), to develop our therapy-smarter tool in an iterative way, without spending large amounts of money.

Another benefit is that the product we are using remains fully accessible to us at the architecture and data level, and is largely self-documenting. FilemakerPro produces human-readable graphical representations of its database structure as a standard report and the functional scripts are basic-like in their use of real language, and thus easy to follow.

What this means is that, for a team like ours, without coders, the scary step of commissioning native code from people whose work we will ultimately not be able to judge in detail is made much less risky. When we judge that the time is right to take the system to the next level – when we need it to go faster and handle more clients, we will have to get the thing recoded – and this will mean bringing developers in.

For startup teams without coders, this is a terrifying point. How do you find the right person? How do you choose which framework, which language, which platform, which architecture? How can you even begin to judge the recommendations you are hearing? How can you describe the features you want?

Continue reading “Using FilemakerPro as a RAD platform just got more interesting”

Costing coding work – and the value of experienced intuition

OK, I’ve come to an impasse with what I’m doing at the moment – banging my head against a particular wall for a few hours too long.

Time to move on to another topic; pull out the mental list of all the things that need to be at least thought about in order to move our startup forward.

IP, MVP, business model, data protection, regulatory environment, legal structure, read more about Scrum/Agile, marketing strategy, logo design, data structures, UX prototyping …  …  … …  (…:::!!!!)

OK, here’s one: how much money are we going to need to spend on coding to get to a scalable MVP launched?

Big question! Cost estimation is a big deal in traditional bricks-and-mortar architecture, too, so I’m aware that this is not a subject to be taken lightly or fudged. A frequent and serious pain point in construction projects is when project estimate costs rise significantly AFTER the client is committed. Whatever else happens when this occurs, confidence and morale are dented, usually badly.

Construction clients want to spend as little as possible while statutory consents are at risk, and one way to spend less up-front is to do lightweight cost estimation (on the back of lightweight specification) and hope for the best. Of course, even if they have misgivings about these estimates, consultants are often unwilling to rock the boat at an early stage, not wanting to be the messenger that gets shot. Less scrupulous players have even been known to downplay cost risk until the client is committed, and then milk the situation (‘Oh, you wanted us to do the roof? Oh no, we never included for that. Yeah, yeah, I know you need a roof – rainin’ innit? Let me see what I can do for ya. Not gonna be cheap though – you wouldn’t want to skimp on a roof, wouldja?’).

So my approach to construction projects is almost always to convince clients of the value of making a larger-than-typical effort at the early stages to address all the likely risks – I’d rather have a client cancel early than go into something that is going to turn into hell for everyone. If they come up with another project in a few years perhaps they’ll remember me as that honest chap who saved them from getting burned.

So, can I do this with software?

It seems not. In fact, it seems not, big-style. Continue reading “Costing coding work – and the value of experienced intuition”