Koyo Technology Culture – Part 2

Overview

In the previous blog post, we introduced the tech culture at Koyo and outlined our two central, core values.  In this blog post, we consider the next 5 values: 

1. We have just enough process 

Only in highly repetitive tasks, is a high level of process the correct structure.  Cooking a burger at McDonald’s (other fast food companies are available 😊) is an example of a process which is highly repetitive, where consistency is critical and thus a very precise, well-defined, restrictive process is used. 
 
In contrast, building great software is a complicated endeavour.  Whilst there might be “design patterns” and guidance on “best practice”, each problem we face is unique and the best solution is often a matter of debate and opinion. 

This does not mean we have no process!  At an earlier startup I joined the developers were literally deciding on the interesting things that they wanted to work on.  This worked (as the startup developers understood the problem domain very well) but was clearly not scalable.  I’m all for tech-led companies but there is taking things too far. 

So, we have just enough process.  We absolutely do not want to be bureaucratic. 

(The best definition of bureaucracy is when someone asks “why do you do it like that” and the response is “I don’t know, that’s the way it’s always been done”).   Too much bureaucracy slows things down.  At best it acts as a “straight jacket”, at worst it gets subverted.  ITIL is evil (if you’ve never had to deal with ITIL then congratulations!). 

Conversely, we do not want too little process.   Given a choice, we will air on too little process.  I’d much rather we have a “loose” process where people feel empowered and able to get things done rather than one where people feel powerless and frustrated. 

As a corollary, we do not focus on the tools around the process – it becomes too easy for the focus to shift away from finding the best process to finding the best tool and further for the limitations of the tool to define the process.  This is a case of the tail wagging the dog.   If you have a single, small collocated team, the most effective “tool” is a whiteboard with cards for each user story.
Further, we recognise that the right process will evolve as the team evolves.  What is right for a tech team of 2, is not right for a team of 10, a team of 30 or a team of 100.

2. We are lazy

Larry Wall (creator of Perl) said “The quality that makes you go to great effort to reduce overall energy expenditure.”  I hate to do boring, repetitive tasks.  I will go to great lengths to not have to do them!

Most obviously, this is largely about automation – of internal tasks (most famously CI/CD) but critically also across the company.  If we see boring, repetitive work that can and should be automated we should be vocal about eradicating it.  Too often other functions (e.g. finance) will put up with such drudgery and risk teams will put in multiple manual controls to compensate for lack of automation.  We should ask “would I put up with that?”  And if the answer is no then we should look to automate. 

This follows the company value of being courageous and challenging the status quo.  For me, this is a key component about being a “tech led” company: it is a mindset that says that technology should be core to what we do and to strive to achieve a high level of automation.  (As an aside too many fintech companies are old-school financial companies with a thin veneer of tech and a lot of marketing spin.)

Finally, we can be lazy by not over-engineering and blindly following the latest tech fashions without understanding when they are appropriate (a team of 2 developers does not need a microservices architecture).

3. We do the right thing

We do the right thing: in general, if something is worth doing it is worth doing well.  There is a natural tension here with the need to get to market quickly and to be able to iterate – this is also critically important.

There will be compromises but “short term solutions” often turn into “long term solutions”.  The trick is to know when a solution will indeed be short term and compromises can be made.  Architectural compromises are a lot worse than code level compromises.  I have come into other organisations which have persistently taken short-term solutions and built an amazing amount of architectural-level technical debt.  When you repeatedly take short-cuts you end up with “spaghetti” – you want to fix one thing but as you pull on that single strand a whole set of other changes are required (and of course without tests these only become apparent in production…)

4. We hire the best

The biggest benefit is working with other bright people solving difficult problems. Small, highly motivated, skilled teams outperform large, mediocre teams and they have more fun (see this video).

Whilst we look to systemize and make the recruitment process repeatable (which will be covered in another blog post), if we are unsure about a candidate we will pass.   If we have made a mistake and hired someone who is not working out, we take steps to resolve.  This should never come as a surprise.  However, one person that is seriously underperforming will at best have a negative impact on the team as a whole and at worst will breed resentment.  Steve Jobs also categorised this as “A players hire A players”.  If the next person you hire is not better than the existing average, then the quality of the team is going down – this means the first person you hire needs to be better than you.

5. We are fully distributed

Hiring in London is very competitive.  We cast the net wider in order to be able to get the right quality of people.  This is primarily not about price, but about being able to hire the best (see above).  We only hire people in timezones close to London.  This means that we do not need to worry about off-line communication or ask people to work anti-social hours in their local timezone.  We use all the necessary tooling (Zoom, Slack) to make this as efficient as possible.  If we end up with one or two developers in London, we will still primarily communicate over those channels so that remote team members are involved in all decision processes.  Once the first tech team is built-out we will make a decision about whether a second team will also be distributed, or based in London.  

Conclusion

I would like to wrap up with where I started.  “If the culture is right then everything else follows – coming to work is a pleasure, people feel valued, they are productive, problems and difficulties are addressed head on and solved.”  I am hoping that by documenting our culture early, by leading by example and by promoting good behaviour we will create such an environment here at Koyo.