An introduction to engineering in 11:FS Consulting
At 11:FS, we build digital financial services, primarily banks. ‘Bank’ is a very broad term, of course, and our focus on client needs and ‘Jobs To Be Done’ approach (“People don’t want a mortgage, they want to buy a house”), means that we rarely set out to build a pure bank.
It’s a useful tagline, though. The technology we’re building with our clients, after all, needs to be up there with the most performant, robust and scalable of the Fintech firms and ‘neo-banks’.
Within Consulting Engineering, we have a particular set of challenges. We’re not typical of the sort of engineering capability you usually see from consultancies, but neither are we a dedicated ‘software shop’. We work across multiple clients, working very closely with each client to deliver alongside them whilst using the experience and tools we’ve built up to catalyse each delivery. In order to build synergies across our engagements - particularly as we scale - we’ve evolved some cultural norms, ways of doing things.
It’s at this point that you usually see a list of principles, the things that the company has, you’d imagine, written on a poster on the office wall (or possibly on stone tablets). Thou shalt….
The thing is, at the moment, our principles are unwritten. When we set out to build an engineering function for 11:FS Consulting, we were never going to do it in a ‘waterfall’ fashion. We’ve grown rapidly over the last year, but we’ve tried to add one person at a time, hiring for the skills that we need and the traits and personalities that are going to add something, both culturally and in terms of knowledge.
So, given that we hire kind, smart and talented people, it would be folly to hobble them by giving them a very prescriptive set of rules and processes to follow. We do need to be aligned to ensure we’re all heading in the same direction, but the principles we employ will be constantly evolving. So, you should consider this a snapshot, a point in time. It’s going to change (and likely will have changed by the time you read this!).
I’m also cynical when I read accounts of how companies operate, what they’re like to work for - particularly when it’s published by said company. At best, these essays are usually ‘aspirational’. More than once, I’ve spoken to an engineer at a well-known company, mentioning how impressed I am, and they’ve rolled their eyes or smirked. To that end, I will be challenging our engineers to read this and call out the gaps, the deltas - where are we lagging?
So, without further ado, some of the themes we consider important:
Teams
We’re cross-functional. No silos here. One of the most important things I’ve learned in my career is that by harnessing the views and opinions of people with different backgrounds, genders, beliefs and from different teams or specialties, you’re going to have a greater breadth of possible solutions and will likely deliver a more robust output.
There’s incredible value in involving Product, Development and Operations (if only there were a word....), QA, Security from the beginning of a project to gather a range of feedback and input. Diversity of roles and functions is relatively easy: we hire these roles, so it’s simply about how we structure the teams. Diversity of people is harder, but it’s top of mind. We’re nowhere near perfect and getting there will require more efforts and thinking to ensure it happens but it’s where we want to go.
We’re all about maximising the time we spend on the differentiating parts of the proposition.
Ways of Working
Having worked for ‘agile’ organisations for a number of years, I’ve come to some strong conclusions on the ‘a’ word:
- There’s an entire industry built around organisations trying to do it.
- Most organisations who say they’re doing it aren’t doing it well.
- If you’re trying to ‘do’ agile, you’re unlikely to get very far.
I personally believe that ‘adaptive’ is a much better word for the way we work. Every team is unique - different people, personalities, skills, aims, clients. So, we work directly with the clients, and we work in an iterative fashion. We favour delivering ‘small and often’, and we run retrospectives and demos every couple of weeks.
By ensuring we act on the feedback generated by retros, whatever ‘methodology’ the team starts with, very soon it adapts to suit that team. And the demos keep the feedback coming so that the product is constantly improving, and the team understands first-hand the value of the work they’re doing.
Building Blocks
In any software architecture, there are many components that are standard, repeatable. We don’t want to waste our time on recreating boilerplate components time after time. So, where we can, we make these components reusable (we call them “ConStructs’ - ‘Consulting Structures).
This means we can bootstrap a new build very quickly (platform, pipelines, skeleton services), then we get to spend our time focusing on the differentiators, the unique parts of each product we build. We’re all about maximising the time we spend on the differentiating parts of the proposition.
Automation
Similarly, we consider platform, testing and deployment automation to be ‘table stakes’. In order to make our deployments small and frequent, we need to substantially reduce the overhead of each deployment. Automating the ‘complex, but repeatable’ parts of the deployment process removes the cognitive overhead from our engineers. Providing automated tests gives us confidence, becomes part of an ever-expanding regression suite, and also allows our QA specialists to focus on high-value exploratory testing. If it can be automated, we automate it.
Testing the Hypothesis
We’re building products and services. Typically when we engage with a client, our Research and Product specialists drive a rigorous iterative process to generate ideas.
We then set out to test these hypotheses by building something quickly and putting it in the hands of the client’s customers. We use both our own ConStructs and carefully-selected third-party services in order to test these ideas and generate feedback as quickly as possible. At this stage we emphasise tactical solutions, but always with an eye on the future: as we prove our hypothesis, we’re able to evolve towards more strategic long-term solutions.
Feedback and Recognition
Finally, something I consider to be incredibly important. This often gets lost in big banks, when a typical software team is buried in the bowels of the organisation - a long way from their customers.
While technologists often enjoy solving complex problems, occasionally this becomes somewhat abstract: fun and interesting for the engineer, but not necessarily of benefit to anyone else. People need and deserve recognition for their efforts, whether this is running working demos for the team (including our clients), acknowledgement of the huge amount of work needed to hit a deadline, or even a metaphorical pat on the back for making a positive contribution.
It costs very little in the way of effort to recognise the efforts people make, and against the backdrop of a global pandemic, it’s even more critical that we do so, and do so often.
So there you have it. Some broad themes that hopefully give a feel for our approach, and where we want to get to.
We are not perfect (and any organisation that sounds too slick to be true almost certainly is), but we do a lot of things really well, and we have the freedom to keep improving.
