The “red tape” danger

The problem with too much process and red tape is that it creates excuses for not getting problems solved:

“Our processes dictates that I must do this”, “I am not measured on doing that”, “I cannot do anything about it, it’s the rules”, “We have a policy that…”.

Etcetera etcetera.

Of course there needs to be rules and processes, and sometimes they’re even defined by law.

But having said that it is also important to reiterate that just because you can push a set of rules, a boss or even the law in front of you, it doesn’t mean that you can’t show empathy for the person(s) in the other end obviously experiencing a problem.

One of the reasons why startups even stand a fighting chance against much larger and more resourceful organizations is that they don’t have all these rules, processes and KPIs in place.

They’re just trying to do what they think is necessary to enable them to solve issues and move forward. By showing empathy and some sort of efficient pragmatism whenever they encounter a challenge or – most importantly – a customer experiencing a problem and in need of a fix to it.

When companies grow and more people get onboard, the need for processes, policies and rules will grow – sometimes almost exponentially.

That may be fine in itself. But it should never be an excuse for throwing empathy and the ability to act and fix issues out the window.

If you start doing that you will enable precisely all the behaviour internally in your organization that you DON’T really want. And absolutely don’t need to succeed.

(Photo: Pixabay.com)

Capturing learnings

One of the things I am trying to do while we work to get our new MedTech startup off the ground is to document my learnings so far.

I do that in a mindmap using SimpleMind. Because when taking notes and reflecting on things the easy of speed of getting it down into some sort of structure beats trying to get the format right from the go.

Anyways, the learnings I am documenting serve a couple of purposes;

First of all, I am trying to get the learning myself. Reflect on the things we have done as a team and I have done as an individual and try to use the instances, where we could have done better or been more efficient, to become better and more efficient in the future.

Second, I am trying to document whether there are some patterns in what we have done that we can put on formula for later use and thus make the next startup startup process a bit more smooth.

Looking at the latter point, two things have already become abundantly clear:

There are a lot of learnings around process; when to do what in order to create a flow where everything around establishing the team, the corporate structure, strategy etc can happen at a pace, where people are in it and don’t risk feeling either overwhelmed, not heard or just straight out of the picture. I think those learnings are universal and can be directly applied to other future cases.

On top of that there are a lot of learnings about people; what’s important, what’s not important, how to interact in ways that builds a great degree of trust, which I think is absolutely key for a future long term corporation to work. Some of those learnings are directly applicable to future cases, but as it relates to people, and people are inherently different, some of them will have to have major adjustments on a case by case basis.

Basically, two things are fascinating for me in jotting down those learnings:

The sheer volume of notes, thoughts and reflections is just daunting and is both a reminder of the process so far and the sheer amount of work, we have put into making our new startup work for everybody. But it also has immense value in itself as a future (part) blueprint for how to do these things.

The other thing is that I will be curious to see what will end up being the differentiator for future cases and the applicability of our learnings to them? Will it be predominantly the process parts of the people parts.

The jury is still very much out on that one and as such the journaling continues.

(Photo: Pixabay.com)

Success-in-progress

I have a fondness for paradoxes. I find them interesting, intriguing and sometimes even amusing.

One of the paradoxes is the one about working agile and lean while at the same time lamenting the lack of progress.

Why is it that we often judge something that is work-in-progress as a failure because it’s not the finished article yet? It is a great disconnect.

What we could be discussing instead is success-in-progress; assume that we’re on our way to something great and that every step that moves us one step closer towards that goal is a success worth celebrating.

It would be so much more productive.

The trouble with work-in-progress is the same as the difference between people who see things black or white and those of us who enjoy the nuances; it is super hard to agree whether something is good or bad – for one everything will (most likely) look like a disaster where to the other one it’s a step towards something better but nevertheless a step.

The good thing about discussing success-in-progress rather than work-in-progress is that the extra positive connotation to it brings more energy into the endeavour; it enable those who are working to finally get there – to the Promised Land – to feed on the excitement of their surroundings rather than murmours and complaints.

Because after all: What brings us closer to where we all want to be? Positive spurring on or complaints or just plain indifference?

Is it even a question?

Hattip: Paul Graham

(Photo: Pixabay.com)

Mistakes are OK

When you venture into something new, you haven’t tried before and/or don’t have the faintest idea of where will end up, you are going to make mistakes. And probably a lot of them.

The easy thing to do is not to venture anywhere, in the first place, because by doing nothing, you won’t make any mistakes.

Right?

Wrong.

The first and biggest mistake is to be afraid of making mistakes so that you don’t do anything at all.

Because not only will nothing happen, and everything will be dead in its tracks. You will also miss the mistakes that are really just opportunities to learn, improve and get better.

So that you can really nail it the next time. And become better. And better. And better at what you do.

Until, one day you’re a true expert who derives success from tons of previous mistakes and the lessons from them.

(Photo: Pixabay.com)

Talk code as non-coder

For quite a while I have been deeply fascinated with no-code platform Bubble. It’s immensely powerful in itself, and it allows no-coders like me the opportunity to dabble a bit into it and try to get an understanding for how code structure actually works.

But it also presents another huge advantage: An improved ability to understand and communicate with coders.

Here’s how I am trying to do it:

The Bubble editor contains a number of separate workstreams. Two of these are Data and Workflow.

Start with Data. Here you can define the properties that should go into your database, ie the different datapoints you would like to capture, store and manipulate as either part of a function of your service or the user itself.

You can essentially map out your business model here. Think about what you need to capture, and what you need to be able to do with it. And make sure that your database is structured based on it using telling labels etc.

When you have your database table in order, you move onto Workflow.

Here you can pick out individual labels from the database and basically do a IF THIS THEN THAT analysis on them and just map them out one by one. You can do this through fx a mindmap where you specify that when you’re looking at this function or feature, and a specific thing happens, the result should be something like this. And then repeat the process, until you have all aspects mapped out.

Using this approach you will end up with a serious of pretty well-structured maps that will illustrate your core functions and how they should operate and spelled out in a way that should make it easier for you to have the conversation with the coder(s) who are going to build something.

Because even if you can’t completely speak their language, you have at least made a real effort to try to bridge the gap – and all things considered you will be a lot closer to a fruitful dialogue.

(Photo: Pixabay.com)

Corona thoughts, part 9

So, we’re back in Covid-19 territory. The numbers are going up in the greater Copenhagen area and as such many have been requested to go back to working from home, not meeting physically etc.

It was a pain the last time. And it’s a pain again. But for me a different kind of pain.

First of all, I am much more aware of what is required to me to function well and ‘keep the light on’ this time around than I was the last time. So I am addament to make sure that the impact of the new restrictions will be as lightweight as possible for me, the team and the schedule, we’re on.

Which brings me to the second point: The team and the schedule. Because here there is a stark difference between then and now:

Back then we were very much in the preliminary planning phase with our new venture. Now, we’re hard at work to make it happen. We have milestones to meet, things to do, tasks to get crossed of our list.

And the last thing we need is for Covid-19 restrictions to put any sort of potential break on that.

That also makes it more stressful than the last time. Because this time there is not a feeling that potentially, we could just ‘wait it out’. This time we need to remain focused, get the job done and move along on our journey all while we observe the restrictions. That’s a big difference.

I realize that for many this was also indeed the case the first time around, and I am full of awe of how people and businesses have handled it across the board.

For me the situation now is somewhat new, but that others have gone before and succeeded gives me the confidence that our team will as well.

So thank you for setting an inspiring example to look up to.

(Photo: Pixabay.com)

Falling in love

One of the things I have learned when working to build a startup team is that if you run a recruitment process trying to find the right co-founders, there is a huge risk you will eventually get to talk to people basically looking for a job.

Like in a normal recruitment process? Duuh!

Saying this I mean absolutely no disrespect to the great people, I have met and talked to. Far from it. They are truly great.

What I do mean though is that when you’re trying to find the right candidate with co-founder potential for a startup in a very short period of time, the odds that you will run into the person, who is just deeply in love with the problem, you’re looking to solve – like yourself should be – is really really poor.

That – to me – is a lot of what separates a co-founder from a key hire but nonetheless a hire.

Meeting the potential co-founder during a recruitment process is most likely down to sheer luck. And it’s totally awesome if it happens. Absolutely.

But should you count on getting lucky?

What I have found you most likely will get instead are great people

(1) looking to buy into a very convincing pitch,

(2) comparing what you’re offering with the job they already have,

(3) looking for an economic incentive on the short term that looks like the one they already have in their present role and

(4) have a deep feeling of uncertainty about risking the jump from something they know well and which feels safe into something they know nothing about and just seems fraught with risk and pitfalls.

And it is super natural. Because they don’t know any better yet. And because they haven’t had time to fall in love with the problem, yet.

The learning?

Start super early getting in touch with people, networking, sharing ideas and building that sense of needing to do something to fix a shared understanding of a problem.

In fact, you can probably not start early enough.

Don’t put expectations too high. Don’t demand anything of the people you connect with in the process. Let it grow on them and keep notes of those who look like they’re really getting to the place, where they need to be in order to make the perfect potential co-founder for your startup.

Share the love. Feel it. As deeply as possible.

Why is falling in love with the problem so important?

For a couple of reasons:

First of all, I have a deep sense that falling in love with the problem and – by extension – those who are experiencing the problem is fundamental towards developing and going to market with a killer solution for it.

Second – and this is perhaps the most important part for the individual – is that as times do get tough and not everything is easy, it is the love for the problem and potentially being on a course to solve it that will play a big role carrying you through the hardship – and help you and your team ultimately prevail.

Without it, you instead risk ending up deeply lost.

(Photo: Pixabay.com)

Models (kind of) suck

Once upon a time I loved models. I even spent a significant chunk of my own savings getting to know them better in fancy locations around the world.

Models? Work related models, of course. The kind of models you would use for modelling concepts, businesses and such. What did you think?

Never mind.

The point is: I quickly learned that models (any of them) can be deceitful. Just when you think you have figured things out and have the best looking model in front of you, reality strikes. You are torn out of your dream and land, face down, in the ugliness of what real life looks like, when you – as Steve Blank puts it – get out of the building.

Why?

Because (1) models used for conceptualization, business modelling and presentation are inherently based on the past that (2) is seldom a great indicator of the future and (3) has a tendency to not really be able to reflect all the complexity of the real world.

Don’t get me wrong. Models can serve a purpose. They can make things look good and make for nice company and conversation. They can keep you warm and fuzzy, when you need it the most.

Models may give you the impression that all is good and well. That as long as you hold them in your hands, you are in control. When it feels best it almost feels like you’re the same kind of rockstar as a coder, who is super great at developing awesome code.

But you should never grow too fondly attached to the models.

Because the world is more complex than that. It never looks like zeros and ones or simple Post-It’s in a map or 2×2 model.

Never.

(Photo: Pixabay.com)