A lot of people ask how do you know you have product market fit? If you have to ask, you don't. Product market fit feels like you're being dragged kicking and screaming by the market as users ask for more and more stuff.
I joined a company with PMF last year. At one point an interviewee asked how does it feel to work here? Honestly, it feels like I stepped into a blender and someone just keeps pressing the button. We've grown engineering by 3x, the company by 2x, we're running out of office space, and we still can't keep up. The market wants more.
So this talk is my attempt to step back and write down some of the things I've learned. Hope you find something to apply in your team.
Keep talking and nobody explodes
So there's this game – Keep talking and nobody explodes. 2 players defuse a bomb. One has the instructions, one has the bomb. Your goal is to work together.
When I played this with my partner we tried both roles. When she had the bomb and I had the instructions, the game sucked. We kept bickering and fighting and we lost the game. Both of us felt panicked and out of control.
But when I had the bomb and she had the instructions – we won. Both of us felt in control, calm, and the words were flying. The more you talk, the easier it is to defuse the bomb.
Let go
I feel in control when I do the work, my partner feels in control when she understands the instructions.
Growing the team is a lot like that game. The more you talk, the more you win. Because you can't do everything, you have to let others do the work or you'll be the one who explodes.
The worst part is that you go from holding the bomb to holding the instructions. As others do more of the work, they need someone to be the glue and keep everyone pulling in the same direction.
And that's kinda scary. It's disorienting. Half the time you feel like you have half an idea what's going on. The other half you have all these ideas and no time to make them happen.
Run towards least certainty
As the experienced member on the team, you go to areas with least certainty. You surf out front and create clarity for others. Figure out what needs to get done, what technologies to use, who to talk to, find all the fires.
That's why it feels like a blender. You're constantly confused and jumping between levels of abstraction. One minute you're deep in the weeds helping to debug a database issue, the next minute you're answering "Hey how's that initiative for the quarter going?"
Like I don't know man, software flies like a squiggle. But you're accountable, you gotta know.
And if you try to timebox the jumping around, you'll just create piles of unfinished work waiting for you.
Who not how
The simple fact is you cannot do everything and be everywhere. The list of priorities and good ideas never ends. The more you create, the more users ask for, and the more ideas you have.
The solution, I've found, is to stop thinking about how to do the work and focus on who. Got an idea? Great! That's for Jane. Feature request? Awesome. That one's for Joe. Bug? Alice knows that code.
Every piece of work goes to somebody else. You can hold the instructions but you can't hold the bomb anymore. There's too many bombs.
You become the SideQuest Specialist
My job is increasingly sidequests.
— Swizec Teller (@Swizec) August 25, 2025
But it's okay, I got my job description updated to SideQuest Specialist (manager)
Since you can't work on critical things anymore, you become the sidequest specialist. That's still safe for you to do. The sort of projects where it doesn't matter if you have to put it down for a few days. Or weeks. Sometimes months.
I just implemented an idea that I started working on back in February. It's pretty cool. But it's a little bleeding edge and the tech wasn't ready yet. Had to let it cook for a few months.
That's the sort of thing you can do as the sidequest specialist. Long-term ideas with dubious feasibility. Or super short projects to unblock a thing for tomorrow so your team doesn't get distracted.
Or you can do the uncertain ground work, get things half way, then let others take over and finish the feature. This is fun but unrewarding. You never get to point at something and say I did that.
Mentor lots
Here's the rewarding part: You get to mentor others. Whatever that means.
I still don't know how to point my finger at mentorship. It's not like you have a meeting on your calendar that says mentoring or an item on your daily todo list. Mentoring is this thing that happens in between the work. Some days you spend 3 hours working with someone and it changes how they approach the work, other days you make a throwaway comment and people keep quoting you forever.
If you get it right, people will keep coming back to you for years even after you both work at different companies. At least that's what I do. Make sure you keep in touch with your mentors, it means a lot.
Explain your reasoning
I can't point at mentoring for you, but here's a few things I do that I think count.
The first is that you should always always explain your reasoning. On PR comments, on design documents, on just making quick decisions in slack. Spend the extra 30 seconds to explain your thinking.
This helps you check your work, it gives others the opportunity to say Hey, no, that assumption is wrong, and it helps them make good decisions later. You need to trust your team to run things without you otherwise the who-not-how approach won't work. If you don't explain your reasoning, you'll just become the bottleneck that has to make all decisions forever.
Teach one thing at a time
The next thing is to always mentor one thing at a time. If you're teaching someone how to design a robust distributed system, you can't also teach them how to break down a large user story in the same conversation.
Yes they'll need to do both, but if you keep your feedback focused they can actually implement it. You'll help them ladder up on everything over time, but if you make it all sound important today, they'll just get lost.
Newbies need encouragement, experts want feedback
Which brings me to another point: Newbies need encouragement, experts want feedback.
Forget the shit sandwich. The shit sandwich is for losers. You need to evaluate where people are in their newbie to expert cycle and adjust your approach. One person can be in different stages for different skills!
When someone's a newbie, you need to encourage them. Don't talk about the mis-steps, focus on the good stuff and encourage them to do more of that. Newbies can improve their average performance just by getting better at the stuff they're already good at.
But when someone's an expert, you have to focus on their weak points. They can't get better at the stuff they're crushing. The way to raise average performance is to bring up the rear and get better at the stuff they can't do.
Same is true for you.
Outcomes over outputs
Your other role is to keep everyone focused on the outcomes. You're the bad cop who says "Yes that's cool but what does it help us do?"
This part sucks. You want to play with all the new tech and fun toys but you gotta be the adult who says No. Everything you do needs to lead to an outcome. You don't have time for navel gazing. You need new superpowers, new features, new abilities for the stakeholders, always an outcome.
Let people engage their curiosity but keep them focused. When they find work to do, say "great! What does that give us?", when they find code to refactor, say "awesome, how exactly is it blocking you?"
Find ways to make their work useful sooner. There's more people waiting than you realize.
User stories are good actually
I think user stories are surprisingly helpful. Yes they sound dumb but wow do they work.
"as <type of user>, I want to <achieve outcome>". This structure is important. You have to know who benefits from everything that you do. That way you can ask them if it worked. And you have to know the outcome they want to achieve – what will they be able to do that they weren't able to do before?
Avoid just doing work and delivering code. Focus on achieving outcomes. Code might not even be the best way to make it happen! Sometimes you gotta swipe a credit card.
Most importantly when you talk in user stories, every engineer can think critically and decide if they're falling down a rabbit hole or working towards a crisp result.
Write down everything
That reminds me – write down everything. Feeling like you're in a blender comes from holding too much stuff in your brain at the same time. Some of this is inevitable, you can't do this job if you don't think about it in the shower.
But when it comes to tactical stuff, write it down. Keep notes on decisions made and the inputs that went in. Write down your system designs. Put more context in your stories. Keep subtasks for all in-progress work. Have documents for mid-term roadmaps.
You have to be able to put things down and pick them back up 3 months later. Writing helps. I think of it as stateless decision making – you want to read 1 or 2 documents and make a decision without having to remember everything that happened in the last 6 months.
This also lets you delegate or get help. Share the context.
Set the vision, take small steps
![Building software is like kicking a can](https://i.imgur.com/ajaEEqk.jpeg
On the topic of roadmaps, you want to keep things flexible. Your task manager is way too rigid for long-term planning.
Anything more than a few months out, keep as an idea in your head. A target to aim for. It's gonna keep changing and that's okay. Talk to people, get input, keep making changes.
The next month or two keep in a doc. That's easy to change but more crisp than vague ideas. You can grab on and mold it into something actionable.
The next few weeks, keep as user stories in your task manager. Focus on achieving outcomes. Make them small and valuable. Aim towards the ultimate vision in your mind. It's okay to twist and turn around the ideal path. Shipping will also change your mind.
Don't be afraid to throw things you'll never do on the backlog. It gets them out of your mind and onto paper where they're safe to forget about.
You're a new company every 12 to 18 months
And remember, you're basically a new company every 12 to 18 months. Just because something worked 6 months ago doesn't mean it's gonna keep working now. And vice-versa – just because it didn't work when you first tried, doesn't mean it won't work now.
Try stuff, see what works, toss the rest.
~Swizec
Continue reading about Leadership lessons from growing 3x in 1 year
Semantically similar articles hand-picked by GPT-4
- Why senior engineers get nothing done
- Why great engineers hack The Process
- A few more thoughts on mentoring
- Can I get your opinion
- "Yes caviar is great, here's a ham sandwich"
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️