Robert Stuttaford Clojure Enthusiast

Blog · Clojure Codex · Consulting · Speaking · Open Source · Twitter · Team Readme

Team Readme


This is my contribution to our company's onboarding process at Cognician.

It's inspired by How to Rands, which is a masterpiece of written communication. You should go read it!

I decided to publish it here, because I love feedback, and, yes, because I value the ideas I've shared, and want to spread them!

There is some duplication between this page and others on my site. Rather than edit it out, I decided to keep the whole document as is.

As always, feedback and questions are most welcome :-)

About me

Hi, I’m Robert!

I have a wife, Nadine, and we have two daughters -- Summer, and Elizabeth -- who are just starting their school careers.

I lived in the Western Cape, South Africa almost all my life, with parts of my childhood in Joburg.

I will be living in Apeldoorn, in the Netherlands, from July 2018.

I love reading novels from the sci-fi and fantasy genres. Terry Pratchett, Neal Stephenson, Peter F. Hamilton, and Brandon Sanderson are among my favourite authors.

Previous work experience

Before Cognician, I was a freelance software developer. I worked with several ‘new media’ and web consultancies, and also for several startups over a 12 year timespan.

I’ve built websites, web applications, downloadable apps, mobile games, touch screen apps, and interactive touch table apps.

I’ve used the following technologies:

I learned the Clojure stack on the job at Cognician!

Hobby projects

I have a website:, and I’m quite active on Twitter.


I write blog posts. Only one so far is non-technical, which might be of interest:

The rest are technical, and so far, are connected to my main hobby project at the moment.


I’ve appeared at several conferences and on several podcasts. Links on my site.


Separate to Cognician, I consult on the effective use of Clojure. The page I linked covers a lot about how I work at Cognician, actually: I am a consultative ‘challenge-solver’ (because not all interesting things to work on are problems!)


I am currently working on a long-term ‘build it in the open’ open-source Clojure project: bridge.

In the project’s readme, you’ll find several blog posts detailing what I’m up to.

This is my way of contributing hard-won knowledge back to the broader community, and also as a way of demonstrating my capabilities for my consulting practice.

This project embodies the way I think about building software now. Given that it’s fresh code, suffers no legacy decision-making, and is under no time pressure, it’s a LOT tidier than Cognician’s code.

I am sure that there are many interesting discussions to have about the quality difference between the two 😄

About my work at Cognician

I’m the Chief Technology Officer.

I am accountable for the technology team, and the platform that this team builds, operates and maintains.

I’ve been here since Cognician started! I joined Barry and Patrick as technical co-founder. As a consequence, I have a small share of the company.

I met Barry and Patrick through my freelancing; I helped the Kaytons with their prototype “thought processor” application in return for an iMac (which I needed to be able to get into iOS development!).

It’s a fun story, ask me about it some time!

Since then, I’ve worked first as the only technical person, then as a budding team lead, with a couple extra tech folks working with me, and now as someone who oversees - but does comparatively very little of - the actual technical work that goes into building and maintaining our platform.

I am still a technical team member - I regularly contribute code in all areas of the platform.

Logistics / Temperament

I work from 7am through mid-afternoon, take a break (usually in the form of a nap), and then do a couple more hours throughout the late afternoon / evening.

[contact details redacted]

If I’m being grumpy, it’s likely because I’m overstimulated and could do with a screen break. Tell me it’s ok for me to take a break or a nap :-) I will also happily give any orphan cheesecake a happy home...


Much of what I share below comes from books I’ve read. If you’re keen to learn more about any of it, let me know, and I’ll connect you with a book or two.

Attitude to work

I prefer goal orientation over task orientation.

I like to work with folks who need to build something, or improve something, and to help connect those folks with that ‘something’ in a way that serves everyone’s needs. This makes my job one of ‘vision setter’ and ‘impediment remover’, rather than one of ‘task assigner’. I.e. I want to point in the right direction and get out of your way.

I believe in ‘mutual self-interest’ as the only sustainable way to work together. You get something out of doing your work, and Cognician gets something out of you doing your work.

Given that our team is made solely of people with this disposition, I assume that when issues occur, it’s because of a ‘bad system’ rather than a ‘bad actor’. If something isn’t working, it’s likely due to our system of work not meeting one or both people’s needs. I tackle issues that occur from this mindset.

I believe in Purpose (I want what I’m doing to be in the world), Autonomy (I decide how I’m doing this), and Mastery (I learn, and I apply what I learn).

I don’t like to micromanage folks. When I start to show signs of micromanagement, it’s usually because I am feeling anxious about the work, or the state of the person doing the work. Sometimes this has nothing to do with either one, and I’m just feeling anxious. If this happens between us, I’m sorry about that. The best way ‘out’ of this is to start a conversation with me when you notice it’s happening.

The Strategy is not The Goal

Very often, disputes arise from having preferences for incompatible strategies, which are often based on unspoken assumptions hiding just under the surface. We can both want the same outcome, but have very different ways of getting there.

I firmly believe that motivated, purpose-driven folks can work anything out, if they work from a position of curiosity (“what’s true for you?”) rather than one of identity (“I’m right about this”). That is, to start from the agreement -- the goal -- and to work down from there to a suitable solution -- the strategy we use.

This curiosity comes from this notion of the Growth Mindset, which I try to apply to everything I do.

Naturally, empathy and compassion are very important to me, as these are both necessary social skills to use when having these investigative negotiations.

To make conversations in this space work well, I love the Spine Model, and more fundamentally, Non-violent Communication (which part of the Spine is based on).

Deep work

I believe that it’s everyone’s responsibility to manage their own subscriptions, and to accept the consequences of doing so - it’s a balancing act between being oversubscribed (and overwhelmed) or undersubscribed (and uninformed). You have to actively work to find your own sweet spot - to be effective both as a value-creating maker, and as a valuable team member.

You don’t have to be online all the time.

I am very easily distracted, and so I do a lot to limit my distractions:

Others have covered the ‘why’ of this far better than I ever could:


I work remotely, so all of my comms happens through the Internet.

When the goal is to be social, I’m SUPER happy to have a FlowDock chat or a Zoom call. Early and often!

We have regularly scheduled meetings that focus on this, and I love attending them, because it gives me some small way to connect with you, my colleagues.

When the goal is effective decision-making (which is most of our work), I prefer writing over text-chatting, and text-chatting over voice conversations (aka meetings), and voice conversations between 2-4 people over voice conversations with 5+ people.

Concretely, this means that my preferred order for dealing with a new idea or challenge is:

  1. A concise, purpose-written Google Doc (ADRs and AARs are good systemic examples of these).
  2. An Asana task, in a suitable project.
  3. A Flowdock conversation, in a suitable Flow.
  4. A Zoom call, with the folks who need to help decide.

My ideal situation is (1), followed by (3) or (4) to deliberate on any nuances and make decisions (if needed), followed by as many of (2) as necessary to track execution.

This is largely because experience has taught me that our collective memory is just terrible for remembering the provenance of a decision. When we decide things in meetings, it’s hard to remember to record it properly.

We so often get stuck because we can’t be sure why something is, and therefore we can’t be sure that we can make a new decision safely. This uncertainty is one of the things I am regularly asked to make decisions on, as CTO, which makes me a bottle-neck a.k.a a single point of failure. Better written-communication practices, over time, will reduce this dependency, and improve our overall shared knowledge repository.

I prefer to ‘front-load’ the communication effort in writing, and know that all the salient facts are on record.


I dislike meetings, because they are tremendously draining for me (I’m a ‘high-functioning introvert’), and they force me out of whatever work I am doing. Scheduled meetings also often cause me to avoid starting valuable work, because they cut my day up into small pieces.

I recognise that some meetings are necessary, and so for the meetings I attend, I am committed to being fully present.

But, given a preference ...

One of my ‘superpowers’ is: Saying ‘No’ as constructively as possible

Value driven

It’s very difficult for me to commit (or to support someone else in committing) to doing something, if I don’t see the value.

Most often, that value is in Cognician’s direct value-stream (things we sell, or in support of things we sell), but sometimes that value can be tangential - in support of someone’s learning, evaluating a strategy, etc.

The clearer the value is -- which is to say, the clearer the need is, and the clearer the intended solution fits that need -- the easier it is for me to support.

Risk averse

It’s very difficult for me to commit (or to support someone else in committing) to doing something, unless I am sure that the advantages of doing that thing outweigh the disadvantages.

I am constantly assessing trade-offs, and working to make consequences visible.

Software is far greater than the process of adding code to a production system:

All of this applies to a lesser or greater extent, whether we’re dealing with building something completely new and separate, or making a small change to an existing system.

Whenever we, as a tech team member, agree to building something, we are implicitly agreeing that the right level of thought and care into all of these concerns will be applied, or, we are taking responsibility for the risk that the lack of doing so introduces.

There are many costs to writing and operating software, largely paid by the tech team in cognitive overhead and feelings of inadequacy and overwhelm. For something to be worth doing, I need for us to have a good story to tell about these topics to be able to feel good about supporting that thing.

I feel it is my role to protect the platform from poor or no decision making in any of these areas, because doing so is the best way to provide the highest-leverage value, and eliminate risk, in the long-term.

Sometimes, this will be frustrating -- perhaps tremendously so. If this happens for you, I’m sorry about that. I hope that you can at least empathise with why, after having read this!

Back to top