What do you do?

You show up to a BBQ and you trying to strike up a conversation with you, Bob, your uncle says, “so what do you do?”

Great question, Bob.

To answer the question, we’ve got to ask, what does the company you work for do. At Ferocia, we are building a bank where people will feel good about their money.

It’s easy to say, “we are building a digital bank” or “we are software engineers that build a bank with Ruby on Rails & React” but the issue with all of that is framing. We don’t have to use those tools to solve our problems, and in fact, they aren’t our primary building blocks.

Our primary building blocks are good old-fashioned problem solving and team work. Seems cliched, but I wrote these and then went back and re-read the Agile Manifesto, surprisingly similar.

We often use software to solve these problems, we are good at that, but picking up that particular hammer first can be a trap. In fact, it was a trap on the current project that I’m on. We had expected a partner to deliver us some APIs that we knew would solve a really big chunk of a problem for our support team, so we worked really hard to get that delivered. 6 months on, we are still waiting. In that 6 months we took limited actions on solving the problem, “the API will solve our problems”.

At some stage, we went back and revisited the problem with a broader framing, and realised that even with that API we will still have a problem, it’s different from what we originally thought and while the API will still be incredible, we can solve problems in a heap of different ways. A heap of those will drop this week.

Cool story, so, what do you do?

It’s a simple game that is very difficult to master, and sometimes very hard to know where you even are in the game.

I try to help make sure we are not focusing too closely on the problems we are solving. Allowing myself the knowledge that I will never write the line of code or deliver the actual solution to a problem, instead helping the people around me, often my team, to frame the problem more widely.

More and more and more I say, “what is the problem we are actually solving here?”

And that’s it. I try to make sure that we are building a bank where people feel good about their money, and in the subsection of the world that I do a lot of my work, make sure that we are building tools for our support team to support those customers.

This is a problem of framing. So much of my thinking around this is framed by the book Thinking Fast & Slow by Daniel Kahneman.

Someone says “Oh we can write a bit of software that does x & y”. Should we? Or should we do something else that solves it in a different way. Can we frame this problem in a way which takes a broader/more appropriate view of the solution.

We make mistakes. All. The. Time.

Now, as I said, it’s a simple game with very high level of difficulty to master, and a lot of the difficulty is in peoples innate fallibility. Mistakes are going to be made, the trick is, making sure that one doesn’t lead to another and another.

This happens all the time, as engineers we love getting to the end of a problem. Following the rabbit hole all the way down. But sometimes that pursuit can be a long way down the wrong path. Essentially turning 1 cheap bad decision into an expensive one. This sunk cost fallacy can permeate and permeate. The repercussions of this can be felt for ages.

Take the API problem I mentioned earlier, the easy thing to do is rest on your previous decision and forget that there’s different ways to solve the problem.

This ends up being the hard part, constantly poking and prodding at what the team is doing and assessing and reassessing our processes to help get better at decision-making and delivery. The best opportunities for this is when you know in retrospect that there was a better way, that you made a mistake, or that we’ve done work that we probably need to halt or throw away.

These are all prompts to find a better way.

Did you chat to so-and-so?

Which brings us to collaboration.

Everyone loves that endorphin hit that working together as a team and delivering some good stuff brings. There’s no doubt about it.

And yet, there’s some strange gravitational pull towards working individually. I’m sure someone has done a study, or written a book about this, but I’m not aware of it. But, it’s a thing. I know, I’ve been guilty of it before myself. “Nah, I don’t need to talk about that, I got this”.

So, the solution is to nudge towards collaboration as the default mode of work. Ensure we are talking to the people working directly on the project more than might feel natural. It is never going to be a waste of your time.

There is a mode here which does over do collaboration. This is “death by committee” or “key stakeholder engagement” and ensuring that this doesn’t take over projects is a key role. This involves everyone understanding what success looks like or the definition of done upfront. This let’s small groups be empowered to work together and collaborate.

So that’s what I do. I ensure that small groups of people can solve problems and collaborate.