Why I joined an engineering team of 6

6 months ago, I joined incident.io as the seventh Product Engineer. Previously, I’d had experience in a scale-up of 70 engineers and a large consultancy. As the first non-referral joiner to the team, leaving a job I enjoyed to join a small team felt like a huge leap. There’s a reason why referrals are a really solid way to quickly build a great team, and as a joiner it’s a great way to know somewhere is legit by hearing the endorsement of someone you trust. 6 months in, and I’m so glad that I made the decision. In this post, I’ll talk about why I took the leap, why I’d do it again, and how to mitigate the risk of taking a big decision like this.

Why choose a start-up?

Start-ups, particularly small ones can be really unique in the ways they work. It’s not for everyone, so it’s important that you consider the key points that differentiate the experience and whether they are right for you.


The overwhelming difference between incident.io and anywhere I’ve previously worked is the pace and urgency behind the team. I find it incredibly motivating that large scale features that might have taken 2 months to build in previous companies can now be turned around in 2 weeks.

It’s really important to make the distinction here between running as fast as possible without direction, vs setting a high default pace and making the destination important. It’s also vital to understand that setting a high bar shouldn’t be associated with stress and long working hours. For me, moving quickly means assuming a high default rate of output, but also quickly raising issues, and refocusing when things change. We know things don’t always go to plan, and recognising this and adapting quickly is what can really drive pace.
I’ve found this mode of working really exciting, but it’s important to also recognise the difficult parts. To output features at a high rate, you have to be ready to take bets without having rigorously considered and scoped all options. This means being really ruthless about MVPs, and occasionally making difficult decisions to stop working on a project and refocus elsewhere. These can be tough calls to make, so it’s important to pull together as a team and really identify why you’re making these decisions.

Aside from delivery, the rate of changes to how you work is incredibly high. Processes that you put in place may work for a while, but can quickly become inefficient or not suited to the rapidly changing environment as your team grows, direction changes, and new information becomes available. It’s vital that you’re not only comfortable with a constantly changing environment, but also can reflect and identify the places where change is needed and drive this forward yourself to keep things working efficiently.


The scope you have to make an impact and have a real stake in the decisions of a company decreases vastly with its size. When I chose incident.io I knew it would be one of the best ways to accelerate my development through having to work on such a variety of problems. This prospect also worried me slightly - I wasn’t sure if this would amount to being thrown into problems alone with no context or experience. In reality I’ve found that solving these problems is often far more collaborative than I’d expected, and working on such a breadth of challenges means I’m constantly learning.

With small and fast growing teams, there’s a huge array of opportunities to get involved and make an impact. What can be difficult is finding where you can maximise that, given that there will be countless places you can get involved. You are often in the best place to identify the biggest impact you can make, rather than waiting to be directed. Initially I found myself often assuming that there were reasons behind why things were the way they were. In reality, I’ve found that almost all of the time my instincts on processes feeling weird are correct, but others just haven’t had the time to fix it themselves. In fast growing start-ups, the best way to improve things is to pick up the thing that feels the worst and run with it. There can be less availability from a manager to hand-hold you through things and help you find where you fit into a team, so carving an impactful role for yourself is important.


Working with a team of people who are excited about the company and product they are working on is great. Generally people who’ve been working at startups from the beginning are pretty convinced by the mission. The sense of everyone pulling in the same direction is really clear and people feel far more invested in making stuff work than I’ve experienced in the past. Being excited about and believing in the product I’m building has made a massive difference to the satisfaction I get from working.

I think work should be fun, and I think there’s a really crucial balance to get right, where you feel like you can perform at your best and enjoy what you do. A great way to find that fit is to work in a small and fast growing team, that you gel really well with, but critically also really care about what they’re doing. Too far one way and you leave for the day feeling stressed and overwhelmed, without the camaraderie that helps you shake off the hard stuff. Too far the other and you lose the ability to give and receive crucial feedback because everything feels too detached. I found in previous roles that it’s really easy to lose focus and care in what you do when you’re not receiving useful and targeted constructive feedback, and frustrations with your team build when you’re good friends but lack the culture of being able to give the feedback too.

How to choose the right start-up?

Joining a small start-up is a risk. There’s the more obvious job-security risk, where start-ups only have a certain amount of runway. Funding, endorsement by people you respect, and existing customers can all be good signal, but there’s a lot of other advice on this subject so I won’t focus on it here.

Whilst these were all considerations for me, the aspect I worried about most was the culture. With small teams I’ve learnt that if if it’s good, it’s amazing, and if it’s bad, it’s awful. If the culture isn’t right for you, you don’t have the same ability to coast without investing all your energy or find likeminded people in different parts of the org like you would at a much larger company. As I mentioned earlier, referrals are a really solid way to reduce that risk by having the perspective of someone you trust. That’s not always possible though, so you have only a few vital opportunities to gauge the culture and what’s important to that particular company.

Take opportunities for casual meets

When going through the interview process with start-ups, it’s common that they invite you for a more casual coffee, or lunch with the team. These felt super alien to me at first, and I hated the idea of doing a day of interviews and then having lunch, without knowing if I’d passed or failed. I was wrong - in fact these casual meets are one of the most useful opportunities you have to meet the people you’d be working with. If you’re interviewing with a small team, it’s almost certain that the engineers that interview you will be directly working with you, so trust your vibes here. If in-person interviews are offered, these can be a great way to chat to people and see what they’re about.

Assemble your questions

Again, the opportunities you have to find out more about an organization before being offered a job are realistically limited. Having a really solid list of questions to ask is a good bet for getting the most out of the time you have with them. Write down a list of things you hated and loved about previous companies you worked, and restructure them as questions that really target how that works at the organization you’re considering. Compiling a list of “dealbreakers” over time around culture, engineering set up, ways of working, and being able to ask about them in interview processes is a really important skill.

Culture interviews offer a great opportunity to learn more. All the advice around interviews I’d been given before was to answer questions with a certain formula to give you the best chance of passing an interview. I’ve rethought the purpose of culture interviews in my mind more recently - I think it’s super important to be true to yourself here, and realise that if you have really clear ways of working that don’t align with a company, you probably wouldn’t enjoy being there. Consider the company’s values, and the questions they ask you - do they feel like things you’re not only comfortable with, but are important to you in a workplace? These interviews are usually a great opportunity to be face to face with founders - they are the ones defining the culture, so I’d really encourage bringing your own questions here and dissecting what they’re asking you. If you’re asked about delivering high output, is that accompanied by expectations on working hours and getting things done no matter what? Don’t just dig into what they’re asking you, but why.

Trust your gut

Since you can’t ever find out what somewhere is like without actually taking the leap, you have to trust what you see, and find any and all places to gather information. There were a few other points that really sold incident.io for me. I read their blog to learn which topics were important to them. Seeing tweets from a company or its engineers can also show you some vibes you wouldn’t see otherwise. Working in an inclusive team was essential for me also. It’s so hard to gauge this in an interview - everyone tends to say they care about diversity and inclusion if you ask. Seeing evidence of diversity within the team can often be a good start, and diving deeper into the elements of this that you care about and asking targeted questions is a good way to determine if this is actually ingrained in a company’s culture.

Overall, I’ve had a great 6 months here and can safely say it was the best career decision I could have made. Working in such a fast-growing team has been so much fun for me, and I’ve learnt so much since joining. That said, the experience isn’t for everyone and all start-ups can be wildly different, so actively considering the weight of these decisions and gathering all the information you can is crucial.

Picture of Martha Lambert
Martha Lambert
Product Engineer

Operational excellence starts here