Less is more — Pragmatic CTOing

I’ve been performing the role of CTO for a number of companies/startups and various organisations for the past 7 or so years, and before that been advising and supporting tech delivery at a senior level for around another 8 years.

All in all, I’ve learned a lot and played with a lot of technology in that time. I’ve also watched many projects get delivered, and get canned, and lots of ideas get created as to “how we should do it” and many ideas get canned too.

When I joined my current company, Movivo, I was very simply a bit bored of doing the same thing everybody else was doing. I really didn’t want to do that any more.

So I decided that I was going to take the principle of the MVP to it’s logical conclusion.

Build as little as possible to gain as much as possible.

To put it another way, I was aiming to be as pragmatic as possible.


Pragmatism is about being matter of fact. It’s about only concerning yourself with the facts of a subject, not the surrounding “fluff”.

In the world of tech, it is basically an approach that says something like:

I’m only going to build the business logic, and on top of that, build just enough technology to fulfil the business need identified.

Up until recently, this would have been something like this:

“Get a cloud account, and setup some load balanced instances, and then get a backed up relational database, and use a framework to develop the solution we need, and deploy it all”

Or possibly:


Whereas my approach was simpler:

Get an AWS account and utilise API Gateway+ Lambda + DynamoDB in such a way that I can minimise my “fluff” and just do the business logic (and let AWS figure out the rest, like scaling and load balancing etc).

When you get an instance or containers, you have to both setup and maintain it. The same is actually true for a managed or unmanaged database instance. Still some setup and definitely backup maintenance needed.

So, my solution was very simple. It’s ridiculously lazy as well. I basically hired AWS to do the jobs I don’t really want to do at a lower cost than I could do them myself.

The only bit I had to worry about was the actual business logic.


Keeping it simple

But why does simplicity matter?

I will say that our solution nowadays does not look simpler on the face of it. We have a series of terraform scripts that deploy to staging and live, and utilise CircleCI in our pipeline. But what we lose in “one hit deployment” we gain in flexibility of deployment.

We can refactor things via code. We don’t have to touch very much of AWS any more as it’s all done via Infrastructure as Code.

And we can test a bunch of this infrastructure in our staging account.

And we can make a single function deployment to fix a minor bug with relative ease, knowing that it’s not going to take down a series of servers, or require a rolling upgrade.

Again, we’ve handed over the difficult bit (actual deployment into a live environment) for a bit of added complexity (slightly more complex deployment pipeline).

More spare time!

I flippantly say in talks I do that this means I have more spare time. It doesn’t really, but it does mean that my spare time is rarely interrupted with automated “server down” messages.

In fact, it rarely happens that we have to “fix” anything.

Because when you’re only bothered about each function’s logic, then changing one rarely affects a second.

And so long as you’re not writing mountains of code for each function (you shouldn’t be!) then you end up having highly maintainable single functions.

So, your complexity maybe in deployment setup, rather than anywhere else.

And you may end up not abstracting some of the complexity of the code into a framework.

But you end up with

more spare time

and less downtime

and better deployment to live environments

and fewer headaches about deploying (because rollbacks are simpler)

No more “servers”

There are still times it’s annoying, but to be honest, I’ll take those annoyances in exchange for not having to do the bit that’s hard.

The actual servers.

And eventually we will end up with a scenario where all the provider will ask for is code (a bit like heroku et al, but much much better)

And the provider will give us a highly scalable, highly available solution for not a lot.

Because they know servers

So we don’t have to.

Written by

ServerlessDays CoFounder (Jeff), ex AWS Serverless Snr DA, experienced CTO/Interim, Startups, Entrepreneur, Techie, Geek and Christian

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store