The power of problem solving in a team
Tags: beginners, webdev, programming
Published: 2021-11-07 14:21:15

**I’m a problem solver. You’re a problem solver. We often work in teams of multiple problem solvers. But are we all the same?**

Well, you’ve guessed it; clearly I’m suggesting the answer is “No”. No need to read any further, good job everyone, you can all go home!

But, in case you’re interested, let’s dive a bit deeper into what it really means to be a problem solver, since so many companies add it to their list of ‘desirable qualities’, and so many of us describe ourselves as ‘a problem solver’ when we’re adding to our CVs.

The term ‘problem solving’ really focuses on the end goal, or on having achieved it, but what I’m interested in is *how* we all solve these problems, on how *differently* we solve them, and what that means when problem solving with others in a team.

I am currently studying on a 24 week intensive front-end development bootcamp with [Technigo](https://www.technigo.io/) (who are amazing, btw), and throughout the course we get the chance to try out our pair and mob-programming skills. I knew that this bootcamp was going to be an intense experience, but I had thought that the real learning for me would be around the new programming skills. I’ve worked in teams before, I’ve lead teams before. This part, I thought, would be nothing new. How wrong I was!

**I’m a problem solver**

Let’s start with how I problem solve myself. I’m in familiar territory here, I’ve known myself a long time.

**“Just type something, *anything*!!”** Is the advice I get one day, while pairing.

But no! I can’t type *anything*. When I encounter a problem, I like to try to break it down. I deconstruct it. I analyse it. I like to figure out what is happening, what I think *should* be happening, and then I like to join the dots between these two with knowledge. So I think, I read, I go away, think some more, research (let’s be transparent; I Google stuff). Only when I feel like I’ve understood the problem, can I feel secure in fixing it. This is methodical. This is slow. But I like to think that it’s worth the time, because when I encounter a similar problem further down the line (which I inevitably will) I should have the depth of knowledge to be able to solve it instantly.

**You’re a problem solver**

Working on group Technigo projects (it’s the [Weather App](https://tiger-weather-app.netlify.app/) that really sticks with me) has given me a much deeper insight into the ways in which other people might problem solve, and how those differences can actually benefit teamwork rather than hinder it. We were five different problem solvers on that team, but it’s one amazing team member in particular that I’m thinking about now, (she probably knows who she is!) because her problem solving methods are so completely the opposite of mine! She *does* type something, she *does* type **_anything_**! She still researches (Googles) - we all do - but she looks something up, adds it in, sees what happens. Doesn’t work? Tries something else. Still doesn’t work? No problem, tries something else again. Sometimes, something *does* work, and we all cheer and high five because our problem is fixed. But, of course, her problem solving (I think) doesn’t actually stop once the problem is fixed. Now (or maybe later) she’ll have a look at that little bit of code that works but none of us understand, and understand it.

**We’re a team of problem solvers**

This was difficult for me. Everything went so fast, so how could I analyse what was on the screen before it was gone again, replaced with something new? But it was amazing too, because sometimes the advice is right, and I really do just need to try something, *anything*, so that I have more information to go on. For us, the way to problem solve together was to take it in turns. I would let the code come and go on the screen without trying to figure it all out, but try to see what was happening at each change and find the answer within that. Later, when there was time, I’d go away and do my reading so that I could understand the problem in depth. In some ways I think it’s slightly harder for ‘trial-and-error’ problem solvers to work around my more methodical approach, because it involves waiting while I’m analyzing to see what I come back with. But it’s possible, and when you know your team well, very doable.

**So here is the point:** Yes, it’s fascinating to me that not everyone solves problems in the same way. But being aware of it also has hugely positive impacts on teamwork. There are many ways to problem solve, and when you’re working on a team, it’s not about how an individual solves a problem, it’s about how the whole team comes together, uses the various different problem solving skills of everybody, and makes sure that *everyone gets heard* (that’s so important it should probably be a whole other blog post). And when you come out victorious on the other side, it’s not because one way of problem solving was superior to another, it’s because you took the time to understand each other, what you all can bring, and how to use those problem solving skills together.