We sit down with FaultFixers's CTO, Iain Phillips after almost a year of joining the team to discuss the ups and downs of building a product in a startup environment.
In his interview, Iain talks about how to navigate culture in a hybrid development team, how he manages product feature prioritisation and scalability as well as some useful insight and advice for aspiring CTOs and engineers.
Besides the thought of the evening's dinner plans, I really get a lot of kicks from seeing the impact myself and the wider team can have on a product. Being able to release a change and have people using the new functionality - and enjoying using it. That's an exciting feeling. Of course, there's always the fear of errors to contend with, but this is why we do what we do.
It's the most important thing. Balancing flexibility and efficiency has always been my top priority in building team cohesion. Mutual respect for flexible work conditions and differences in situations shouldn't be at a conflict.
Our teams know this and put in the effort to get the output. The hybrid working model comes with its challenges. When working on something very niche, often some developers will take a step back due to irrelevance. It's usually in these moments when key information is shared or agreed upon. In an office environment, this travels by water cooler osmosis and people pick up what they might not have been focusing on naturally. Involving people in calls where they can continue working in the background gets us closer to ensemble (mob) programming without making the full plunge.
Comparing specialisms
I often come across teams who find that the level of output from developers differs, eg. API development varies from that of UX development. These professions, although similar in nature, are measured in effectiveness in completely different ways. Finding the balance between these outputs and delivery pipelines then becomes an art form!
Not Sharing Responsibility
it's very easy for a development team to feel that once their individual work is completed, they can move on. Of course, as developers, we know this is never so simple. Shared responsibility across features instead of skills allows for help to come in various forms - whether it's putting on a different hat for the day, providing moral support or helping to write documentation.
Taking estimations too seriously
I'm an avid disbeliever of estimations for work completion when it comes to software development so it's also key to me that the team are open and honest about their output and this is reflected in turn in their accuracy.
I try and make this process as visible as possible. The more obvious the known impact, the more refined the prioritisation calls. This works for everyone in the team and ensures any conversations, promises or milestones are adjusted to match expectations.
In this world of digitisation, there's nothing quite like moving a big sticker on a board to show why animated icons might not be quite as in demand as speed optimisations.
By building the applications with transferability in mind, we can be sure that replication of the smallest denominator, be it infrastructure, containers, code, packages or content, is scalable. We know that uptime and data security are key requirements of our customers and so with this in mind have set up FaultFixers to scale with our growth.
It's very easy to get stuck in your own beliefs. We all feel like we know the product well enough to assume how a customer might use it or respond. These kinds of assumptions can easily waste time, reputation and inevitably money. Testing the success of each and every change as early as possible with the customers is the only way to avoid getting stuck in a rabbit hole of guesses. This, for me, is where many startups end up wasting time.
Design and UX have always been important to me, but as time has gone on, it's become even more important to the customers as well. Nobody wants to use a system that you need a degree in to use, something that is so intuitive that anyone can pick up for the first time and understand exactly what's expected is the north star for any kind of software. One of the dangers of software development is that over time, the systems themselves evolve to be more complicated than is often necessary. Continuously evaluating, simplifying and focusing on the intent of the software is vital to a successful product in my opinion. This is why companies like Apple are unbeatable (no matter how hard I beat them) - they've understood that customers will change their ways of working to accommodate simplification for the sake of innovation.
Try and take in as much information as you can. I know this sounds obvious, but it's very easy to specialise and ignore anything else. This could be to further your career or because it just interests you more and specialism is great. What I'd say is that there will always be alternatives to your specialism and so being able to understand enough of other routes to consider them as viable options for yourself or somebody more qualified, helps to push a product in the right direction.
