Moonsift’s Values
A brief overview of the values we aim to promote at Moonsift as we grow our team.
One of my main motivators in founding a company is the ability to create a working culture and environment that reflects modern day society. To me that means a culture that is inclusive, flexible, healthy and, indeed, fun. In this article I want to outline some of my current thinking on what values should drive Moonsift forward as we aim to achieve these things. Personally I find a lot of corporate value statements vague and unhelpful, so I’ve picked three key themes and tried to put in some examples of how we are working. Whilst this is a personal perspective, the values are shared with my co-founder Alex and other team members.
Keep learning, Keep asking questions
Learning means growing, means improving, means finding new interesting and fun things and also — hopefully — becoming more efficient! I’m from a research background and days where I don’t learn anything are dull days. During the development of Moonsift, I’ve been in part motivated by learning react, firebase, google cloud platform and a whole host of other tools. The past 6 months I’ve been working with a brilliant junior software engineer, Harley, and really enjoyed planning what he’s been working on such that he is able to progressively develop his skills. In addition, we discuss his professional development during meetings and so I’ve been able to suggest to him topics read up on during some of his work hours. His questions have also kept me on my toes and ensured I’ve learnt things from him too.
We are currently working on bi-weekly discussion topics where we discuss our knowledge of some of the key components of our set up. Where possible, we find someone who knows more about these things than we do and ask them to join. We’ve recently done a discussion on some of the advanced options of version control and will be looking at some design patterns next. I’m a great believer in fostering a community where you feel safe to admit to not knowing something and asking questions. No one knows everything, there are no stupid questions, perhaps just ones that are better answered by google than a colleague. I think the best questions are often the ones that question our most basic understandings and conceptions and usually start with “why”… but that’s a topic for another post.
Put our users at the centre
We’re primarily building a consumer product and this means when developing it we take UX very seriously and try very hard to let our user feedback drive the features we build. We’ve spoken to hundreds of people over the past 2 years about their problems buying clothes online. Alex, my fantastic co-founder, spends hours every week chatting to our users and filling books and notion documents with their thoughts. Our product worksets (our term for sprints) always begin with us looking at user feedback and deciding what features to build, then — crucially I believe — we keep the design and development process separate, with Alex taking on the design and myself giving feedback. It’s far too easy as the developer to just build whatever is easiest — i.e. what you know or what a library implements. And whilst us developers push-back over what is hard, we’ve prototyped everything we’ve built and users push back too (often in the other direction). So what we have today is a compromise giving users something they actually want and is easy to use. By now we feel like we have this process rather streamlined, although it does take time. It’s all worth it, however, when our users post about how much they love us.
Be accountable and supportive
Perhaps having something to do with the fact the rest of the company is from New Zealand and also that I’ve had the pleasure of the ups and downs of a PhD, we’ve built what I believe is a very accountable and supportive environment for working.
In academia I realised the importance of accountability when I was working on my own experiments. Unfortunately, I ended up neglecting some of the fundamental parts of research when I began my PhD, and didn’t write up (as in to a peer-reviewed paper standard) my research as I did it. What’s worse is that this was contrary to my supervisor’s advice! When I eventually did start writing up that rather long piece of work I realised things were not as rigorous as they should have been. Luckily, having a co-founder helps incredibly with this and over 9 months Alex and I went from meeting each other for the first time to working remotely with, at times, just a phone call a week. Almost 2 years later and with remote-working a necessity I feel we have built up a level of trust during the time we shared an office that has enabled us to work remotely well. We’re now striving to make sure with a live product that we keep each other informed and make sure that we both stay focused. There’s definitely improvements to be made in our accountability systems — a whole bunch of tools to investigate and try and we’re keen to develop that over the next few months.
Support comes from the people in a business but also from your processes. We’re fortunate enough not to have the pressure of business clients or a competitor to release a product in a rush (we are still the “contrarian” business — more on that in another post!). We’re thus able to build in a considerate and healthy way to a high standard and this makes for much less stressful development later. For instance, at the time setting up our continuous integration and separate dev / staging / production environments with Google Cloud Platform seemed like a frustrating time without building anyting. The payback, though, has been immense in recent deployments and left my mind free to concentrate on building a new feature rather than maintaining previous, rushed code.
And of course support means staying healthy mentally and this is always on the minds of both myself and Alex as co-founders and we frequently discuss it. For example, I’ve never been able to comprehend the typical North-American system of 1–2 weeks of holiday a year. Breaks are important, holidays are important, where you live is important… The key here I think is flexibility. Flexible working hours and location. Moonsift is generally designed in London and built in San Francisco, Birmingham and Edinburgh (and frequently whilst travelling between the last two). We’re not quite at the stage where we can say at any one time someone, somewhere is working on Moonsift, but I’m a great believer in enjoying a hike on a sunny Wednesday and making up for it on a rainy Saturday. Whilst I expect as we grow our team some flexibility will decrease, we’re keen to try and keep it as high as possible for everyone who joins us.
If you’re excited about Moonsift’s vision we’re hiring at the moment (September 2020) including for a full stack developer, see that job description here.
