Real people, solving real problems

Hello! I’m Jules Coleman. I’m founder and CTO at Resi. Before that I was a co-founder of Hassle.com, which I started in 2010. This is when I taught myself to code!

The reason we launched Resi, is because we noticed that there are no large well known residential architecture practices. It is an industry that hasn’t seen a lot of innovation in recent decades (apart from CAD). Because nearly all of the practices consist of fewer than 5 people there is no one with the scale to innovate. We wanted to change that by building a practice that puts customer experience, brand and technology at its core. We manage hundreds of projects simultaneously which has required us to build effectively the operating system for an architecture practice. For the customer this means more expertise, fairer pricing and a faster turnaround on projects.

I wrote the first lines of code for Resi in November 2016. I had just met two of my now business partners earlier that day. There were four of us in the founding team. Myself and my best friend and co-founder from Hassle.com, Alex Depledge. We partnered up with two industry professionals who ran a traditional residential practice,  Nick Stockley and Rich Morgan. Straightaway, the four of us saw the potential of the idea and we started all working on the business full time from Jan 2017.

For the first year the tech team was just me. I built out the first version of the product from data structure to backend to frontend. Using Ruby on Rails it was possible as a single developer to achieve quite a lot. As always the hard part isn’t writing code but knowing what code to write. By October 2017 I knew we needed to expand the team and I hired our first two engineers (one a Le Wagon alumni – Guv Marwaha). Through 2018 we hired our first UX designer and then another Le Wagon graduate – Freddie Scadding. We are now a team of 7 in total and growing.

 

 

For me the best tech candidates are those that realise they have a skillset that allows them to solve real world problems. Sometimes that is achieved by writing code but often it is not. Knowing when the best approach is to code up a new feature versus changing the process is a real skill. When the answer is to write code, a great candidate is pragmatic.

When I was learning to code Ruby on Rails was the new ‘hotness’. Like Rails it is likely to stand the test of time and be a useful skill to have for a long time to come. People can get very territorial about new technologies but for me it is always about picking the right tool for the job.

As someone who learned to code slightly later in life, I can easily relate to the career arch of many of the Le Wagon graduates. Our team is a blend of university trained engineers and self-taught/bootcamp engineers. Both routes have their benefits. Computer Science graduates do often have a broader understanding of engineering concepts but the self-taught route typically brings with is broader work experiences that help inform their problem solving skills.

We have access to formal learning resources like Frontend Masters, Go Rails, etc. Also books on testing and object oriented programming from authors like Sandi Metz. However, the best learning resource is the team member sitting next to you!

Alongside the normal on the job training, all of us have our Personal Objective Plan (POP) in which we set out what we want to achieve professionally in the next six months. It is my job then to try my best to make that happen. Whether it is someone wants to improve their testing skills or man management abilities. As a company we invest in external coaches and employees that feel they could benefit from time with them get a personal slot in their diary.

How much we invest obviously depends on the background of the new team member. When it comes to Le Wagon graduates it tends to be quite straightforward as they have already seen a number of Rails applications, albeit not on our scale! First, and this applies to all new joiners in the company, they spend time with each team in the business to understand how we work and what we do.

Our product development process involves writing ‘Problem Cards’ that need to be solved. Our aim is for a new joiner to have completed at least one or two of these ‘Problem Cards’ in their first week. Obviously more senior members of the team will work closely with the new team member to make sure they are on the right track and can find their way around the codebase and the business. Every problem card pull request, whether worked on by me or someone on their first day, is then peer reviewed by at least one other team member. This provides a great opportunity for learning on different ways to approach a problem.

Real people, means that we haven’t forgotten that everyone that calls Resi their place of work is a living and breathing human. They have good bits and some bad habits, they have good days and bad days and a whole life outside of work. Work is not more important than the rest of your life but you spend a lot of your waking hours there so we may as well make it as enjoyable and productive as possible!

Solving real problems means we haven’t lost sight of why we exist. At the highest level that means Resi believes everyone deserves a well designed place to call home. Day to day that means solving the problems faced by homeowners as they try to make that a reality. However we know that homeowners are already a relatively small, privileged group in British society. That is why we have started Resi.foundation where we offer our architectural design services completely for free to councils to encourage the construction of really well designed social housing.