Imposter syndrome: how we act and work together

Often when we write about imposter syndrome in developers, we look at what the individual can do to stop it from happening. In this post, FutureLearn Developer Melinda Seckington looks at what we can do as a team.

As developers, we’re constantly learning: we’re expected to keep track of new technologies, languages and frameworks. We’re expected to work with old technologies, languages and frameworks. We’re expected to fix weird never-seen-before-bugs. We’re expected to solve problems that don’t necessarily have one unique solution.

There’s an overwhelming amount of things we could know, and everything we do requires us to learn and adapt.

When we experience imposter syndrome, that feeling of not belonging and thinking we don’t know enough, it’s caused by the assumptions that we make about the rest of the world: we make assumptions about how and what we think the world expects us to be, to act and to know.

Imposter syndrome is not just a personal issue

Part of this is a personal issue: there are plenty of things we each can do to stop feeling that way. But knowing how many people experience imposter syndrome, I think this is wider than that: this is an issue we should be dealing with as a community. What can we each do to help others not feel that way? How do we remove these assumptions people make about what they’re expected to know?

I think this can be primarily solved by highlighting the state of not-knowing. Starting off by knowing nothing, making mistakes and learning as you go is all part of the process. Especially as developers, having the space and time to do all that helps us make new assumptions of what we think we should know.

What I think this comes down to is having a culture of learning where people can learn and fail. So how do we create that culture?

Unsurprisingly, most of our team at FutureLearn are interested in learning more and in better ways. Our company mission of providing the best learning experiences to everyone, anywhere, is not only about our product, but is also reflected in the way our team works.

Giving people the space and time to learn and fail has been essential for creating a sustainable development team. As our company has grown, our culture of learning has evolved to what it is now, embodying the ideas and values of everyone that works here.

I think we can look at this from two different perspectives: the way we act and work together and the different types of events we organise to support learning. In this post, I’ll focus on the way we act and work together, while in an upcoming post I’ll talk about the events we organise to support this.

How we act and work together

So I want to share six values or principles or whatever you want to call them about how we act and work together. Now we’ve never made these explicit values in our product team, since we believe that these should be a given for every team. They’re not something that are unique to our company or our team, although they are all things that we do and try to uphold.

1. Embrace failure

From a very early age, we’re taught: failure is bad. Failure means you didn’t study or you were lazy, or that you’re just not smart enough. We’re taught that failure is something to be ashamed of. And that’s just wrong.

Making mistakes and failing is all part of learning something new and we should accept that it will happen. Just think about the first time you learnt how to read, or learnt how to play a new instrument, or how to ride a bike. Did you do all those things perfectly the first time you did them?

Every mistake, every failure is part of the learning experience. This shouldn’t be a surprise to those of you that do test-driven development (TDD) or behaviour-driven development (BDD) – you don’t just want to make your tests pass, you need to see them failing as well. So this isn’t only about embracing and accepting failure, but it’s about actively seeking it out as well.

2. There are no stupid questions

This is something that I struggled a lot with. I thought asking questions and admitting I don’t know something was a sign of defeat. A sign that I was a fake, that I didn’t belong. Tied up with this is googling something if you don’t know it. I always thought good developers had just memorised everything there is to know, but that’s not true.

As I said before, the state of not-knowing is part of the process. There will always be times when we look at a bug or a new feature and go “I have no idea where to start on this”. Good developers know when to ask questions and when to ask for help.

But this also means that you should never look down or make fun of questions that others might have. You should never stop asking questions, but more importantly you should never stop answering them.

3. Trust people to do the right thing

We believe that everyone we’ve hired is working to the best of their abilities. Nobody is actively working against us and trying to destroy everything. We trust that people, our team members, are working towards a common goal and will make sensible decisions.

In some cases the “right thing” is not to work on something or to ask for help with something. You trust that they know their own abilities. Giving people this trust, also builds their confidence that they are making the right decisions. It takes time to do this, to learn how to make good decisions, but you end up with smart proactive people rather than mindless drones that just do what they’re told.

4. Treat people like grown-ups

This goes hand in hand with the previous one, but is more focused on permissions. We don’t require everyone to ask permission to do things. Since we trust that they’ll be doing the right thing, we shouldn’t need to put any rules or restrictions in place to stop them from doing things.

One example of this is how we deal with committing code and pull requests. We don’t require them for every single thing that someone commits. Rather, we leave it up to each developer to decide whether they think it requires a pull request – are there specific questions they want answered, or do they want feedback on it – it’s up to each person to make that decision.

5. Don’t focus on job titles

We think it is important that people are not confined by their job title. We don’t want anyone thinking “I can’t do X because I’m only a developer”, where X could be “lead a team”, “run a retrospective”, “manage our infrastructure” or “work on a back-end story” etc. Everyone on the team is encouraged to work on the skills they want to have, even if they might not have them yet.

For instance, we try not to differentiate between “junior”, “mid-level” or “senior”, or even between “back-end” or “front-end”. We don’t expect you to be the best at something to be the one to do it. As long as you know who to turn to and who to ask questions to if you do get stuck.

6. Give constructive feedback

Giving feedback and helping others improve themselves is a good thing, but you need to be constructive. Give feedback that allows people to understand the changes they need to make.

For example, rather than purely saying that you don’t like someone’s commit messages, give examples of exactly what you don’t like about their commits: are their commit titles too short? Are their messages not descriptive enough? Make sure your feedback is directly actionable by the person receiving it.

These are just six values that we believe create a culture where people feel comfortable with learning and failing. They are not the only things we can do, but we think these form a good base for creating the right type of environment to enable learning. How would you create a culture of learning? How would you help others deal with imposter syndrome?

Want to know more about the way we do things at FutureLearn? Check out the video of Melinda’s talk about our culture of learning or take a look at more of our “Making FutureLearn” posts.